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

[Tom Gundersen]

On Fri, Jun 13, 2014 at 7:10 PM, Dan Williams <dcbw at redhat.com> wrote:
> 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.

Right. Splitting this up makes sense to me.

Cheers,

Tom

> 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
>