Thanks for the review. On Oct 26, 2010, at 7:52 PM, Brian E Carpenter wrote:
>> 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 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
