Joel M. Halpern wrote: > This discussion seems to take as a premise the view that if we define > applications only on IPv6, even though they could be defined on IPv4, that > this will give people a reason to use IPv6. > It also seems to take as a premise that if we don't define ways to work > around NATs, people won't use the applications with NATs. I suffer from no such disillusions as those are not the premise for the initial note, though without having the background in the original note it is easy to see why someone might come to that conclusion. My assumption is that the market will not ignore the opportunity to develop NAT traversal technologies. That does not equate to a need for the IETF to waste valuable resources standardizing hacks that attempt to mask previous hacks. In particular the IAB needs to be looking forward and helping the application community understand that there are approaches today that allow them to ignore the nonsense that has grown in the network by using IPv6 tunneling as a NAT traversal tool. This approach completely avoids the need for complex and error prone ALGs. > > The fact is that external evidence indicates that both premises are false. > For a long time we tried ignoring NATs. As a result, people crafted many > strange and non-interoperable ways to work with NATs. > I know of several initiatives that tried to define their protocols for > IPv6. Some even thought they had good reasons. Before the work was even > done, I saw customers requesting vendors to supporting the initiative > using > IPv4 directly. > > Trying to pretend something won't work with IPv6 is not a substantive > value > add for IPv6. I assume you meant 'without IPv6', and the point is completely lost on the IETF that we -can- build complex NAT traversal, but that does not mean we should. Intelligent people find the challenge stimulating so it is easy to understand the lure of solving the hard problem. At the same time the resulting complexity makes no operational sense at scale and substantially raises the costs of running the network and developing or deploying new applications. The result is not a win for the Internet as a whole. > > Not needing NAT is a minor value add for IPv6. But we have already seen > several major corporations publicly indicate that they intend to use NAT > with IPv6, even though they can get enough public address space. They have been sold the NAT == Security kool-aid. See: draft-vandevelde-v6ops-nap-01.txt > > As far as I can tell, following through on the kind of approach discussed > here would simply make our products les useful, and reduce actual > interoperability in the field. Generating hack after hack is raising the operating cost of the network. The frog is in the pot and the water temperature is rising. Does it have to reach a boil before we recognize that we should have left that environment behind? Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf