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

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2006 09:05:56 -0700

FYI. Margaret's original message seems to have not made it to v6ops,  
or at least through it to me and reportedly several of you.

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] On Behalf Of
Margaret Wasserman
Sent: Wednesday, May 24, 2006 7:06 PM
To: [email-masked]'; [email-masked]'
Subject: Review of draft-ietf-v6ops-nap-02.txt

Hi All,

I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number of serious
issues with the document.  I realize that the Last Calls have already
completed and that this document is on the agenda for this week's IESG
telechat, but I consider these issues to be serious enough that they are
worth raising as late objections.

I think that there is a serious problem with the way this document  
describes
existing NAT technology.  There are significant issues with the tone  
of this
document, which is arrogant and argumentative.  I also believe that the
document contains several factual mistakes and some potentially damaging
recommendations.  In addition to resolving my review comments, I would
suggest that the document shepherd request a technical review from  
members
of the Transport area who focus on NAT-related technologies.

While there are some strong technical points in this document, I  
think that
they are severely weakened by the length of the document and the  
level of
IPv6 marketing hype included in a document that is simultaneously  
bashing
NAT providers for exactly this sort of behaviour.  Little of this hype,
including the entire appendix, is actually operational advice of any  
kind,
and I don't know why the IETF would want to publish it.  There are  
already
existing groups that market IPv6, and I think that it is outside the  
scope
of the IETF to do so.

The authors also seem to have inserted quite a bit of their own  
religion,
and I think that there are large parts of this document that do not even
come close to expressing IETF consensus on various topics like NAT  
features,
the usefulness of firewalls, appropriate use of the IGP routing  
practices,
etc.  It seems unlikely that this document has received adequate  
review from
people in these areas.

In other words, I think that some of the contents of this document  
and the
current editorial style make it unsuitable for publication as an RFC.

Specific comments are included below, along with the document exerpts  
that
they refer to.

Margaret

---

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.

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

1.  Introduction

    Although there are many perceived benefits to Network Address
    Translation (NAT), its primary benefit of "amplifying" available
    address space is not needed in IPv6.  The serious disadvantages of
    ambiguous "private" address space and of Network Address Translation
    (NAT) [1][5] have been well documented [4][6].  However, given its
    wide market acceptance NAT undoubtedly has some perceived benefits.
    Indeed, in an Internet model based on universal any-to-any
    connectivity, product marketing departments have driven a perception
    hat some connectivity and security concerns can only be solved by
    using a NAT device or by using logically separated Local Area  
Network
    (LAN) address spaces.  This document describes the reasons for
    utilizing a NAT device in an IPv4 environment that are regularly
    cited in marketing pronouncements.  It then shows how these needs  
can
    be met without using NAT in an IPv6 network.  Some of the IPv6
    solutions offer advantages beyond the equivalent IPv4 NAT solution.
    The use of the facilities from IPv6 described in this document  
avoids
    the negative impacts of address translation.

I don't understand, at all, the mentione of "marketing departments"
and "marketing pronouncements" in this section and think it should be
reworded to remove them and/or cite specific documents.  There are real
reasons why people use NATs in IPv4, and there are better ways to do  
those
things with IPv6.  That's what we should say.  The text in the above
paragraph is insulting, incorrect and very likely to get the network
administrator to stop reading before you can offer any advice on how to
set-up an IPv6 network.

2.  Perceived Benefits of NAT and its Impact on IPv4

    This section provides insight into the generally perceived benefits
    of the use of IPv4 NAT as extolled by product marketing.  The  
goal of

Again with the "product marketing".  Do the authors of this document  
really
believe that these benefits do not exist?  Does the IETF as a whole?  I
think we should be somewhat embarrassed to publish this document as-is,
because it seems very naive and one-sided.  This continues throughout  
the
document, but I will not continue to mention it.

2.2.  Simple Security due to Stateful Filter Implementation

    A firewall doesn't fully secure a network, because 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.

This is the section where we are describing the benefits of NAT without
analyzing them.  So, why is this sub-section here?  It is clear that the
side effects of NAT can be used as one element of a system to protect
internal nodes.  It is not sufficient to protect them from  
everything, which
doesn't mean that it doesn't protect them against anything.  Much of  
this
section could appear to be an argument that firewalls of all kinds are
useless because of the existence of Trojan Horse-style attacks, which is
obviously false.  Have any firewall experts been asked to review this
section?  If not, I think you should ask someone like Steve Bellovin  
to do
so.

2.3.  User/Application tracking

    Although NATs create temporary state for active sessions, in general
    they provide limited capabilities for the administrator of the  
NAT to
    gather information about who in the private network is requesting
    access to which Internet location.  This could in theory be done by
    logging the network address translation details of the private and
    the public addresses from the NAT device's state database.

    The checking of this database is not always a simple task,  
especially
    if Port Address Translation is used.  It also has an unstated
    assumption that the administrative instance has a mapping between an
    IPv4-address and a network element or user at all times, or the
    administrator has a time-correlated list of the address/port
    mappings.

