IPv6 Confusion

Tue Feb 17 22:17:13 UTC 2009

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 