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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Jul 2006 13:20:00 +0200

Tony Hain wrote:
> Margaret, 
> 
> The text sent out on 6/13 was mid-edit session, basically looking to get
> comments about the tone changes wrt marketing. The completed edit is
> attached with the diff, though I have not passed this by the other authors
> yet.

I think this version is greatly improved.

     Brian

  I had planned to do that when I finished today, but your note appeared
> to need a prompt response so you all get it at once.  
> 
> I made a number of grammatical changes and reordered some areas to make the
> points clearer. Most of the marketing comments are gone, but in their place
> is a statement that points out that most users of nat do not evaluate the
> technical trade-offs and are not even made aware of the problems they will
> encounter. I also changed the tone in some areas from one of offering a
> choice between approaches to one that explains how those approaches work.
> The 'offer' tone appears to have left the IESG with the perception that the
> approaches were speculative.
> 
> One thing to highlight here though is that there appears to be an
> expectation that this document is a BCP, when all along it has been
> informational. If a BCP is the goal then substantial changes will be
> required. As information, it covers the range of approaches that people need
> to be aware of. 
> 
> The portability you reference below is not a nat feature. The only 'real'
> advantage to nat is the expansion of the address space. The reduction of
> impact on the routing system has more to do with insistence on ISP based
> aggregates that would go away with other aggregation units. Unfortunately
> people prefer a challenge and would rather engineer a non-deployable
> work-around to a problem-of-choice than discuss the fundamental issues or
> alternatives. 
> 
> I expect there will need to be some discussion in the WG to make sure it
> covers the issues before we present this to the IESG again, though I do
> believe it addresses all the comments.
> 
> Tony
> 
> 
> 
>>-----Original Message-----
>>From: Margaret Wasserman [mailto:[email-masked]]
>>Sent: Wednesday, June 28, 2006 12:40 PM
>>To: 'Tony Hain'; 'Fred Baker'; 'Tim Chown'
>>Cc: [email-masked]
>>Subject: RE: Review of draft-ietf-v6ops-nap-02.txt
>>
>>
>>
>>Hi Tony,
>>
>>
>>>I had done some updating before the last IESG call & round of
>>>comments. The working draft is attached along with a diff to
>>>the -02 version. As always comments are welcome. I am not
>>>sure this needs a WG slot, but if someone really wants one I
>>>am sure we can figure out which one of us can lead the
>>>discussion. Below are the comments I sent to the authors
>>>about the IESG discuss items.
>>
>>I think it might be useful to discuss the IESG comments in more depth,
>>either on the list or in the WG meeting.  I realize that you have made
>>changes to address some of the comments, but I think that the WG has to
>>decide what to do (if anything) about the substantive issues that you have
>>not yet addressed.
>>
>>
>>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
>>>w_comment&id=5
>>>2102
>>>I put in an arbitrary 50k number as a scale reference.
>>
>>50K is an order of magnitude higher than the analysis in Alex Zinin's
>>presentation would seem to indicate.  His presentation indicates that flat
>>routing will only scale to something on the order of 1K nodes.  Please
>>feel
>>free to check with Alex, though, as he certainly has more understanding of
>>IGP scaling than I do.
>>
>>
>>>That
>>>text could be expanded to discuss protocol specifics,
>>>topology, and churn rate as hinted by the reference, but that
>>>somewhat misses the point. "The technology does work with
>>>scale limitations", is the bullet that the IESG appears to be
>>>missing by essentially asking for a tutorial on igp
>>>engineering. It might be better to put in a range of
>>>something like 5k-50k to highlight the point that this is not
>>>a hard limit without having to discuss the details of why.
>>
>>If this document is going to recommend doing flat routing for topology
>>hiding, I think that the WG needs to do the analysis to determine that
>>this
>>is a valid and scalable technique.  I would prefer that we just took it
>>out
>>(perhaps considering a separate document to describe this technique if we
>>really think it is worthwhile), because this is an informational document
>>and I don't think it is the best place to specify a new operational
>>recommendation.  BUt,  if we do decide to leave it in, then we need to
>>document it in enough detail for readers to know when it is (and is not)
>>applcable.
>>
>>
>>>I did not expand on renumbering as Thomas requested. It is
>>>not clear to me what he wants beyond referencing rfc 4192.
>>>The second paragraph of 2.5 could be expanded, but that is
>>>not the focus of the section. The second paragraph of 2.7
>>>could be expanded, but would seem to loose context. It sounds
>>>like he wants a statement like 'renumbering is hard in IPv4'
>>>as justification for nat.
>>
>>NAT has real (not just perceived ormarketing-invented) advantages in the
>>area of address portability.  At this point, we do not have mechanisms in
>>IPv6 that provide a similar function although SHIM6 may help.
>>
>>
>>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
>>>w_comment&id=5
>>>1234
>>>This was covered by the edits, and additional background
>>>explanation was in the message I sent to the IESG on 5/26.
>>
>>Did you cc: the WG on that message?  I don't seem to have received it.
>>
>>You made several changes based on my review comments that look good to me.
>>Thank you!
>>
>>However, you don't seem to have addressed some of the concerns that were
>>raised in my review.  I realize that you don't agree with all of my review
>>comments, but some people did agree with them on the list.  I guess I'd
>>like
>>to see some further discussion before we simply decided that no changes
>>are
>>warranted based on these comments.
>>
>>In particular, I am still concerned about the following comments:
>>
>>(1) Thomas' comments on renumbering, combined with my comments on
>>providing
>>a more balanced view of the real benefits of NAT:
>>
>>
>>>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.
>>>
>>>(2) Hiding internal topology from external communicants.
>>>
>>>(3) Avoiding the establishment of unauthorized inbound connections.
>>>While this NAT side effect can also cause problems, it does provide
>>>the real benefits of a stateful firewall.
>>
>>(2) I think that this portion (in section 4.1) still needs some work.  Let
>>me know if I am missing something here:
>>
>>
>>>   It should be
>>>   noted that the address selection policy table in end-systems needs to
>>>   be correctly set up so that true global prefixes are distinguished
>>>   from ULAs and will be used for the source address in preference when
>>>   the destination is not a ULA.
>>>
>>>Unless one takes steps to actively screw this up, a globally routable
>>>destination address will always have a longest-prefix match with a
>>>globally routable source and a ULA will always have a longest-prefix
>>>match with a ULA.  So, the last sentence is unnecessary and somewhat
>>>misleading.
>>>
>>>The tricky part is making sure that the node uses the right destination
>>>address -- a ULA for local traffic and global address for non-local
>>>traffic.  This will generally require the use of some type of split DNS,
>>>with ULAs returned internally but not externally.
>>
>>(3) Although you made changes based on my comments on section 4.1, bullet
>>3,
>>you have not completely addressed by comment.  We are essentially
>>declaring
>>that something will not be a problem if the IIDs are randomly distributed
>>while ignoring the fact that they won't be.  If we are trying to indicate
>>that administrators should override the default mechanisms for IID
>>autoconfiguration to provide random IIDs, I guess we should say that.
>>Otherwise, we should understand that the IIDs will not be randomly
>>distributed, so the math later in this section does not apply.
>>
>>(4) Section 4.6 has been updated based on discussion, but it now says:
>>
>>   IPv6 provides sufficient space to completely avoid the need for
>>   overlapping address space with the total possible addresses being
>>   340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38).
>>   Since allocations in IPv6 are based on subnets rather than hosts a
>>   more reasonable way to look at the pool is that there are about
>>   17,293,822,569,102,704,640 (17*10^18) unique subnet values where
>>   sparse allocation practice within those provdes for new opportunities
>>   such as .
>>
>>The last sentence above is apparently truncated.
>>
>>(5) I still don't see any justification for this statement:
>>
>>
>>>  o  On a local network, any user will have more security awareness.
>>>
>>>IPv6 will make users more security-aware?  What does this mean?
> 
> 
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Jul 2006 19:50:18 +0100