I think that this document is arguing that User/Application tracking  
is not
a benefit of NAT?  If so, why is it even in this document?

2.4.  Privacy and Topology Hiding

    The goal of 'topology hiding' is to provide devices on the private
    network with an identifier (IPv4 address) which an entity outside  
the
    network can use to communicate with or to reference the private
    network devices in protocols but prevents the external entity making
    a correlation between the topological location of the private device
    and the address on the local network.

The above sentence does not parse (editorial).

    The use of NAT then results in a user behind a NAT gateway actually
    appearing on the Internet as a user inside the NAT box itself; i.e.,
    the IPv4 address that appears on the Internet is only sufficient to
    identify the NAT.  When concealed behind a NAT it is impossible to
    tell from the outside which member of a family, which customer of an
    Internet cafe, or which employee of a company generated or  
received a
    particular packet.  Thus, although NATs do nothing to provide
    application level privacy, they do prevent the external tracking and
    profiling of individual host computers by means of their IP
    addresses, usually known as 'device profiling'.  At the same time a
    NAT creates a smaller pool of addresses for a much more focused  
point
    of attack.

What does the last sentence mean?  Give some sort of example or take  
it out,
perhaps?

3.4.  Untraceable IPv6 Addresses

    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.  This correlation could be done by
    generating IPv6 host route entries or by utilizing an indirection
    device such as a Mobile IPv6 Home Agent.

Is not technically sound to advocate the dissemination of host routes  
in the
IGP for infrastructure hiding.  IGPs are not designed to scale well  
for this
sort of use.  It would be much more technically sound to advocate the  
use of
L2 switching to avoid exposure of network topology at L3.

Besides, I thought the point of network address hiding (or one of  
them), as
outlined above was to avoid the ability to identify different nodes by
address for port scanning purposes, not (merely) to avoid the ability to
tell what subnets they are on.  The proposed technique doesn't seem to
address that issue at all.

    With external connectivity the simple gateway could also 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 [9] derived from this prefix delegation.  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 completely 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.

    In the very simple case there is no explicit routing protocol and a
    single default route is used out to the global Internet.  A slightly
    more complex case might involve local routing protocols, but with  
the
    entire local network sharing a common global prefix there would  
still
    not be a need for an external routing protocol as a default route
    would continue to be consistent with the connectivity.

I don't understand this paragraph at all.  What does it have to do with
ULAs?  Also, the second half of this sentence doesn't make sense.
I'm not 100% sure what it means, but if it means what I think it  
means, it
is wrong.

4.2.  IPv6 and Simple Security

    The vulnerability of an IPv6 host is similar to that of an IPv4 host
    directly connected towards the Internet.  The use of firewall and
    Intrusion Detection Systems (IDS) is recommended.  A proxy may be
    used for certain applications, but with the caveat that the end to
    end transparancy is broken.  However, with IPv6, the following
    protections are available without the use of NAT while maintaining
    end-to-end reachability:
    1.  Short lifetimes on privacy extension suffixes reduce the attack
        profile since the node will not respond to the address once the
        address is no longer valid.
    2.  IPsec is a mandatory service for IPv6 implementations.  IPsec
        functions to prevent session hijacking, prevent content
        tampering, and optionally masks the packet contents.  While  
IPsec
        might be available in IPv4 implementations, deployment in NAT
        environments either breaks the protocol or requires complex
        helper services with limited functionality or efficiency.

IPsec performs exactly the same purposes in IPv4 as IPv6.  I don't  
know of
any stacks that implement IPsec for IPv6 and not for IPv4.
Also, it is not clear that end-to-end IPsec is fundamentally useful,  
even
without the interference of a NAT box, as I believe that there needs  
to be
some sort of binding to the upper layer protocol in order for IPsec to
provide these protections.

If you decide to keep this section, you should acknowledge that use  
of the
IPv6 stateful firewall mechanisms advocated in bullet 3 will present  
similar
obstacles to using IPsec.

    3.  The size of the address space of a typical subnet (64 bits of
        IID) will make an effective network ping sweep and resulting
        port-scan virtually impossible due to the number of possible
        combinations available, provided that IIDs are essentially
        randomly distributed across the available space.

IIDs will not be randomly distributed.  They are based on EUI-64 IDs  
which
are certainly not randomly distributed.  In fact, on Ethernet 16 of the
64-bits will have a known value.  Also, the numbering space for the  
first
three bytes (24-bits) is not completely allocated and there is very  
clearly
an unbalanced distribution in that space.  The fact that companies  
tend to
buy somewhat homogenous hardware can make it possible to guess which
three-byte combinations are most likely to be present within a given
company.  So, the length of the IID offers nowhere near the level of
protection described above.

        This protection is nullified if the attacker has no access to a
        local connection.  If an attacker has local access then he
        could use ND [3] and ping6 to ff02::1 to detect local
        neighbors.  (Of course, a locally connected attacker has many
        scanning options with IPv4 as well.)  It is recommended for
        site administrators to take [18] into consideration to achieve
        the expected goal.  This protection will also be nullified if
        IIDs are configured in a group near the start of the IID space.

    Assuming the network administrator is aware of [18] the increased
    size of the IPv6 address will make topology probing much harder, and
    almost impossible for IPv6 devices.  The intention of topology
    probing is to identify a selection of the available hosts inside an
    enterprise.  This mostly starts with a ping-sweep.  Since the IPv6
    subnets are 64 bits worth of address space, this means that an
    attacker has to send out a simply unrealistic number of pings to map
    the network, and virus/worm propagation will be thwarted in the
    process.  At full rate 40Gbps (400 times the typical 100Mbps LAN,  
and
    13,000 times the typical DSL/Cable access link) it takes over 5000
    years to scan a single 64 bit space.

