On 21 okt 2009, at 23:34, David W. Hankins wrote:
There is a problem with the "Both RA and DHCPv6 Model" currently proposed by IETF iconoclasts. Should RA fail, for any reason from router, system, software, network path, security, or user error, then the simplest networks imaginable (where hosts and mail/Intranet/ work servers are all co-located on the same broadcast domain) will not be able to talk to one another,
Or the rest of the world. Note however that it is very hard to get false negatives for RAs and even harder to get false positives. The only way I've had RAs fail in the real world was with multilayer switches that wouldn't let IPv6 multicasts through because they couldn't do IGMP snooping for those. This affected RAs but also all other neighbor discovery, and would have affected DHCPv6, too. So in this situation IPv6 is completely dead in the water. The good thing is that you don't get any false positives, where a host thinks there's a router somewhere but there's not actually a router there. This is because when a router stops being a router it will also stop sending RAs. All of this works extremely well, I can't think of any instance where there is any trouble with RAs, except of course the problem of rogue routers advertising themselves. However, this is not really any different from the situation in IPv4 where rogue DHCP servers advertise stuff they shouldn't advertise.
To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means.
Why not simply fix the DHCPv6 protocol so it has a prefix length attribute? DHCP'ers can complain about stateless autoconfig and RAs, but the simple truth is that DHCPv6 has problems that are unrelated to anything outside DHCPv6 that haven't been fixed in the half a decade that I've been paying attention to it.
But it may complicate your designs if you are assigning /80's.
RFC 3513 says that all interface identifiers for addresses outside ::/ 3 must be 64 bits in size. That doesn't work with a /80. So I'm not sure if using DHCPv6 with /80s will work on all systems.
According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6' compiles and runs on Mac OSX. I don't actually own a Mac, so I have never used it myself, and our release notes even go into detail about the limitations of the current 'dhclient-script' for the Darwin platform (apparently their configuration system is somewhat opaque).
MacOS detects when interface go online and offline and does all kinds of stuff when that happens. For instance, you can't globally enable/ disable stateless autoconfig on MacOS, either. Manually running a script when the interface status changes is a rather blunt way to interact with the system.
Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X?
No...but I have heard plans of the exact opposite.
[...]
When people at the microphone asked why Apple did not include a DHCPv6 client implementation, even a stateless one, I believe Bernard Aboba addressed the concern at the microphone saying, and I am paraphrasing from memory here, "We were told by the IETF that RA was all we would ever need, implementing DHCPv6 is optional, so RA is all we are doing."
I don't remember that. What I do remember is that Stuart Cheshire of Apple explained how he was unhappy that it was necessary to run a rather involved protocol (DHCPv6) for the relatively simple task of obtaining DNS resolver addresses.
To summarize, RA+DHCPv6 implementers are posed with problems:
...which apparently some DHCPv6 people want to solve by ALWAYS running their chatty protocol that wastes a lot of bandwidth on wireless LANs until people give in and just run a DHCPv6 server just to get rid of the constant DHCP retransmissions that can't be stopped any other way because actually looking at the O/M bits is of course way too simple. I hate this crap so much.