On Fri, Jun 30, 2006 at 12:37:16PM -0700, Tony Hain wrote:
> Network Working Group                                    G. Van de Velde
> Internet-Draft                                                   T. Hain
> Expires: January 1, 2007                                        R. Droms
>                                                            Cisco Systems
>                                                             B. Carpenter
>                                                          IBM Corporation
>                                                                 E. Klein
>                                                      Tel Aviv University
>                                                            June 30, 2006
> 
> 
>                   IPv6 Network Architecture Protection
>                      <draft-ietf-v6ops-nap-03.txt>

Hi Tony,

Some comments on this nap-03 version follow.

Overall, it is a good and a very useful document.

The Informational nature of the document should be stressed (vs BCP).

I think my general comment would be that the proposed IPv6 tools all have
their own tradeoffs, just as deployment of IPv4 NAT is a tradeoff.   These
tradeoffs should be explicitly mentioned; I am not sure they are right now.

For example, privacy addresses have management issues (recognising hosts 
over time), as does using ULAs with globals ('bugs' in RFC3484).   Both 
need more operational experience and/or (minor) protocol fixes.   The topology
hiding solution has the biggest tradeoff, and that's probably why Margaret
has a bigger issue with that.   

In addition to the considering the tradeoffs, we need to have some 
operational experience from use of these proposals (to migrate the text to 
BCP one day), and hopefully that will come soon.