See my comments above about why this is not correct.

4.3.  User/Application Tracking

    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.

Why is this mentioned in this document?  Given this paragraph, I  
think you
have perversely stated another benefit of NAT -- that my ISP cannot
effectively track this information on a per-machine basis.
Also, how is this consistent with the idea that IPv6 will use privacy
address for client communications?

    There are two possible scenarios for the extreme situation when a
    network manager also wishes to fully conceal the internal IPv6
    topology.

    o  One could use explicit host routes and remove the correlation
       between location and IPv6 address.  This solution does however
       show severe scalability issues.

Right.  That is why we should not recommend it.

    o  The other technology to fully hide the internal topology would be
       to use a tunneling mechanism.  Mobile IPv6 without route
       optimization is one example.  In this example the public facing
       addresses are indirected via an edge Home Agent (HA).  This
       indirection method truly masks the internal topology as all nodes
       with global access appear to share a common prefix.  The downside
       of using this method is that it makes usage of middleware like a
       Home Agent (HA).

This seems awfully complex and may present other problems, such as
brittleness and MTU/fragmentation issues.

What are the possible benefits of subnet hiding that could justify  
this type
of solution?

There are other answers involving L2 bridging with VLANs for limiting
broadcast domains that are much more scalable and simpler than either of
these approaches.

4.5.  Independent Control of Addressing in a Private Network

    [...]

    When using IPv6, the need to ask for more address space will become
    far less likely due to the increased size of the subnets.  These
    subnets typically allow 2^64 addresses per subnet and an enterprise
    will typically receive a /48 which allows segmentation into at least
    2^16 different subnets.

    The ongoing subnet size maintenance may become simpler when IPv6
    technology is utilised.  If IPv4 address space is optimised one has
    to look periodically into the number of hosts on a segment and the
    subnet size allocated to the segment; an enterprise today may have a
    mix of /28 - /23 size subnets for example, and may shrink/grow these
    as their network user base changes.  For IPv6 all subnets have /64
    prefixes.

I am not really sure what any of this has to do with anything, and it  
isn't
entirely correct.  The 64-bit IID is a hard limit in IPv6, but there  
is no
hard limit that all sites will be allocated a /48.

4.6.   Global Address Pool Conservation

    IPv6 provides sufficient space to completely avoid the need for
    overlapping address space,
    340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38)  
total
    possible addresses.  As previously discussed, the serious

The naivete of pointing out the number of possible IPv6 addresses  
actually
hurts this argument.  Because of the 64-bit IID and the IETF's
recommendations to allocate a /48 to home users, the address space  
will be
much less densely used than in IPv4.  Many people still feel that  
there will
be enough address space that conservation is not needed, and there are
decent documents that you could cite that make that argument.  This has
little or nothing to do with the number of possible addresses in IPv6,
though.

    disadvantages of ambiguous address space have been well documented,
    and with sufficient space there is no need to continue the
    increasingly aggressive conservation practices that are necessary
    with IPv4.  While IPv6 allocation policies and ISP business practice
    will continue to evolve, the recommendations in RFC 3177 are  
based on
    the technical potential of the vast IPv6 address space.  That
    document demonstrates that there is no resource limitation which  
will
    require the adoption of the IPv4 workaround of ambiguous space  
behind
    a NAT.  As an example of the direct contrast, many expansion  
oriented
    IPv6 deployment scenarios result in multiple IPv6 addresses per
    device, as opposed to the constriction of IPv4 scenarios where
    multiple devices are forced to share a scarce global address.

4.7.  Multihoming and Renumbering

    Multihoming and renumbering remain technically challenging with IPv6
    (see the Gap Analysis below).  However, IPv6 was designed to allow
    sites and hosts to run with several simultaneous CIDR-like prefixes
    and thus with several simultaneous ISPs.  An address selection
    mechanism [10] is specified so that hosts will behave consistently
    when several addresses are simultaneously valid.  The fundamental
    difficulty that IPv4 has in this regard therefore does not apply to
    IPv6.  IPv6 sites can and do run today with multiple ISPs active,  
and
    the processes for adding and removing active prefixes at a site have
    been documented [12] and [19].

