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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2010 15:52:02 +1300

> 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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 27 Oct 2010 07:02:24 -0400

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:

> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 05:14:31 -0700

Thanks for the review.