For many admins, the topology and privacy issues will not be important.  So
maybe there are different 'levels' of NAP that could be used, varying from
global addressing + firewall at the bottom then adding ULAs, RFC3041 and
topology hiding as additional features.

As an aside, if you defined IPv4 NAP, that would represent globals and 
firewalls; you could even do the host routing.   The advantage IPv6 has,
once proven, is the multi-addressing with ULAs and privacy addresses.

Inline comments:

   Indeed, product marketing departments have
   effectively driven a perception that some connectivity and security
   concerns can only be solved by using a NAT device, without any
   mention of the negative impacts on applications. 

=> Isn't the main benefit is ease of deployment, for the typical home user?
   And wasn't the word 'marketing' being removed throughout the doc?

   header modification feature of NAT in an IPv6 network.  It should be
   noted that this document is 'informational', as it discusses
   approaches that will work to accomplish the goals.  It is
   specifically not a BCP that is recommending any one approach.

=> This is hidden too well (see main comments :)

   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).

=> Are points 1-3 discussed later in the context of NAP?   If those points 
   add value for NAT, NAP should be stated to match them.

   +------------------|-----------------------|-----------------------+
   |  Addressing      |  RFC 1918             |  RFC 3177 & 4193      |
   |  Autonomy        |  see section 2.5      |  see section 4.5      |
   +------------------|-----------------------|-----------------------+

=> RFC 4193 isn't mentioned in section 4.5?

   +------------------|-----------------------|-----------------------+
   |  Global Address  |  RFC 1918             |  17*10^18 subnets     |
   |  Pool            |  << 2^48 application  |  3.4*10^38 addresses  |
   |  Conservation    |  end points           | full port list / addr |
   |                  |  topology restricted  | unrestricted topology |
   |                  |  see section 2.6      |  see section 4.6      |
   +------------------|-----------------------|-----------------------+

=> Make the numbers explicit?  Where do they come from?

   +------------------|-----------------------|-----------------------+
   |  Renumbering and |  Address translation  |  Preferred lifetime   |
   |  Multi-homing    |  at border            |  per prefix & Multiple|
   |                  |                       |  addresses per        |
   |                  |                       |  interface            |
   |                  |  see section 2.7      |  see section 4.7      |
   +------------------+-----------------------+-----------------------+

=> Anyone for 8+8? :)

   Wide-scale deployments have shown that using NAT to act as a simple
   gateway attaching a private IPv4 network to the Internet is simple
   and practical for the non-technical end user.  Frequently a simple
   user interface, or even a default configuration is sufficient for
   configuring both device and application access rights.

=> Therefore IPv6 gateways must be simple to deploy too.  Maybe the document
   needs a new section that is simply "Simple to Deploy"?   Then you could
   discuss how simple it is to manage a stateful firewall, or to negotiate
   firewall traversal for apps (as opposed to NAT traversal).

2.2.  Simple Security due to Stateful Filter  Implementation

   This benefit
   may be partially real, however, experienced hackers are well aware of
   NAT devices and are very familiar with private address space, and
   have devised methods of attack (such as trojan horses) that readily
   penetrate NAT boundaries.  For these reasons the sense of security
   provided by NAT is actually an illusion.

