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
Trying to pretend something won't work with IPv6 is not a substantive
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:
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
Ietf mailing list