To be balanced, you should at least say something here about the fact  
that
end-user sites that currently have "swamp space" addresses in IPv4  
may need
to move ot ISP-provided addresses in IPv6, thus increasing concerns  
about
renumbering and multi-homing.

    If there is need to mask the internal structure towards the external
    IPv6 internet, then some form of 'untraceable' addresses may be  
used.
    These addresses will be derived from a local pool, and may be
    assigned to those hosts for which topology masking is required or
    which want to reach the IPv6 Internet or other external networks.
    The technology to assign these addresses to the hosts could be based
    on DHCPv6.  To complement the 'Untraceable' addresses it is  
needed to
    have at least awareness of the IPv6 address location when routing an
    IPv6 packet through the internal network.  This could be achieved by
    'route-injection' in the network infrastructure.  This route-
    injection could be done based on /128 host-routes to each device  
that
    wants to connect to the Internet using an untraceable address.  This
    will provide the most dynamic masking, but will have a scalability
    limitation, as an IGP is typically not designed to carry many
    thousands of IPv6 prefixes.  A large enterprise may have  
thousands of
    hosts willing to connect to the Internet.  Less flexible masking
    could be to have time-based IPv6 prefixes per link or subnet.  This
    may reduce the amount of route entries in the IGP by a significant
    factor, but has as trade-off that masking is time and subnet based.

This whole "untraceable" address concept seems to be poorly thought- 
out.  I
am concerned that this document, while supposedly an informational  
document
on existing IPv6 features is trying to specify a new IPv6 feature and  
doing
it quite inadequately, IMO.

    While a full prefix is expected to be the primary deployment model
    there may be cases where the ISP provides a single IPv6 address for
    use on a single piece of equipment (PC, PDA, etc.).

How does this differ from the "single user connection" case described in
5.3?

6.1.  Subnet Topology Masking

    There really is no functional gap here as a centrally assigned pool
    of addresses in combination with host routes in the IGP is an
    effective way to mask topology.

You discuss the scaling issues in your own document, so this seems to be
misleading.

6.4.  Site Multihoming

    This complex problem has never been completely solved for IPv4,  
which
    is exactly why NAT has been used as a partial solution.  For IPv6,
    after several years' work, the IETF has converged on an  
architectural
    approach intended with service restoration as initial aim [20].
    Again, ULAs may help since they will provide stable addressing for
    internal communications that are not affected by multihoming.

Depending on what benefits are expected from multihoming, the  
capacity for
IPv6 to use more than one prefix per interface may help here, too.

Appendix A.  Additional Benefits due to Native IPv6 and Universal Unique
              Addressing

I am not really sure that including a "marketing brochure" regarding the
general benefits of IPv6 at the end of this document serves to make  
it any
clearer.

    The users of native IPv6 technology and global unique IPv6 addresses
    have the potential to make use of the enhanced IPv6 capabilities, in
    addition to the benefits offered by the IPv4 technology.

A.1.  Universal Any-to-Any Aonnectivity

Connectivity, perhaps?

A.4.  Increased Security Protection

    The security protection offered by native IPv6 technology is more
    advanced than IPv4 technology.  There are various transport
    mechanisms enhanced to allow a network to operate more securely with
    less performance impact:
    o  IPv6 has the IPsec technology directly embedded into the IPv6
       protocol.

See note above.  IPsec is no more "embedded" in IPv6 than it is in IPv4.

       This allows for simpler peer-to-peer encryption and
       authentication, once a simple key/trust management model is
       developed, while the usage of some other less secure  
mechanisms is
       avoided (i.e. md5 password hash for neighbor authentication).
    o  On a local network, any user will have more security awareness.

IPv6 will make users more security-aware?  What does that even mean?

       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 Translater and hance no false safety perception.
    o  All flows on the Internet will be better traceable due to a  
unique
       and globally routable source and destination IPv6 address.  This
       may facilitate an easier methodology for back-tracing DoS attacks
       and avoid illegal access to network resources by simpler traffic
       filtering.

We already can trace these flows inside the NAT just fine.  The only  
place
it is now easier to trace is outside my NAT, where the attackers live.

    o  The usage of private address-space in IPv6 is now provided by
       Unique Local Addresses, which will avoid conflict situations when
       merging networks and securing the internal communication on a
       local network infrastructure due to simpler traffic filtering
       policy.

How is this a security benefit?

    o  The technology to enable source-routing on a network
       infrastructure has been enhanced to allow this feature to
       function, without impacting the processing power of intermediate
       network devices.  The only devices impacted with the source-
       routing will be the source and destination node and the
       intermediate source-routed nodes.  This impact behavior is
       different if IPv4 is used, because then all intermediate devices
       would have had to look into the source-route header.

Again, how is this a security benefit?

A.5.  Mobility

    Anytime, anywhere, universal access requires MIPv6 services in
    support of mobile nodes.  While a Home Agent is required for initial
    connection establishment in either protocol version, IPv6 mobile
    nodes are able to optimize the path between them using the MIPv6
    option header while IPv4 mobile nodes are required to triangle route
    all packets.  In general terms this will minimize the network
    resources used and maximize the quality of the communication.