=> Which applies to IPv6, or IPv4 with globals used.   The question is 
   more whether the address and port manipulation provides security,
   and you answer that question anyway.

   In some cases, NAT operators (including domestic users) may be
   obliged to configure quite complex port mapping rules to allow
   external access to local applications such as a multi-player game or
   web servers.  In this case the NAT actually adds management
   complexity compared to a simple router.  In situations where two or
   more devices need to host the same application or otherwise use the
   same public port this complexity shifts from difficult to impossible.

=> Maybe some operators want NAT for 'walled gardens'.   But that's a 
  'political' statement maybe best avoided?

   Some network managers prefer to hide as much as possible of their
   internal network topology from outsiders as a useful precaution to
   mitigate scanning attacks.  Mostly this is achieved by blocking
   "traceroute" etc., though NAT entirely hides the internal subnet
   topology.  Scanning is a particular concern in IPv4 networks because
   the subnet size is small enough that once the topology is known it is
   easy to find all the hosts, then start scanning them for vulnerable
   ports.  Once a list of available devices has been mapped, a port-scan
   on these IP addresses can be performed.  

=> Are IPv4 networks really that sparsely populated for that to matter?

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 sufficiently large pool for a clean and
   hierarchical addressing structure in the local 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.

=> Maybe spell out that internal comms can keep working while renumbering
   or disconnected.   But this section also true because typically a NAT
   network has clients accessing external servers, and not vice-versa.

   The number of and types of applications that can be deployed by these
   ISPs and their customers is restricted by the ability to overload the
   port range on the public side of the most public NAT in the path.
   The limit of this approach is something substantially less than 2^48
   possible active **application** endpoints (approximately [2^32 minus
   2^29] * [2* 2^16 minus well known port space]), as distinct from
   addressable devices each with their own application endpoint range.

=> Expand on the working?  Not clear where the numbers come from, as per
   the same comment earlier.

   The reader must clearly distinguish between features of IPv6 that
   were fully defined when this document was drafted and those that were
   potential features that still required more work to define them.  The
   latter are summarized later in the 'Gap Analysis' section of this
   document.  However, we do not distinguish in this document between
   fully defined features of IPv6 and those that were already widely
   implemented at the time of writing.

=> It's not just about what's defined, but also what we have operational
   experience of, and tradeoffs in using the tools.   For example, using
   Privacy Addresses is fine, but has a price (management complexity).

3.1.  Privacy Addresses (RFC 3041)

   As originally defined, IPv6 stateless address auto-configuration
   (SLAAC) will typically embed the IEEE Link Identifier of the
   interface as the IID part, though this practice facilitates tracking
   and profiling of a device through the consistent IID.  RFC 3041 [7]
   describes an extension to SLAAC to enhance device privacy.  Use of

=> Maybe 'add' not 'enhance'?

   the privacy address extension causes nodes to generate global-scope
   addresses from interface identifiers that change over time,
   consistent with system administrator policy.  Changing the interface
   identifier (thus the global-scope addresses generated from it) over
   time makes it more difficult for eavesdroppers and other information
   collectors to identify when addresses used in different transactions
   actually correspond to the same node.  A relatively short valid
   lifetime for the privacy address also has the side effect of reducing
   the attack profile of a device, as it is not directly attackable once
   it stops answering at the temporary use address.

=> Maybe note the Privacy Address is only used for initiating outbound
   connections; a node receiving connections inbound is likely to have
   a separate global address, which is probably DNS-advertised.

3.2.  Unique Local Addresses

   o  In practice, applications may treat these addresses like global
      scoped addresses but address selection algorithms may need to

=> Actually they *have* global scope?  See 3.3 of the ULA RFC.

   The main goal of untraceable IPv6 addresses is to create an
   apparently amorphous network infrastructure as seen from external
   networks to protect the local infrastructure from malicious outside
   influences and from mapping of any correlation between the network
   activities of multiple devices from external networks.  When using
   untraceable IPv6 addresses, it could be that two apparently
   sequential addresses are allocated to devices on very different parts
   of the local network instead of belonging to devices adjacent to each
   other on the same subnet.

=> As per the Network Scanning draft, I'd avoid sequential addresses,
   rather emphasising the obfuscation of topology at the subnet view as 
   the important thing?

   These should be globally routable IPv6 addresses which can be
   randomly and independently assigned to IPv6 devices.  The random
   assignment is intended to mislead the outside world about the
   structure of the local network.  However the local network needs to
   maintain a correlation between the location of the device and the
   untraceable IPv6 address.  For smaller deployments this correlation
   could be done by generating IPv6 host route entries, or for larger
   ones by utilizing an indirection device such as a Mobile IPv6 Home
   Agent.  Additional details are in section 4.7.

