Re: A Plea for Architectural & Specification Stability with IPv6

[Mark ZZZ Smith <[e-mail]>]

++1


"The Twelve Networking Truths"
https://tools.ietf.org/html/rfc1925

"(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take away"



>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: RJ Atkinson <[e-mail]> 
>Cc: IETF IPv6 Mailing List <[e-mail]> 
>Sent: Friday, 14 March 2014 1:27 AM
>Subject: Re: A Plea for Architectural & Specification Stability with IPv6
> 
>
>
>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
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[e-mail]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>
>
>