Re: Review of draft-ietf-v6ops-nap-02.txt

[Thomas Narten <narten@us.ibm.com>]

FWIW, I, without having done a complete review of the document or of
Margaret's comments, did look long enough to agree that more work is
needed. Specifically:

> > Abstract
> > 
> >     Although there are many perceived benefits to Network Address
> >     Translation (NAT), its primary benefit of "amplifying" available
> >     address space is not needed in IPv6.  In addition to NAT's many
> >     serious disadvantages, there is a perception that other benefits
> >     exist, such as a variety of management and security 
> > attributes that
> >     could be useful for an Internet Protocol site.  IPv6 does 
> > not support
> >     NAT by design and this document shows how Network Architecture
> >     Protection (NAP) using IPv6 can provide the same or more benefits
> >     without the need for NAT.
> > 
> > This abstract seems very slanted.  I also think that it would 
> > be incorrect at this point to say that "amplifying" address 
> > space is the primary benefit of NATs, as many companies use 
> > them in spite of the fact that they have plenty of address 
> > space available.
> > 
> > There are at least three other _real_ benefits of NAT boxes.  
> > While I hold with this document's position that these 
> > benefits can and should be realized in other ways in IPv6, I 
> > do not think it is factual or helpful to argue that they 
> > don't exist.  Those benefits are:
> > 
> > (1) Avoiding the reliance of internal network number on 
> > externally allocated numbers.  AKA not having to renumber 
> > when you change ISPs or when ISPs change address allocation 
> > strategies.

This is _so_ true. I then skimmed the document and the word
"renumbering" barely appears at all, and never mentions avoiding the
need to renumber as one of the real benefits of NAT. IMO, this
document is completely inadequate and unbalanced if it doesn't
recognize the clear value that NAT plays in the renumbering debate and
speak to that point directly.

Reading section 2 (the alleged benefits), I do not find the topic of
renumbering to be covered adequately.

Take section 2, entitled:

>    2.  Perceived Benefits of NAT and its Impact on IPv4 . . . . . . .  6

and section 2.5 in particular

> 2.5.  Independent Control of Addressing in a Private Network
> 
>    Many private IPv4 networks take benefit from using the address space
>    defined in RFC 1918 to enlarge the available addressing space for
>    their private network, and at the same time reduce their need for
>    globally routable addresses.  This type of local control of address
>    resources allows a clean and hierarchical addressing structure in the
>    network.
> 
>    Another benefit is due to the usage of independent addresses on
>    majority of the network infrastructure there is an increased ability
>    to change provider with less operational difficulties.
> 
>    Section 2.7 describes some disadvantages that appear if independent
>    networks using [RFC1918] addresses have to be merged.

The above seriously understates the issue of the renumbering problem
and how NATs play into that discussion.

Indeed the document later says:

> 4.7.  Multihoming and Renumbering
> 
>    Multihoming and renumbering remain technically challenging with IPv6
>    (see the Gap Analysis below).  

The WG needs to treat Margarat's review seriously. While the tone of
some of the comments may seem harsh, there is substance there. And
this document does have the problem of trying to blame "marketing" for
misperceptions about NAT's benefits. In fact, some of the benefits are
real (like avoidance of renumbering).

Another area I find weak is the discusion about NATs
vs. firewalls. E.g.:

>    Additionally, thanks to successful marketing campaigns it is
>    perceived by end users that their equipment is protected from the
>    malicious entities and attackers on the public IPv4 Internet.

Sorry, but it is true that firewalls do add protection. And suggesting
that the firewall function (not the NAT function) has no value
undermines the credibility of this document. (This document could do a
much better job of distinguishing between the NAT function and the
Firewall function, since they are not the same.)

Thomas