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.
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.
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.
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.
Yours, Joel M. Halpern
At 05:36 AM 3/11/2005, shogunx wrote:
On Thu, 10 Mar 2005, Erik Nordmark wrote:
> Tony Hain wrote: > > >>Why are we wasting effort in every WG and research area on NAT traversal > >>crap??? > > FWIW I'm also concerned that we are doing too many different NAT > traversal protocols. It should be sufficient to just define how IPv6 is > tunneled across NATs and start using more IPv6 in the applications.
I agree wholeheartedly. Lets face the reality of the situation. Carriers have abused IPv4 for financial reasons. As a result, NAT is widely deployed, because it was and is an effective workaround for dealing with siad carriers trying to squeeze extra money from IP addresses. There is nothing that can be done about that now, except implement the solution that has been written to solve the problem, IPv6, right on top of the existing NAT's. With full application layer support for v6, NAT will eventually deprecate, and be little more than a bad memory. The open source community has a wide variety of v6 enabled daemons and clients already, for almost every widely used protocol. While these can easily be implemented on any host, good luck getting the general public to do so. The solution for migration most likely lies in somebody developing a little v6 router, that autoconfigs a tunnel with a small allocation of addresses.
Scott
>
> >>On another topic, why is it that the API is so sacred that we will create
> >>a massive array of complex approaches to avoid defining a real session
> >>layer. We put imitation session efforts at layer 4 (SCTP), layer 3.5 (HIP),
> >>layer 3.25 (shim), and the TRILL crap is trying to do it at layer 2.5.
>
> I don't understand what makes you think TRILL is trying to do a session
> layer. If it does, then any other routing and tunneling approach should
> also be given the same verdict.
>
> Erik
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
