Re: [nat66] I-D Action:draft-mrw-nat66-00.txt

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
> nat66@ietf.org
> https://www.ietf.org/mailman/listinfo/nat66