David Conrad wrote:
On Feb 17, 2009, at 11:28 AM, Tony Hain wrote:
Approach IPv6 as a new and different protocol.
Unfortunately, I gather this isn't what end users or network operators want or expect. I suspect if we want to make real inroads towards IPv6 deployment, we'll need to spend a bit more time making IPv6 look, taste, and feel like IPv4 and less time berating folks for "IPv4- think" (not that you do this, but others here do).
I am not trying to berate anyone, just point out that your starting perspective will impact how you see the differences. From what I have seen, people are generally happy when they find similarities, and pissed off when the find differences. Therefore, if you start by assuming it is different, you will be much happier.
For example, getting over the stateless autoconfig religion (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4.
There are many religious positions here, and none are any more valid than the others. At the end of the day, each approach needs to be complete and stand-alone, but due to religious fighting, all approaches are required to exist at once for anything to work. This being a list of network engineers, there is a strong bias toward tools that allow explicit management of the network. This is a fine position, and those tools need to exist. There are others that don't want, or need to know about every bit on the wire, where 'as much automation as possible' is the right set of tools. Infighting at the IETF kept the RA from informing the end systems about DNS, and kept DHCPv6 from informing them about their router. The result is that you have to do both DHCP & RA, when each should be capable of working without the other. As far as dnssec, while the question is valid, blaming the IPv6 design for not considering something that 10+ years later is still not deployed/deployable, is a bit of a stretch. This all comes down to trust anchors, and personally I question the wisdom of anyone that considers DHCP to be a valid trust anchor. It gets that status because it is something tangible that is reasonably well understood, but there is nothing in its design, or the way that it is deployed in practice that makes it worthy of anything related to trust. An out-of-band trust cert between an auto-configured end system and a ddns service makes much more sense than a DHCP service based on believing that the end system will not bother to spoof its mac address.
Or, we simply continue down the path of more NATv4.
While this is the popular position, those that have thought about it realize that what works for natv4 at the edge, does not work when that nat is moved toward the core. If people really go down this path, the end applications will do even more levels of tunneling over the few things that work, and the network operators will lose all visibility into what is really going on (IPv6 tunnel servers are just the modern modem pools, and tunneling over http will become more common if that is the only path that works). Tony