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

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 7 Feb, 2013, at 11:52 , Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

>> 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;
> 
> How could the anything use the kernel UDP stack when the interface has
> no addresses?  It can't even tell what packets are intended for it
> under such circumstances.  It is not possible to send an IP packet
> without putting _something_ in the ip_src and ip_dst fields.  Using IP
> without configuring an address means incoming traffic can't work
> because the kernel has no way to tell whether a packet is intended for
> it or not; outgoing connectionless traffic could in principle work, but
> would require userland to explicitly specify the source address for
> each packet (since the kernel can't assign one as usual).

That's fairly straight forward.  Most UDP applications, for example ntpd
and bind, need to be able to explicitly tell the kernel what source address
to put in an outgoing packet in any case since, if there is more than one choice
for this, they need to make sure that the source address in a response is
the same address that was the destination of the request they are responding to
(TCP does this automatically, but kernel-stateless UDP requires applications
to manage this themselves).  If you have a way for applications to tell
the kernel what source address to use in outgoing packets then the DHCP
application, having suitable privileges, can use this to tell the kernel
it wants the source address to be 0.0.0.0.  Note that the exact mechanism
ntpd and bind use now can't quite manage this but is also broken in other
ways, anyway; both ntpd and bind will spectacularly fail to run, for no good
reason, on machines with a sufficient large interface configuration.  A
different way to indicate the source address, say a sendmsg() option, could
satisfy DHCP's needs as well as helping fix the interface scaling problems
that ntpd and bind have.

That's the source address.  While you can't send a packet to a unicast
destination address out an ethernet with no addresses configured you can
always multicast the packet or send it out using the 255.255.255.255
broadcast address.  DHCP is required to use the latter; this should
just work.

That's the outgoing side.  On the incoming side there are a couple of options.
If the interface is configured on you will see IP packets arriving from it and,
while the kernel won't recognize unicast-addressed packets as its own it will
willingly receive packets to multicast and the all-ones broadcast addresses with
no address configuration.  The DHCP client has the option of asking the server
to send responses to the all-one's broadcast address (the server doesn't have
to broadcast the response, but it does put that address in the packet IP
destination) and, if it does, those incoming packets will be delivered to it 
even
in a very vanilla kernel.  That's the easy way.

The harder way is to let the DHCP server send the packet back to your new
unicast address.  This packet will arrive on the interface but will eventually 
be
discarded as "not for us".  This wouldn't be worth fixing for DHCP alone (DHCP
has the 255.255.255.255 alternative), but note that the need to receive packets
that don't look like they are addressed to the local box is not solely DHCP's
problem; certain routing protocols, e.g. RSVP and PIM, need to be able to do
precisely the same thing.  The thing all of these protocols have in common is
that the packets of interest will normally end up in an exception path in an
unmodified networking stack (the discard path for DHCP, the IP options 
processing
path for the routing protocols), so having a facility against which packets
could be checked if they arrive at that exception path to see if they might be
of interest to the local system regardless of their destination address would
kill several birds with one stone.

Generically speaking I don't think there's any reason a DHCP client couldn't
be implemented as a fairly normal UDP application with a decently functional
networking stack, and fixing the things which prevent a NetBSD networking
stack from supporting this would have benefits for applications beyond just
DHCP.

> 
>> it would need to put an IPv4 address on the interface to configure it
>> up for sending and receiving the IPv4 packets
> 
> Oddly enough, I've seen addresses configured with 0.0.0.0 while DHCP is
> trying to get an address on them.

That's another way at getting the kernel to send packets with a 0.0.0.0
source address.  I prefer just being able to explicitly tell it what
the source address needs to be since many UDP applications running on
multihomed hosts and routers need this.

Dennis Ferguson