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 RD
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
