tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD systems as half-routers for P2P or VPN links



On 6 Feb, 2013, at 23:01 , Erik Fair <fair%netbsd.org@localhost> wrote:
> Can NetBSD systems in a pair with a point to point link (physical or VPN'd 
> through ... pick your virtual interface) act as half-routers, with the 
> intermediate link being "unnumbered" (to use Cisco parlance)?
> 
> If so, what's the configuration recipe?

Ah, one of my more favorite doesn't-work-right topics.  The short
answer is no, in a BSD kernel you can't use an interface for a
protocol without that protocol's addresses configured on the
interface.   The work-around is to configure the local address
on the p2p interface the same as an interface in the box which does
have an address configured, while setting the destination to some
arbitrarily chosen address which is unlikely to be used by a host
you need to talk to.  Note that the addresses on a BSD point-to-point
interface are (unlike Cisco, I suspect) unrelated host addresses;
they don't need to have a prefix in common but they do need to be
there.

The longer answer is that it is a misfeature of BSD protocol
configuration; a network protocol is traditionally configured 'up'
on an interface by configuring an address for that protocol on the
interface.  The "protocol configuration" == "address configuration"
has some very annoying side effects.  It is one of the (short list of)
reasons why an IPv4 DHCP client can't use the kernel UDP stack to send
and receive its UDP packets, and instead has to resort to BPF and roll
its own IP/UDP; it would need to put an IPv4 address on the interface
to configure it up for sending and receiving the IPv4 packets it
needs to exchange to learn the address to put on the interface.  It
is also the reason you can't keep IPv6 from yammering out interfaces
as soon as they are turned on even when you know there is no hope
of there being anyone for it to talk to (short of compiling the whole
thing out of the kernel, that is); if "protocol configuration" ==
"address configuration", but IPv6 can conjure up and configure its
own addresses, then there is no way at all to tell IPv6 where it is
and isn't appropriate to do that.

I think the right solution for this is to separate protocol-is-up
configuration from address configuration.  That is, you turn the
interface hardware on, then you configure the network protocols you
want to operate there 'up', and only then do you (or the protocol
you've just configured up) add address configuration, or not.  Note
that a multiaccess interface with the protocol up but without
addresses isn't very useful, but it is useful enough for DHCP to
exchange packets and learn the addresses to configure the way
a normal UDP application does.  A point-to-point interface, on
the other hand, is pretty much fully functional once configured
up without any addresses at all.  Once point-to-point addresses
are relieved of their "protocol configured up" function their
remaining utility is limited and optional.

I'm hence not quite sure why you are calling it a "half-router"
when the addresses aren't there.  The relationship between the
two routers, or between a router and a host, is identical
whether a point-to-point link has addresses configured or not;
the addresses don't matter very much, they are essentially a
form of static route configuration.

Dennis Ferguson


Home | Main Index | Thread Index | Old Index