Re: A Plea for Architectural & Specification Stability with IPv6

[Lorenzo Colitti <[e-mail]>]

On Thu, Mar 13, 2014 at 9:49 PM, RJ Atkinson <[e-mail]> wrote:

>   If folks in the IETF IPv6 WG want IPv6 to be more widely deployed,
> more rapidly deployed, and its capabilities to be more widely used,
> then WE NEED TO STOP CHANGING THE IPv6 SPECIFICATIONS.
>

Hear, hear.

For a long time I've believed that int the IETF we think that IPv6 is "not
being deployed" because something is wrong with it. And so we keep changing
it. But that's not the problem. IPv6 *is* being deployed, it will just take
time. At current S-curve growth, we'll be done in 10 years.

The original IPv6 architecture is sound, and the core protocols are
perfectly deployable. They are a solid (though admittedly minor)
improvement over IPv4. There is *nothing wrong* with the IPv6 architecture.
Deploying IPv6 *as it is today* will, after a minor speed bump, lead to
simplification, cost reduction, and increased transparency of a network
that today is cluttered with brittle and expensive middleboxes (expensive
both because they cost money and because they cost developer time for apps
to work around).

It's true that those that want IPv6 to be exactly like IPv4 are
disappointed, because IPv6 is not IPv4. No, you can't do routing without
RAs. No, you can't "save addresses" by making host subnets /120s (at least
not easily). No, there is no RFC1918. No, ULAs are not the same as RFC1918.
No, there is no NAT. But I think that in a lot of scenarios those are
advantages, not disadvantages.

When people say that IPv6 can't be deployed in ISPs, in enterprise
networks, in content providers, in home networks, or in mobile networks
because it lacks feature X, we'd do well to remember that there are large
deployments of IPv6 in all these areas. I know, because I've personally
been involved in all of the above. In my experience, excuses for not
deploying IPv6 are, to a great extent, just that: excuses. They have no
relationship to the actual reason for not deploying it, which is, and has
always been, "we see no benefit" (or, to a lesser extent, "our code doesn't
support it", and "our code has bugs" -- both of which are temporary). These
excuses mislead the IETF into thinking that the lack of IPv6 deployment
means that there is somehow something wrong with the protocol. This in turn
causes hand-wringing and standards-writing, but in my experience, that
doesn't help: when we remove an excuse, people move on to another excuse --
because the excuse wasn't the real reason anyway.

Continued tinkering with IPv6 - especially tinkering with it to make it
look more and more like IPv4 in order to reduce imagined "barriers to
adoption" - will just erode IPv6's long-term advantages by eliminating the
simplification, robustness, and benefits that IPv6 as it is today *does*
provide -- and it won't lead to adoption anyway, because lack of adoption
is not a technical issue.

What we need to do now is stick to the protocols as designed and wait until
the combination of ever-increasing pain caused by IPv4 exhaustion, and
exponentially-increasing IPv6 deployment in the Internet at large (or at
least in the consumer space), change the "there's no benefit" equation.
That *does* have the power to cause deployment in a way which changing the
standards will never have -- and as you put it, the more we change now, the
more we *delay* deployment, by causing vendors to write code that then
needs to be waited for, tested, and debugged before operators can deploy.

Personally, I think 6man has the duty to ensure that no radical changes go
into the core protocols until *real deployment experience* -- not of the "I
can't deploy because..." kind, but only of the "I deployed *and it didn't
work because...*" kind -- shows that there is really a gap in
functionality, and even then, to think extremely carefully whether the
long-term effects will be beneficial or not. We're hoping that this IPv6
thing is going to last us for the next 30 years. Let's not get too hung up
on the next 3.


Cheers,
Lorenzo