Nice plug for MIP6, but why is it here?  And, have you run this text  
by the
MIP4 WG to make sure that they agree with it?

A.7.  Community of interest

    Although some Internet-enabled devices will function as fully- 
fledged
    Internet hosts, it is believed that many will be operated in a  
highly
    restricted manner functioning largely or entirely within a Community
    of Interest.  By Community of Interest we mean a collection of hosts
    that are logically part of a group reflecting their ownership or
    function.  Typically, members of a Community of Interest need to
    communicate within the community but should not be generally
    accessible on the Internet.  They want the benefits of the
    connectivity provided by the Internet, but do not want to be exposed
    to the rest of the world.  This functionality will be available
    through the usage of NAP and native IPv6 dataflows, without any
    stateful device in the middle.  It will also allow to build virtual
    organization networks on the fly, which is very difficult to do in
    IPv4+NAT scenarios.

Uh...  What is this all about?  VPNs?  Something else?  Why is this
different in IPv6 than in IPv4?

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 29 May 2006 09:15:34 -0400

I am fine with the NAP document most of the below complaints seem to be
personal subjective view by the reviewer and objective technical
statements.  The document should ship to RFC.  It has been widely
reviewed and presented to the market often and I have not heard any
complaints.  Technically I have no issue with any of the sections.
Editing wise I have not scrutinized the document for grammar or spelling
etc.  Thus I emphatically disagree strongly with the statements below
from this review.

