Chris Engel wrote: > James, > > My impression is that there is considerable pressure in IETF to NOT > publish a standard for NAT66 ... or even discuss the potential utility of > this technology in the hopes that somehow ignoring it will make it less > likely for it to be utilized. I haven't followed this much recently, but my impression has been for several years (at least a decade) that IETF has a very strange attitude about NAT.
On one hand it's been reluctant to be honest about how much harm NATs cause - and I really mean that, the documents published to date are still glossing over a number of problems. On the other hand, it's been reluctant to develop any solution to the NAT problem that would raise the bar for NATs much at all. The assumption seems to be that we can't fix NATs, even in IPv6, so the problems that NATs cause have to be solved elsewhere in the network, or in applications. In other words, there's no attempt to resolve the tussle or even to make it explicit in the architecture. Failure to resolve this conflict is, in effect, a decision to prolong the tussle indefinitely - to continue the arms race between users and applications devleopers on one hand and network administrators and vendors of network equipment on the other - and to make IPv6 almost as dysfunctional as IPv4. To me this is the worst of the alternatives available. Either NATs in IPv6 should be discouraged in the strongest possible terms, or they should be required to implement an explicit, standardized mechanism to allow applications (with appropriate credentials) to explicitly maintain bindings and/or punch holes in them. (the PnP and NAT-PMP are tiny steps in the right direction, but need to be generalized and to support authentication so that hosts and apps can be issued credentials to allow them to do what they need). Personally I've become convinced that NATs between IPv4 and IPv6 are absolutely necessary for transition, that applications need to have explicit control of the bindings in such NATs in order to reasonably deal with them, and that the transition will last for a decade at least. Given that necessity, I think the more prudent course is to standardize an API for NATs in general. I don't like this conclusion, as NATs are still a huge mess even if you make them explicitly visible to applications and allow applications to maintain bindings. I'd love to be convinced otherwise. But from where I sit now, and after having looked at this problem for about 15 years, to me that currently looks like the best course of action. _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
