Re: Lack of need for 66nat : Long term impact to application developers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday 22 November 2008 05:39:02 ext Tony Hain, you wrote:
> There is a ---very--- large issue here related to the application
> developers and end users need to deal with topology warts. In IPv4, nat
> became necessary due to the limited address range, so establishing some
> rules through Behave made sense to minimize the kinds of impacts that
> applications would have to deal with. So far there has not been any valid
> need documented for why a 66nat should exist. Just the lame, 'they will be
> built anyway' group-think of the mob.

Because "they will be built anyway", application developpers will continue to 
try to design application-layer protocols around them. From that sole 
perspective, it does not matter than much whether IETF specifies NAT66. It 
matters whether IETF designs layer>=4 protocols that cope with NAT66 
which "will be built anyway".

That being noted, history shows that IETF has designed lots of protocols that 
do not cope with NAT44, especially before BEHAVE (at least in Transport, 
Internet and RAI areas). And the similarity with the SBC "problem" in RAI 
area is too striking to not mention it. In other words, I am not very 
optimistic about IETF coping with NAT66, if it ends up not being specified 
_yet_ widely deployed. Eventually, the long-term relevance of -several areas 
of the- IETF is at stake.

On the other hand, as I said at the mike, the very fact that IETF would 
specify NAT66 will be an excuse for vendors to ship it. In the end, I expect 
we'd end up with "better" but more widely deployed NAT66. I don't claim to 
know which way would be best. I just hope that NAT66 is NOT deployed in 
access and unmanaged IPv6 networks in any case, and shall stick to 
managed/corporate policed networks. That is why I argued for a clear 
unambiguous applicability statement to NAT66 should the IETF go forward with 
it.

> If there is a valid need, yes Behave should make sure we minimize the kinds
> of impacts that applications have to deal with. Lacking a valid need,
> standardizing 66nat only ensures that applications will have to deal with
> these unnecessary topology warts ---forever---.

> This is ---NOT--- making things 'better' for applications developers, and
> end users.

The fact that vendors claim they're going to do it anyway makes me feel like 
we really should standardize it anyway. The point is precisely to limit its 
bad impact upon application developpers and users.

The only reason why I'm personaly undecided is the fear that standardizing it 
also makes it -needlessly- more widespread that if it were not specified.

> Making it easier for a few product vendors to throw in 66nat while they are
> doing  46/64 is not in the long term best interest of the Internet, and
> therefore the IETF should not be doing this work. The charter of Behave
> should be amended to remove this entire discussion until someone
> demonstrates that we actually need a 66nat because there is no way to solve
> a real problem without it.

Makes me think...

I was largely over-hummed in favor of only specifying TCP & UDP for NAT64 at 
the second BEHAVE session. I don't know in which camp you were (if any). But 
I have to say that the only "reason" why someone would want to stick to TCP & 
UDP only, is to be able to re-use existing NAT44 implementations and extend 
them to do NAT64.

If that's the case, then they will NOT follow the BEHAVE specs (since most 
NAT44 don't), not even for UDP and TCP. Then why would NAT66 follow a 
would-be IETF RFC on NAT66 either?

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]