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).