[no subject]

[Margaret Wasserman <margaret@thingmagic.com>]

Hi All,

I've reviewed the latest NAP document, draft-ietf-v6ops-nap-04.txt,
and I found the document to be greatly improved over the previous
version.  Most of my issues have been addressed, including all of my
most serious issues.

I think that the document now does a good job of communicating a
very important message.

I do still have some comments (including a few substantive ones) on
the new draft, but I think it is very close to ready for  
publication.  I've
included my comments below along with some document context.
My editorial comments are marked with "[Editorial]" and substantive
comments are marked with "[Substantive]".  Although the RFC Editor
will generally deal with editorial issues, it is unclear enough how
to solve a couple of these issues  that I would  recommend another
editorial pass before this document is approved.

Jari, please look over my comments below and make your own decision
about whether to continue to hold a discuss based on these issues.
Although I would like to see one more clean-up pass, I would
certainly understand if you'd rather call it "good enough" at this
point.

Margaret

---

>1.  Introduction
>
>   There have been periodic claims that IPv6 will require a Network
>   Address Translation (NAT), because with IPv4 people use NAT to
>   accomplish that person's preferred task.

[Editorial] What person?  Perhaps change to:

   There have been periodic claims that IPv6 will require Network
   Address Translation (NAT), because IPv4 network administrators
   use NAT to meet a variety of needs that will also need to be
   met when using IPv6.

>   This document will explain
>   why those pronouncements are false by showing how to accomplish the
>   task goal without address translation.

[Editorial] s/pronouncements/claims
[Editorial] s/the task goal/those goals

[Editoral] Start new paragraph.

>   Although there are many
>   perceived benefits to NAT, its primary benefit of "amplifying"
>   available address space is not needed in IPv6.  The serious

>   This document describes the goals for utilizing a NAT device in an
>   IPv4 environment that are regularly cited as solutions for  
perceived
>   problems.

[Editorial] Goals cannot be cited as solutions for perceived problems,
can they?  How about:

     This document describes the goals that are commonly met in IPv4
     networks through the use of NAT.

>   It then shows how these needs can be met without using the

[Editorial] s/needs/goals

>   Another consideration discussed is the view that NAT can be used to
>   fulfill the goals of a security policy.  At a technical level the
>   translation process fundamentally can not produce security because
>   mangling the address in the header does not fulfill any useful
>   security functions;

[Substantive] Later on, you talk about the value of all nodes
appearing to be at the edge of the network, hiding the internal
topology from attackers and you propose a solution to provide the
same type of protection in IPv6.  That is inconsistent with this
paragraph, so I'd suggest that you remove this paragraph.

>   in fact it breaks the ability to produce an audit
>   trail which is a fundamental security tool.  That said, the  
artifacts
>   of NAT devices do provide some value.
>
>   1.  The need to establish state before anything gets through from
>       outside to inside solves one set of problems.
>   2.  The need to stop receiving any packets when finished with a  
flow
>       solves a set of problems
>   3.  the need to appear to be attached at the edge of the network
>       solves a set of problems
>   4.  and the ability to have addresses that are not publicly routed
>       solves yet another set (mostly changes where the state is and
>       scale requirements for the first one).

[Editorial/maybe Substantive] The content of this list is very  
confusing.
According to the previous paragraph, this would seem to be a list of the
ways in which NATs provide value.

The first bullet is okay, as NAT requires that users establish state
before anything comes in from the outside, and the last bullet is
also okay, as NATs provide the ability to use non-publicly routed
addresses.  But the other bullets make less sense.  NATs do not impose
"the need to stop receiving packets" or "the need to appear attached to
the edge of the network".

You could instead say something like

     2. NAT state expirations stops allowing inbound connections
         after an application completes, which solves a set of  
problems.
     3. Making all nodes appear as though they are attached at
         the edge of the network solves a set of problems.



>          Goal                 IPv4                    IPv6
>   +------------------+----------------------- 
+-----------------------+
>   | Simple Gateway   |  DHCP - single        |  DHCP-PD -  
arbitrary  |
>   | as default router|  address upstream     |  length  
customer      |
>   | and address pool |  DHCP - limited       |  prefix  
upstream      |
>   | manager          |  number of individual |  SLAAC via  
RA         |
>   |                  |  devices downstream   |   
downstream           |
>   |                  |  see section 2.1      |  see section  
4.1      |
>    
+------------------|-----------------------|-----------------------+

[Editorial] Define SLAAC before use.

>   o  One approach uses explicit host routes in the IGP to remove the
>      external correlation between physical topology attachment point
>      and end-to-end IPv6 address.  In the figure below the hosts  
would
>      be allocated prefixes from one or more logical subnets, and  
would
>      inject host routes to internally identify their real attachment
>      point.  This solution does however show severe scalability  
issues
>      and requires hosts to securely participate in the IGP, as  
well as
>      having the firewall block all external to internal traceroute  
for
>      the logical subnet.  The specific limitations are dependent  
on the
>      IGP protocol, the physical topology, and the stability of the
>      system.  In any case the approach should be limited to uses with
>      substantially fewer than the maximum number of routes that  
the IGP
>      can support (generally between 5,000 and 50,000 total entries
>      including subnet routes).  Hosts should also listen to the  
IGP for
>      duplicate use before finalizing an interface address  
assignment as
>      the duplicate address detection will only check for use on the
>      attached segment, not the logical subnet.

[Substantive]  This is a _much_ improved description of this mechanism.
However, I am still of the opinion that an informational document is not
the right place to define a new untraceable addressing mechanim.

[Editorial] Including the picture after all three bullets makes it  
unclear
which mechanism is pictured.  Maybe re-order to put this one last, or
add a sentence to make it clearer which is pictured?

>   o  On a local network, any user will have more security awareness.
>      This awareness will motivate the usage of simple firewall
>      applications/devices to be inserted on the border between the
>      external network and the local (or home network) as there is no
>      Address Translator and hence no false safety perception.

[Substantive] IPv6 will not make users have more security awareness.
When we say something like this, we are emitting the same type of
marketing hype that we deride in the vendors of NAT products.  This
bullet should just be omitted.

[Editorial] Although all but one of the specific problems I had with the
text in Appendix A have been fixed, I am still not sure why an
appendix on the benefits of IPv6 belongs in this document.