Hi Keith, Keith Moore wrote: > 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).
There's already work and running code in the IETF to do that: NAT/FW NSLP was developed within the NSIS WG for exactly this purpose, http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-20 However, this 2nd option comes at the extra cost of such signaling. > 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. Maybe you could take a look at the NATFW draft: it's probably exactly what you meant. > 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 Yep. > 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. The thing is that if we standardize NAT for v6 it will probably just get deployed widely, because it's there and network admins got used to it, as underlined by Chris' mail. Maybe NAT offers some benefits in some scenarios, and it would be nice if it is only used as an exception. However, restricting NAT use to only some exceptions will probably not work. So providing alternative solutions along the lines of RFC 4864 would be better. Regards, Roland _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
