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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 27 October 2010 02:50 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=VrN/vKjwoobZ5DsUSYvFdIZBXRUqL2syJWfHmLmDIefhm8TN9PZU176nYqSet284AA fZh6oujO1wGHq5djEw5hHkuqA7/IJ0Sds7BBA5PHZaoMh47fISbqbKr567l/gvgDEhdb EjIE2YrmGOkWUia18ZsJVR4RPkxuPr3MIxvNw=
Message-ID: <4CC793D2.5050209@gmail.com>
Date: Wed, 27 Oct 2010 15:52:02 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: nat66@ietf.org
References: <20101018190002.323803A6D0B@core3.amsl.com>
In-Reply-To: <20101018190002.323803A6D0B@core3.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [nat66] I-D Action:draft-mrw-nat66-00.txt
Precedence: list

> 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

Re: [nat66] I-D Action:draft-mrw-nat66-00.txt Brian E Carpenter
Re: [nat66] I-D Action:draft-mrw-nat66-00.txt Margaret Wasserman
Re: [nat66] I-D Action:draft-mrw-nat66-00.txt Fred Baker