On 10 jun 2011, at 18:06, Leo Bicknell wrote: > However, many networks are much more closed deployments. Enterprises > have not deployed IPv6 internally yet. Many will not deploy it for > another 3-5 years, chosing instead to use web proxies at the edge > that speak IPv4 (RFC1918) internally and IPv6 externally. They > often can enforce the software deployed on the boxes connected.
If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways. > The fact that bad standards and software exist today should never be an > argument to not design and deploy better software. So what if it takes > until 2019, at least from 2019 to the end of IPv6 we'll have something > better. If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. On 10 jun 2011, at 19:32, Owen DeLong wrote: > Some administrators want DHCP to be a complete solution and do not want to > use RA at all, whether from a legitimate router or otherwise. It's good to want things. Doesn't mean you'll get it. One of the three big RIRs has already run out of IPv4 space, the second will within less than a year. IPv6 deployment is still measured by counting zeroes behind the decimal point. We still don't have good CPE and broadband specs. The "happy eyeballs" stuff is still experimental but much needed. Important operating systems have serious IPv6-related bugs. And THIS is the time to start asking for a new feature that even when viewed most favorably, is just a nice-to-have? No more that pesky multicast packet once every 200 seconds (or when a new host attaches to the network). Yes, that's really something the IETF and vendors have to spend their cycles on. NOW. Because otherwise, you know, there's this packet. It's really bad. Every 200 seconds! > There are situations, for example, where the administrator does not want all > hosts in a broadcast domain to receive the same set of prefixes and/or the > same set of routers. This can be achieved by using different parameters based > on the system identifier in the DHCP configuration. It cannot be achieved > using RA. It can also be done using my suggested "DHCP validates RA gateway address" mechanism. > Eliminating rogue RAs is not the problem being described. That problem is > solved through RA-Guard. Well, someone certainly intermingled the discussions, and it wasn't me. > The problem being described is the desire to be able to configure a host from > zero to functionally on the internet using DHCP without RAs. I think everyone > understands that you don't want to do so. That's fine. However, adding the > functionality to DHCPv6 doesn't require you to use it. Making it available > for operators that want to use it is not a bad thing. It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD. This industry has a history of doing stuff that ends up wasting huge amounts of time and money that could easily have been avoided but apparently the voice of reason was absent that day. Not this time. > In some situations, this fate (it's fate, not fait, btw) Oh, right, I always get that wrong and I know I always get it wrong but still that doesn't help me to get it right. > sharing is not desired. Why not? > documenting that a host which sees no RA should attempt DHCPv6 would also be > a good thing, IMHO. Nope, not a good thing. It doesn't work for normal operation because the delay while lack of RAs is observed would be unacceptable. Also, the M and O bits need to be honored. A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. And like I said before, we have more pressing things to do than tinker some more with DHCPv6.
