[systemd-devel] [PATCH 00/24] Initial DHCPv6 client support

[Dan Williams]

On Fri, 2014-06-13 at 18:38 +0200, Tom Gundersen wrote:
> On Fri, Jun 13, 2014 at 6:26 PM, Dan Williams <dcbw at redhat.com> wrote:
> > On Fri, 2014-06-13 at 16:44 +0300, Patrik Flykt wrote:
> >>       Hi,
> >>
> >> This patch set provides initial DHCPv6 client support for
> >> systemd-networkd. It adds support for ICMPv6 Router Solicitation sending
> >> and Router Advertisment receiving and the very basic Solicit, Advertise,
> >> Request and Reply message transactions. Networkd is able to start DHCPv6
> >> negotiation for a link, but doesn't yet do anything with the result.
> >>
> >> As only the initial DHCPv6 client side support is implemented, this patch
> >> set omits the following features specified in RFC 3315:
> >>  - Rapid Commit in the Solicit message
> >>  - Information Request, should the router only announce the availability
> >>    of "Other" information
> >>  - Reacquiring of an address, i.e. Renew, Rebind, etc.
> >>  - Temporary adresses, option requesting, elapsed time options
> >>  - DHCPv6 authentication
> >>
> >> ...and a few more that I for sure have forgotten from this list. The
> >> intent is to have the remaining parts essential for the protocol
> >> functionality to be done as quickly as possible after this patch set.
> >>
> >> On startup, the DHCPv6 client implementation sends Router Soliciations
> >> in order to receive Router Advertisments. Only the Managed/Other flags
> >> in the Router Advertisment are currently used, any prefix information
> >> is currently ignored. ICMPv6 and a basic test case is handled by patches
> >> 02-04 with the basic DHCPv6 library and test case provided in patches 01
> >> and 08.
> >
> > For future consumers of the library, can the RA/RS behavior be
> > selectively disabled?
> 
> No objections from me, but out of interest, what is your desired
> behaviour here? Will this option be exposed to the user, or do you
> have some other way to determine whether or not to do RA/RS, or do you
> simply do it in a different way?

Two reasons:

1) We're already using libndp to do RS/RA in NM, and I'm sure we'd be
open to switching over in the future, but more importantly:

2) IPv6 RA/RS has no relationship with DHCP per-se, it's a provider of
some information that DHCP might want to use (the M/O bit) but that's
all. As such it makes no real sense to tie the two together, because
RS/RA is used in many more circumstances than DHCP is used.  I'm talking
about dhcp_network_icmp6_send_router_solicitation() and
dhcp_network_icmp6_bind_router_solicitation() mostly.

So best would be to keep the RS/RA bits completely separate from the
DHCP bits, but then consume the RS/RA stuff from the DHCP code.  That's
not going to adversely affect time-to-address if properly architected.

I know you probably don't care much about other DHCP clients, but we're
fighting this same battle with dhcpcd (on Debian mostly) which tries
really, really hard to be everything-and-the-kitchen-sink, and also
unconditionally does RS/RA when DHCPv6 is requested.

Dan