Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

Wed Oct 3 16:54:54 UTC 2007

At 04:07 PM 10/2/2007, Iljitsch van Beijnum wrote:

>On 2-okt-2007, at 16:53, Mark Newton wrote:
>
>>By focussing on the mechanics of inbound NAT traversal, you're
>>ignoring the fact that applications work regardless.  Web, VoIP,
>>P2P utilities, games, IM, Google Earth, you name it, it works.
>
>O really? When was the last time you successfully transferred a file
>using IM? It only works half the time for me and I don't even use NAT
>on my main system myself. Some audio/video chat applications work
>well, others decidedly less so. The only reason most stuff works most
>of the time is because applications tell NAT devices to open up
>incoming ports using uPnP or NAT-PMP.

By policy, I generally block file transfer over IM at security 
boundaries where possible, whether NAT is in use. End users on 
corporate networks do not need to be using IM as a file transfer mechanism.

>>IPv6 will happen.  Eventually.  And it'll have deficiencies which
>>some believe are "severe", just like the IPv4 Internet.  Such as
>>NAT.  Deal with it.
>
>If you want NAT, please come up with a standards document that
>describes how it works and how applications can work around it.

Been there, and done that. Please go read RFC 3235, and read the 
other RFCs that came out of the NAT Working Group in the IETF. This 
WG documented how things worked, and how to write apps and such. NAT 
itself had been in widespread use for a long time before, though 
implementations varied in both function and terminology. Having a 
common point of reference, and recommendations for living with it 
seemed to many like a good idea. It appears the documents have not 
been widely read.

>  Just
>implementing it and letting the broken applications fall where they
>may is so 1990s.
>
>>If you believe that v4 exhaustion is a pressing problem, then I'd
>>humbly suggest that 2007 is a good time to shut the hell up about
>>how bad NAT is and get on with fixing the most pressing problem.
>
>"NAT is not a problem" and "running out of IPv4 address space is a
>problem" can't both be true at the same time. With enough NAT
>lubrication you can basically extend the IPv4 address space by 16
>bits so you don't need IPv6.

Running out of address space may well have been a problem a decade 
ago without NAT. You and I don't know, largely because none of us 
really knows how many computers are behind NAT boxes today. But the 
IETF was not ready to provide a replacement for IPv4 at the time. So 
NAT bought the IP protocol stack enough time to dominate the marketplace.

>>If we're successful, there'll be plenty of time to go back and
>>re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory.
>
>Right. Building something that can't meet reasonable requirements
>first and then getting rid of the holes worked so well for the email
>spam problem.

This is a rather disingenuous argument. You might look at the history 
of TCP, which has had several tweaks over the years as more was 
learned. In trying to have every duck perfectly in a row, IPv6 is 
quite late to the party. Even NASA launches deep space probes before 
operational software is finished, and updates it in flight... (OK, so 
maybe that's a bad example, given math errors and a certain crash on mars).