David Conrad wrote:
Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.
Right. I'll admit some confusion here. If the IETF, due to religion or aesthetics, is blocking attempts at making DHCPv6 do what network operators _need_ (as opposed to want), why haven't network operators routed around the problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., to implement what they need?
At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work.
How do we fix that?
You seem to be asking "how do we make people not stupid". Folks tend to simplify reality so that it fits their world view. Stupid people attempt to force that simplified reality onto others. You can either play their game, attempting to get them to understand reality is often more complicated than we'd like, or route around them. Or you can post to NANOG... :-)
The root of the argument I see in this entire thread is the assumption that 'what we have for IPv4 has *always* been there'. There is lots of finger pointing at the IETF for failure to define 15 years ago, what we have evolved as the every-day assumptions about the IPv4 network of today. SLAAC was presented specifically to deal with the DHCP failure modes of the time, and the very real possibility that DHCP might not make it as a technology that operators would want to deploy. While lots of evolution happened in the DHCP space to deal with changing operational requirements, it is still a complex approach (which may be why it is favored by those that like to maintain a high salary). To be fair, there were failures in the IETF, as the SLAAC and DCHP sides couldn't get out of each other's way; so now instead of having 2 independent models for provisioning, we have 2 interdependent models. RFC 5006 is one step at breaking that interdependence, and more are needed on the DHCPv6 side, yet these steps can't happen if people sit in the corner and do the 'they won't listen to me' routine. For those that insist that DHCP is 'the only way to know who is using an address', have you considered dDNS? Oh wait, that moves the trust point to a different service that in the enterprise is typically run by the host admin, not the network admin, or in the SP case crosses the trust boundary in the wrong direction ... my bad. Seriously, there are ways to figure this out, as Ron Broersma pointed out on Monday. I am not arguing for one model over the other, as they each have their benefits and trade-offs. The real issue here is that some people are so locked into one approach that they refuse to even consider that there might be an alternative way to achieve the same goal, or that the actual goal will change over time in the face of external requirements. IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no different. The fact that there is not functional parity between the operational aspects is due to operators insisting until very recently that 'the only thing that matters is IPv4'. It should not be a surprise that IPv4 is where the majority of the work in the IETF happened. Despite my attempts to get the IETF to stop wasting effort on what is clearly a dead-end, this is still true today. As drc points out, you can continue to post complaints on the nanog list, or if you want real change make sure your vendors get a clear message about IPv6 being the priority, then make your point on the appropriate IETF WG list. At the end of the day, the way networks are operated today is not the way they will be operated in 5 years, just as it is not the same as they way they were operated 5 year ago. Asserting a snap-shot perspective about 'requirements' has its place, but everyone needs to recognize that this is an evolving environment. Changing the base protocol version is just one more step on that evolutionary path. Tony