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

[Margaret Wasserman <[e-mail]>]

Thanks, Brian!

I will make your suggested changes and look into the v6ops simple  
security spec.

Margaret


On Oct 26, 2010, at 10: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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nat66