On Mon, Aug 09, 2010 at 04:18:30PM +0200, Pavel Herrmann wrote: > Currently ISC dhclient (and others) set the prefix length to 64, which might be > what you want, but otherwise is just plain wrong (or possibly acceptable as > failover if no prefix for DHCPv6 supplied address has been received). The fundamental problem is that DHCPv6 does not supply a prefix length along with the configured address. It is just an address, so the advertised prefix length in this sense could be said is /128. The problem this causes is blindingly trivial; Hosts with valid IPv6 addresses (allocated by DHCPv6) cannot communicate with other hosts on the same link in the situation where a router ceases emitting RA's. They have no covering prefix that tells them other nodes are local (for example, their nameserver(s), which may still be able to tell them a working address of their email/'Intraweb'/etc services). So the local LAN goes dead after the uplink dies. A local DHCPv6 server means DHCPv6 would continue to succeed in configuring the clients, but without an outbound router they cannot reach their neighbors. In my opinion this is a really bad precedent in Internet design, and a DHCPv6 client is broken no matter what prefix length it chooses to apply. This, and the proposed workaround to have any local DHCPv6 server emit redundant RA's, fails the litmus test of user expectations. Neither do users expect to have to start radvd whenever dhcpd is started (that is the router's job), nor do they expect 'dhcpd -6' to invoke an radvd. You can simply modify your local client to use /128 prefix lengths for the allocated addresses (this will work fine because you will get wider prefixes from your RA's) if the above failure scenario doesn't concern you or exceed your users' expectations. For my part, since attempts to allocate a formal DHCPv6 option code have ground to a halt, we will switch to use prefix length options in 'VSIO' sub-option spaces (Vendor-Identified using ISC's Enterperise- ID). ISC DHCP's v6 server can then send the prefix length option by default. In the client of the same software version, I feel confident we can switch to using /128 prefixes when the configured prefix length is not present. This should satisfy all parties. Honestly, I chose this path because I believed that non-64 bit prefix lengths would be uncommon until much later in IPv6's deployment. I figure it affects the least number of people until we can get a fix installed. One more piece of information: IETF has never agreed on correct meaning and implementation of M and O bits in RA flags, which I think is more the subject of your query. Are you supposed to stop a client if the bits clear? No one seems interested in providing clarification. The last implementor to try was told to pack it up. My advice then is to simply run the DHCPv6 client permanently. When a DHCPv6 server is present, you will receive configuration. When it isn't, you will simply fall back to wider and wider retransmission intervals, and no real harm is done. Of course this means you also don't need to have a feed of kernel received RA's or their timeout behaviour. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgp7IeTqXzaf4.pgp
Description: PGP signature
