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