> Abstract > > This document describes a stateless, transport-agnostic IPv6-to-IPv6 > Network Address Translation (NAT66) function that provides the > address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) > while minimizing, but not completely eliminating, the problems > associated with NAT44.
I think "minimizing" is a bit strong, How about "mitigating"? (Same comment in the Introduction.) > 3. What is Address Independence? ... > The use of IPv6 Provider Independent (PI) addresses has also been > suggested as a means to fulfill the address independence requirement. > However, this solution requires that an enterprise qualify to receive > a PI assignment and persuade their ISP to install specific routes for > the enterprise's PI addresses. There are a number of practical > issues with this approach, especially if there is a desire to route > to a number of geographically and topologically diverse set of sites, > which can sometimes involve coordinating with several ISPs to route > portions of a single PI prefix. These problems have caused numerous > enterprises with plenty of IPv4 swamp space to choose to use IPv4 NAT > for part, or substantially all, of their internal network instead of > using their provider-independent address space. Somehow you get through this without mentioning that generalised use of PI prefixes will explode the BGP4 routing system in its present form. I think that deserves mention (perhaps with a reference to draft-irtf-rrg-recommendation). > 4. NAT66 Applicability ... After the discussion of DNS issues, can you add something about the impact on 3rd party referral issues? We don't actually discuss NAT66 as part of the problem in draft-carpenter-referral-ps, but maybe we should. > Prefix = 2001:0DB8:0001:/48 Everywhere you have a prefix, it ends :/48 instead of ::/48 > 9. Address Mapping for Longer Prefixes > > In some cases, it may desireable to use NAT66 with global prefixes > longer than /48. I think it would be better to say "unavoidable" instead of "desirable". And maybe add: longer than /48, but at the longest /64. > 13. Security Considerations ... > For this reason, it is > RECOMMENDED that NAT66 devices include an IPv6 firewall function, and > the firewall function SHOULD be configured by default to block all > incoming connections. Administrators could then enable inbound > connectivity for specific ports by reconfiguring the firewall. A reference to draft-ietf-v6ops-cpe-simple-security would be appropriate here. Strictly, if any of the default recommendations in that spec are inappropriate for NAT66, it would be good to override them explicitly. Regards Brian Carpenter _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