=> This mapping may have some of the state complexity of NAT?

=> It may be that this is only needed for a part of a site, not all of it?
   So a 50,000 node site may only want to hide certain parts, and a few
   hundred nodes?

4.  Using IPv6 Technology to Provide the Market Perceived  Benefits of
    NAT

=> Delete 'Market'?

   With external connectivity the simple gateway should use DHCP-PD to
   acquire a routing prefix from the service provider for use when
   connecting to the global Internet.  End-system connections involving
   other nodes on the global Internet will always use the global IPv6
   addresses derived from this prefix delegation.  It should be noted
   that the address selection policy table in end-systems defined in RFC
   3484 should be configured to prefer the ULA prefix range over the
   DHCP-PD prefix range when the goal is to keep local communications
   stable during periods of transient external connectivity.

=> So are you advocating ULAs and globals in parallel?  There are again
   costs here (tradeoffs), e.g. possibly running split-view DNS, and
   the 3484 'bugs' described in v6ops this week.  The gotchas cited in
   the 'Deprecating Site Locals' text need to be carefully considered
   still, even with ULAs. 

   3.  The size of the address space of a typical subnet (64 bits of
       IID) will make a complete subnet ping sweep virtually impossible
       due to the potential number of combinations available.  Reducing

=> Change 'virtually impossible' to 'computationally difficult'?

   Assuming the network administrator is aware of [19] the increased
   size of the IPv6 address will make topology probing much harder, and
   almost impossible for IPv6 devices. 

=> Ditto on 'impossible'.

   IPv4 NAT was not developed as a security mechanism.  Despite
   marketing messages to the contrary it is not a security mechanism,
   and hence it will offer some security holes while many people assume
   their network is secure due to the usage of NAT.  IPv6 security best
   practices will avoid this kind of illusory security but can only
   address the same threats if correctly configured firewalls and IDS
   systems are used at the perimeter.

            It must be noted that even a firewall doesn't fully secure
            a network. Many attacks come from inside or are at a layer
            higher than the firewall can protect against. In the final
            analysis, every system has to be responsible for its own
            security, and every process running on a system has to be
            robust in the face of challenges like stack overflows etc.
            What a firewall does is prevent a network administration
            from having to pay for bandwidth to carry unauthorized
            traffic, and in so doing reduce the probability of certain
            kinds of attacks across the protected boundary.

=> So maybe separate the network security here from application security
   more explicitly.   Focus on the pros/cons of the bit manipulations?

   reflective session state).  There should also be an easy interface
   which allows users to create inbound 'pinholes' for specific purposes
   such as online-gaming.  Another consideration would be the capability
   for service provider mediated pinhole management where things like
   voice call signaling could dynamically establish pinholes based on
   predefined authentication rules.

=> Here you mean firewall traversal not NAT traversal?  I think there is
   a difference worth making.  The problem is shifted, but there.

   IPv6 enables the collection of information about data flows.  Due to
   the fact that all addresses used for Internet and intra-/inter- site
   communication are unique, it is possible for an enterprise or ISP to
   get very detailed information on any communication exchange between
   two or more devices.  This enhances the capability of data- flow
   tracking for security audits compared with IPv4 NAT, because in IPv6
   a flow between a sender and receiver will always be uniquely
   identified due to the unique IPv6 source and destination addresses.

=> Again, there's a tradeoff here that's not mentioned.

   Due to the large IPv6 address space available there is plenty of
   freedom to randomize subnet allocations.  By doing this, it is
   possible to reduce the correlation between a subnet and its location.
   When doing both subnet and IID randomization [RFC 3041] a casual
   snooper won't be able to deduce much about the networks topology.

=> A tradeoff here is lack of aggregation, with scalability implications
   for routing tables, but also implications if you want to renumber or
   restructure parts of your network.

   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

=> As Margaret says, I think the tradeoff here is significant.

   o  Another technical approach to fully hide the internal topology is
      use of a tunneling mechanism.  Mobile IPv6 without route
      optimization is one approach for using an automated tunnel, as it
      always starts in tunnel mode via the Home Agent (HA).  In this

