[arin-ppml] An article of interest to the community....

[Owen DeLong]

On Aug 30, 2011, at 1:06 PM, Mike Burns wrote:

> Hi Lee,
>  
>  
> Old work and new work on this issue:
>  
> http://www.faqs.org/rfcs/rfc1710.html
> http://tools.ietf.org/html/rfc6346
> https://mice.cs.columbia.edu/getTechreport.php?techreportID=560
>  
> The market, left to its own devices, has selected NAT as the pseudo-protocol of choice to facilitate virtually transparent address sharing.

An excellent argument in support of the idea that markets left to their own devices do not necessarily make good choices.

> I think there is work undone which would extend NAT to allow customers to have control over even multi-layer NAT and would define clear paths for multi-NAT traversal.

There is work undone which could optimize torture techniques to inflict greater amounts of pain while still not causing death, too. I don't support such research. IMHO, there is a direct correlation between these two types of research.

> I believe the IETF and the registries have thwarted development in these areas because they see, correctly, that IPv6 is a superior answer to problems of address shortage.

I do not believe that the IETF or the registries have thwarted development in these areas. I believe that development in these areas has thwarted itself because when presented to the market of ideas and compared to IPv6, that particular market of ideas (the market of ideas instead of the market of $$ and current vested monetary interests) is a market that primarily consists of people who understand the problems in question and rightly chose IPv6 as a better solution. OTOH, those who do not understand the problem chose unperceived and not well understood damage to what they already know over a venture into the unknown. Such is the market of $$ where there is no requirement that the participants understand what they are buying.

>  
> The problem is that IPv6 has no customer demand driving transition, and has thus languished.

That is rapidly changing, actually.

And I believe that deployments of CGN will actually change it even more rapidly.

I think a bigger problem is that some organizations have spent far too much time and money "Promoting IPv6" and not nearly enough time just DEPLOYING IPv6.

Hurricane Electric is late to the party Promoting IPv6 because we spent our initial IPv6 investment on deploying IPv6 first. We focused on promoting after we had already deployed and implemented. Now we have again refocused on not only promoting, but, also helping others deploy.

>  
> I am not saying that I have a replacement successor protocol to deliver to you, but I look hungrily at the 8 bits of port number space in the header and wonder whether it is possible to effectively multiply our current space by 256, which to me would provide ample headroom and still leave 256 potential ports per address.

8 bits is not nearly enough. We're already at nearly that level of compression through existing NAT mechanisms and all you'd really be doing is moving around where the address compression occurs. Arguably you would be moving that address compression to a less functional place as well. You might gain a few efficiencies in the process, but, certainly not 256x.

>  
> And this is in answer to the question posed by Mr. Vixie, which postulated a no-option endpoint at IPv6.
>  
> If I had a magic wand to wave, I would wave it and turn the Internet to IPv6 overnight, I wouldn't wave it to create a half-way protocol extension.
>  
> But we have no magic wands to wave and exhaustion of the lingua franca staring us in the face.

Which is why we need to get over the idea of half solutions, implement the transition mechanisms we have where we must and deploy IPv6 everywhere as quickly as possible so that we can get on with the business of maintaining and improving a scalable end-to-end internet built on a protocol that has a future (IPv6) rather than continuing to try and breathe life into a protocol that, in reality, ran out of steam almost a decade ago.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110830/245d7e5a/attachment.htm>