Best,
/jim 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Friday, May 26, 2006 12:06 PM
> To: Tony Hain; Brian E Carpenter; EricLKlein; 
> [email-masked]; Ralph Droms
> Cc: [email-masked]; Lindqvist Erik Kurt
> Subject: FW: Review of draft-ietf-v6ops-nap-02.txt
> 
> FYI. Margaret's original message seems to have not made it to 
> v6ops, or at least through it to me and reportedly several of you.
> 
> From: Margaret Wasserman [mailto:[email-masked]] On 
> Behalf Of Margaret Wasserman
> I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number 
> of serious issues with the document.  I realize that the Last 
> Calls have already completed and that this document is on the 
> agenda for this week's IESG telechat, but I consider these 
> issues to be serious enough that they are worth raising as 
> late objections.
> 
> I think that there is a serious problem with the way this 
> document describes existing NAT technology.  There are 
> significant issues with the tone of this document, which is 
> arrogant and argumentative.  I also believe that the document 
> contains several factual mistakes and some potentially 
> damaging recommendations.  In addition to resolving my review 
> comments, I would suggest that the document shepherd request 
> a technical review from members of the Transport area who 
> focus on NAT-related technologies.
> 
> While there are some strong technical points in this 
> document, I think that they are severely weakened by the 
> length of the document and the level of
> IPv6 marketing hype included in a document that is 
> simultaneously bashing NAT providers for exactly this sort of 
> behaviour.  Little of this hype, including the entire 
> appendix, is actually operational advice of any kind, and I 
> don't know why the IETF would want to publish it.  There are 
> already existing groups that market IPv6, and I think that it 
> is outside the scope of the IETF to do so.
> 
> The authors also seem to have inserted quite a bit of their 
> own religion, and I think that there are large parts of this 
> document that do not even come close to expressing IETF 
> consensus on various topics like NAT features, the usefulness 
> of firewalls, appropriate use of the IGP routing practices, 
> etc.  It seems unlikely that this document has received 
> adequate review from people in these areas.
> 
> In other words, I think that some of the contents of this 
> document and the current editorial style make it unsuitable 
> for publication as an RFC.
> 
> Specific comments are included below, along with the document 
> exerpts that they refer to.
> 
> Margaret
> 
> ---
> 
> 
> Abstract
> 
>     could be useful for an Internet Protocol site.  IPv6 does 
> not support
> 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.
> 
> While this NAT side effect can also cause problems, it does 
> provide the real benefits of a stateful firewall.
> 
> 1.  Introduction
> 
>     using a NAT device or by using logically separated Local 
> Area Network
>     cited in marketing pronouncements.  It then shows how 
> these needs can
>     The use of the facilities from IPv6 described in this 
> document avoids
> and "marketing pronouncements" in this section and think it 
> should be reworded to remove them and/or cite specific 
> documents.  There are real reasons why people use NATs in 
> IPv4, and there are better ways to do those things with IPv6. 
>  That's what we should say.  The text in the above paragraph 
> is insulting, incorrect and very likely to get the network 
> administrator to stop reading before you can offer any advice 
> on how to set-up an IPv6 network.
> 
> 
>     of the use of IPv4 NAT as extolled by product marketing.  
> The goal of
> 
> 
> Again with the "product marketing".  Do the authors of this 
> document really believe that these benefits do not exist?  
> Does the IETF as a whole?  I think we should be somewhat 
> embarrassed to publish this document as-is, because it seems 
> very naive and one-sided.  This continues throughout the 
>     for its own security, and every process running on a 
> system has to be
> This is the section where we are describing the benefits of 
> NAT without analyzing them.  So, why is this sub-section 
> here?  It is clear that the side effects of NAT can be used 
> as one element of a system to protect internal nodes.  It is 
> not sufficient to protect them from everything, which doesn't 
> mean that it doesn't protect them against anything.  Much of 
> this section could appear to be an argument that firewalls of 
> all kinds are useless because of the existence of Trojan 
> Horse-style attacks, which is obviously false.  Have any 
> firewall experts been asked to review this section?  If not, 
> I think you should ask someone like Steve Bellovin to do so.
> 
> 
>     they provide limited capabilities for the administrator 
> of the NAT to
>     The checking of this database is not always a simple 
> task, especially
> I think that this document is arguing that User/Application 
> tracking is not a benefit of NAT?  If so, why is it even in 
> this document?
> 
>     network with an identifier (IPv4 address) which an entity 
> outside the
>     Internet cafe, or which employee of a company generated 
> or received a
>     NAT creates a smaller pool of addresses for a much more 
> focused point
>     of attack.
> 
> What does the last sentence mean?  Give some sort of example 
> or take it out, perhaps?
> 
> Is not technically sound to advocate the dissemination of 
> host routes in the IGP for infrastructure hiding.  IGPs are 
> not designed to scale well for this sort of use.  It would be 
> much more technically sound to advocate the use of
> Besides, I thought the point of network address hiding (or 
> one of them), as outlined above was to avoid the ability to 
> identify different nodes by address for port scanning 
> purposes, not (merely) to avoid the ability to tell what 
> subnets they are on.  The proposed technique doesn't seem to 
>     noted that the address selection policy table in 
> end-systems needs to
> 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 completely unnecessary and somewhat misleading.
> 
> _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.
> 
>     more complex case might involve local routing protocols, 
> but with the
>     entire local network sharing a common global prefix there 
> would still
> I don't understand this paragraph at all.  What does it have 
> to do with ULAs?  Also, the second half of this sentence 
> doesn't make sense.
> I'm not 100% sure what it means, but if it means what I think 
> it means, it is wrong.
> 
>         tampering, and optionally masks the packet contents.  
> While IPsec
> IPsec performs exactly the same purposes in IPv4 as IPv6.  I 
> don't know of any stacks that implement IPsec for IPv6 and 
> not for IPv4.
> Also, it is not clear that end-to-end IPsec is fundamentally 
> useful, even without the interference of a NAT box, as I 
> believe that there needs to be some sort of binding to the 
> upper layer protocol in order for IPsec to provide these protections.
> 
> If you decide to keep this section, you should acknowledge 
> that use of the
> IPv6 stateful firewall mechanisms advocated in bullet 3 will 
> present similar obstacles to using IPsec.
> 
> 
> IIDs will not be randomly distributed.  They are based on 
> EUI-64 IDs which are certainly not randomly distributed.  In 
> fact, on Ethernet 16 of the 64-bits will have a known value.  
> Also, the numbering space for the first three bytes (24-bits) 
> is not completely allocated and there is very clearly an 
> unbalanced distribution in that space.  The fact that 
> companies tend to buy somewhat homogenous hardware can make 
> it possible to guess which three-byte combinations are most 
> likely to be present within a given company.  So, the length 
> of the IID offers nowhere near the level of protection 
> described above.
> 
> 
>     process.  At full rate 40Gbps (400 times the typical 
> 100Mbps LAN, and
> Why is this mentioned in this document?  Given this 
> paragraph, I think you have perversely stated another benefit 
> of NAT -- that my ISP cannot effectively track this 
> information on a per-machine basis.
> Also, how is this consistent with the idea that IPv6 will use 
> privacy address for client communications?
> 
> This seems awfully complex and may present other problems, 
> such as brittleness and MTU/fragmentation issues.
> 
> What are the possible benefits of subnet hiding that could 
> justify this type of solution?
> 
> There are other answers involving L2 bridging with VLANs for 
> limiting broadcast domains that are much more scalable and 
> simpler than either of these approaches.
> 
> 
> I am not really sure what any of this has to do with 
> anything, and it isn't entirely correct.  The 64-bit IID is a 
> hard limit in IPv6, but there is no hard limit that all sites 
> will be allocated a /48.
> 
>     340,282,366,920,938,463,463,374,607,431,768,211,456 
> (3.4*10^38) total
> The naivete of pointing out the number of possible IPv6 
> addresses actually hurts this argument.  Because of the 
> 64-bit IID and the IETF's recommendations to allocate a /48 
> to home users, the address space will be much less densely 
> used than in IPv4.  Many people still feel that there will be 
> enough address space that conservation is not needed, and 
> there are decent documents that you could cite that make that 
> argument.  This has little or nothing to do with the number 
> of possible addresses in IPv6, though.
> 
>     will continue to evolve, the recommendations in RFC 3177 
> are based on
>     document demonstrates that there is no resource 
> limitation which will
>     require the adoption of the IPv4 workaround of ambiguous 
> space behind
>     a NAT.  As an example of the direct contrast, many 
> expansion oriented
>     IPv6.  IPv6 sites can and do run today with multiple ISPs 
> active, and
> To be balanced, you should at least say something here about 
> the fact that end-user sites that currently have "swamp 
> space" addresses in IPv4 may need to move ot ISP-provided 
> addresses in IPv6, thus increasing concerns about renumbering 
> and multi-homing.
> 
>     IPv6 internet, then some form of 'untraceable' addresses 
> may be used.
>     on DHCPv6.  To complement the 'Untraceable' addresses it 
> is needed to
>     injection could be done based on /128 host-routes to each 
> device that
> This whole "untraceable" address concept seems to be poorly 
> thought- out.  I am concerned that this document, while 
> supposedly an informational document on existing IPv6 
> features is trying to specify a new IPv6 feature and doing it 
> quite inadequately, IMO.
> 
> How does this differ from the "single user connection" case 
> described in 5.3?
> 
> You discuss the scaling issues in your own document, so this 
> seems to be misleading.
> 
> 6.4.  Site Multihoming
> 
>     This complex problem has never been completely solved for 
> IPv4, which
> I am not really sure that including a "marketing brochure" 
> regarding the general benefits of IPv6 at the end of this 
> document serves to make it any clearer.
> 
>     o  All flows on the Internet will be better traceable due 
> to a unique
> We already can trace these flows inside the NAT just fine.  
> The only place it is now easier to trace is outside my NAT, 
> where the attackers live.
> 
> Nice plug for MIP6, but why is it here?  And, have you run 
> this text by the
>     Although some Internet-enabled devices will function as 
> fully- fledged
>     Internet hosts, it is believed that many will be operated 
> in a highly
> Uh...  What is this all about?  VPNs?  Something else?  Why 
> is this different in IPv6 than in IPv4?
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 31 May 2006 10:04:38 -0400

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

> > when you change ISPs or when ISPs change address allocation 

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:

>    (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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 31 May 2006 10:08:13 -0400

Oh, and one more peeve.

Does the WG really believe this statement is a fair representation of
reality:

>    340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total
>    possible addresses.

That is, given /48s to end sites, stateless address autoconfiguration
and 64-bit interface identifiers, do we undermine our own credibility
by claiming IPv6 supports 10^38 addresses?

Thomas

---

From: Fred Baker <[email-masked]>
Date: Wed, 31 May 2006 07:59:11 -0700

> by claiming IPv6 supports 10^38 addresses?

as opposed to 10^128?

Stateless autoconfiguration provides a way that any system can get an  
address. It reduces the count of LANs to 10^64, and the business  
about /48s means we reduce the number of sites on the backbone to  
10^32 ISPs each supporting 2^16 customers. I would prefer that we  
talked about /48s for campuses and /56s for SOHO environments, and I  
thought that was on the table at least at one point (wasn't that  
draft-narten-ipv6-3177bis-48boundary?).

Frankly, the requirement stated that we needed to support 10^12 LANs  
and 10^15 hosts. We passed that a long time back.

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Wed, 31 May 2006 17:41:40 +0200

Hi Thomas,

They do not believe that was fair... That is an edit mistake of me as there
was a 
comment about that in the archives.

G/ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Narten
Sent: Wednesday, May 31, 2006 4:08 PM
To: Bound, Jim
Cc: Fred Baker; Tony Hain; Brian E Carpenter; EricLKlein; [email-masked];
Ralph Droms; [email-masked]; Lindqvist Erik Kurt; Margaret Wasserman
Subject: Re: Review of draft-ietf-v6ops-nap-02.txt 

Oh, and one more peeve.

>    340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total

That is, given /48s to end sites, stateless address autoconfiguration and
64-bit interface identifiers, do we undermine our own credibility by
claiming IPv6 supports 10^38 addresses?

Thomas

---

From: Fred Baker <[email-masked]>
Date: Wed, 31 May 2006 08:48:48 -0700

Havard Eidnes read the numbers a little closer than I did: yes, 10^38  
is approximately 2^128.

I think the point remains that the requirement originally stated was  
this:

    CRITERION
       The IPng Protocol must scale to allow the identification and
       addressing of at least 10**12 end systems (and preferably much
       more).  The IPng Protocol, and its associated routing protocols
       and architecture must allow for at least 10**9 individual  
networks
       (and preferably more).  The routing schemes must scale at a rate
       that is less than the square root of the number of constituent
       networks [10].

http://www.ietf.org/rfc/rfc1726.txt
1726 Technical Criteria for Choosing IP The Next Generation (IPng). C.
      Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes)
      (Status: INFORMATIONAL)

Without running through all the history, and the arguments of whether  
in 2006 the numbers selected in 1994 are adequate, the fact is that  
we support a very large number of enumerable networks, on the order  
of the square of the original requirement, and not only do we support  
10^12 hosts in the address space, we support that many and quite a  
few more on each LAN.

Yes, we support about 3 * 10^38 addresses in the address space. That  
is a mathematically accurate statement.

I think the point you're asking is "does that mean we should throw  
the addresses away with both hands?". And I would say, no, that's  
what we did with the IPv4 address space, and we eventually learned  
the error of those ways. It does make sense to think about rational- 
sized address blocks, but frankly I would expect that this is more of  
an RIR issue than an IETF issue. They are currently handing out /32s  
to ISPs, and more if the ISPs can justify it. That means that they  
are allowing for ~4 billion address allocations, each of which is  
presumably enough for 2^16 ISP customers, each of which potentially  
has 2^16 LANs. I do believe that there is a question of market  
dynamics there - if the customer is unlikely to create more than 256  
LANs, selling them a /56 makes sense, and helps with the overall  
address usage density, and if the customer really only needs a  
single /64 or to be a member of a /64, I think those should be  
options the customer can buy. saying "ISPs should only ever under any  
circumstances hand out a /48" seems a trifle over the top.

And I do remember this thing about CIDR, that it removed the classful  
address straight-jacket, which at least at the time some of us  
thought was a good thing, and I wonder why we seem to be re-creating  
it here. But that wasn't your question.

---

From: David Conrad <[email-masked]>
Date: Wed, 31 May 2006 09:42:34 -0700

Fred,

On May 31, 2006, at 8:48 AM, Fred Baker wrote:
> Yes, we support about 3 * 10^38 addresses in the address space.  
> That is a mathematically accurate statement.

No.  A mathematically correct statement would be that IPv6 can, in  
theory, address up to about 3*10^38 objects.  The number of objects  
that can actually be supported is, of course, far, far less.

Rgds,
-drc

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Wed, 31 May 2006 20:01:32 +0200

<slightly off-topic>

Why the difference between objects and addresses in this particular case
for the matematical model? Practically I completely agree, but matemathical
i'm not sure yet? (what if all prefixes are /128?)

G/ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Conrad
Sent: Wednesday, May 31, 2006 6:43 PM
To: Fred Baker
Cc: Thomas Narten; Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein;
[email-masked]; Ralph Droms; [email-masked]; Lindqvist Erik Kurt;
Margaret Wasserman
Subject: Re: Review of draft-ietf-v6ops-nap-02.txt

Fred,

> That is a mathematically accurate statement.

No.  A mathematically correct statement would be that IPv6 can, in theory,
address up to about 3*10^38 objects.  The number of objects that can
actually be supported is, of course, far, far less.

Rgds,
-drc

---

From: "Eric Klein" <[email-masked]>
Date: Wed, 31 May 2006 20:48:25 +0200

From: "Thomas Narten" 

> Margaret's comments, did look long enough to agree that more work is
<snip> 
> renumbering to be covered adequately.
I thought that DHCPv6 was the solution to renumbering.

---

From: "Walt Lazear" <[email-masked]>
Date: Wed, 31 May 2006 14:44:41 -0400

I agree!  I'm a firm believer in the need for IPv6, but
I get a deja-vu knot in my stomach when I hear some IPv6
evangelists (such as at an IPv6 Summit) talking about the infinite 
address space and great applications it enables.  There is 
breast beating about Jon Postel wantonly handing out 
Class A's to buds in IPv4 land and yet I see the same kind 
of large chunks of IPv6 land being distributed freely.  
Perhaps we're letting the RIR's head down the same road?
/64's for serial links!  15 quintillion addresses where 2-4 
will suffice?!?!?!

What's scary are the applications that give addresses to every 
retail item so it can be tracked during it's lifetime.  No
reuse of addresses is contemplated (because they're infinite).
Imagine the ultimate usage, where nano-things in aerosol sprays each 
have an address that is literally "cast to the wind".  Is there a
/70 or /80 in every can of this stuff?  Why is there no built-in
mandatory recycling of address space for these applications?

We're undoing CIDR-like usage.  Hierarchical addressing is
going to be wasteful by nature.  I don't know how the IETF 
can influence the RIR allocation policy, but it's scary 
how much history seems to be repeating itself.  We're
at the early end of the cycle, so it may not seem to some 
that we're handing out addresses with both hands, but we are.

Walt Lazear

> Sent: Wednesday, May 31, 2006 11:49 AM
> To: Thomas Narten
> Cc: Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein; 
> [email-masked]; Ralph Droms; [email-masked]; Lindqvist 
> Erik Kurt; Margaret Wasserman

---

From: [email-masked]
Date: Wed, 31 May 2006 19:50:03 +0000

> that we're handing out addresses with both hands, but we are.

	RIR policy is derived from those who participate in
	the policy development process.  The policy development
	process is analogous to the IETF of last century, when
	what mattered was individual participation... people
	weigh in with thier thoughts and opinions.  ...  Not 
	companies or organizations per.se.    If you don't like
	what the RIR's are doing, consider that the polcies are
	set by folks active in developing policy...

	http://www.arin.net/policy/irpep.html
	
	policies can and have been changed over time.

--bill