On Fri, Jun 13, 2014 at 7:10 PM, Dan Williams <d...@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 <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.
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 > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
