On Fri, 2014-06-13 at 18:38 +0200, Tom Gundersen wrote: > On Fri, Jun 13, 2014 at 6:26 PM, Dan Williams <d...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