=> As it is here.  

4.5.  Independent Control of Addressing in a Private  Network

   IPv6 provides for autonomy in local use addresses through ULAs.  At

=> Do we mention PI proposals here, or leave that out?

4.6.  Global Address Pool Conservation

   IPv6 provides sufficient space to completely avoid the need for
   overlapping address space.  Since allocations in IPv6 are based on
   subnets rather than hosts a reasonable way to look at the pool is
   that there are about 17*10^18 unique subnet values where sparse
   allocation practice within those provides for new opportunities such
   as SEND 3971 [12].  

=> Maybe say 2^n, which is... i.e. show the working in getting to that number.

5.1.  Medium/large private networks

   The majority of private enterprise, academic, research, or government
   networks fall into this category.  Many of these networks have one or
   more exit points to the Internet.  Though these organizations have
   sufficient resources to acquire addressing independence when using
   IPv4 there are several reasons why they might choose to use NAT in
   such a network.  For the ISP there is no need to import the IPv4
   address range from the remote end-customer, which facilitates IPv4
   route summarization.  The customer can use a larger IPv4 address
   range (probably with less-administrative overhead) by the use of RFC
   1918 and NAT.  The customer also reduces the overhead in changing to
   a new ISP, because the addresses assigned to devices behind the NAT
   do not need to be changed when the customer is assigned a different
   address by a new ISP.  By using address translation in IPv4 one
   avoids the expensive process of network renumbering.  Finally, the
   customer can provide privacy for its hosts and the topology of its
   internal network if the internal addresses are mapped through NAT.

=> Do we need to try to suggest using all the bells and whistles here?
   For most sites, maybe using IPv6 and stateful firewalling is enough;
   maybe they don't care about privacy addresses or topology hiding?

5.2.  Small Private Networks

   For the DHCPv6-PD solution, a dynamic address allocation approach is

=> Do you mean dynamic or automatic?

   chosen.  By means of the enhanced DHCPv6 protocol it is possible to
   have the ISP push down an IPv6 prefix range automatically towards the
   small private network and populate all interfaces in that small
   private network dynamically.  This reduces the burden for
   administrative overhead because everything happens automatically.

=> Maybe some customers will want a random prefix each time (for better
   privacy than 3041)?  I wouldn't personally, but some will I'm sure.

6.1.  Simple Security

   Dynamic pinhole management is an area for further study.  Several
   partial solutions exist including ICE, UPNP, as well as alternative
   proposals for Service Provider based control.  The 'simple' aspect of
   the security provided by a stateful firewall will require some degree
   of automation to mask the technical complexity from the consumer that
   only wants a secure environment with working applications.

=> This is firewall traversal rather than NAT traversal?

8.  Security Considerations

   While issues which are potentially security related are discussed
   throughout the document, the approaches herein do not introduce any
   new security concerns.  Product marketing departments have widely

=> 'Marketing' used again?

   This document defines IPv6 approaches which collectively achieve the
   goals of the network manager without the negative impact on
   applications or security that are inherent in a NAT approach.  To the
   degree that these techniques improve a network manager's ability to
   explicitly audit or control access, and thereby manage the overall
   attack exposure of local resources, they act to improve local network
   security.  In particular the explicit nature of a content aware
   firewall in NAP will be a vast security improvement over the NAT
   artifact where lack of translation state has been widely sold as a
   form of protection.

=> Well, a NAT firewall *could* also be 'content aware' (do you mean an 
   IDS function here?)

   This document has described a number of techniques that may be
   combined on an IPv6 site to protect the integrity of its network
   architecture.  These techniques, known collectively as Network
   Architecture Protection, retain the concept of a well defined
   boundary between "inside" and "outside" the private network, and
   allow firewalling, topology hiding, and privacy.  However, because
   they preserve address transparency where it is needed, they achieve
   these goals without the disadvantage of address translation.  Thus,
   Network Architecture Protection in IPv6 can provide the benefits of
   IPv4 Network Address Translation without the corresponding
   disadvantages.

=> But there are other disadvantages, or tradeoffs.   Maybe this can be
   made into another general table?

=> Appendix A maybe repeats information in the main document.  Does this     
   matter?

--
Tim