Subject: Last call on draft-ietf-v6ops-nap-01.txt

From: Fred Baker <[email-masked]>
Date: Fri, 5 Aug 2005 07:08:20 +0200

With this note, I am opening a working group last call on draft-ietf- 
v6ops-nap-01.txt. This WGLC will close in two weeks, at close of  
business 19 July. Please read the document and comment to the list -  
either say that the document is ready, or say what issues you may  
have with it.

Thanks.

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Aug 2005 18:31:09 +0930

Hi Everybody,

On Fri, 5 Aug 2005 07:08:20 +0200

> either say that the document is ready, or say what issues you may  

Some comments. Mostly editorial / readability related, nothing really
that significant I think. Got a bit long unfortunately. I was reading
and commenting at the same time.

I'm aware of and agree with the the points that were in the IETF63
presentation, so I haven't commented on them.

2.2  Simple security due to stateful filter implementation

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

I'm not sure that bandwidth concerns (presumably caused by the threat of
DoS style attacks) are the main reasons why people put firewalls in.
Rather, I think in most cases it would be the other way around - people
put firewalls in to control the types of traffic that can enter or leave
their network, and the reduction in unwanted traffic because of that
control is a beneficial side effect.

Possibly this text could be rephrased or expanded on, mostly only
because it appears to be making an absolute statement of what a firewall
is used for, and I don't think unwanted traffic volume reduction is
necessarily always the reason.

"For these reasons the sense of security provided by NAT are actually
false."

I'd think it would be better to say something along the following lines, as NAT
does provide some security, just as not as much as most people think  -

"For these reasons the actual level of security provided by NAT can be
significantly less than commonly perceived."

"The perceived security comes from the lack of pre-established or
permanent mapping state."

I suggest extending this statement -

"The perceived security comes from the lack of pre-established or
permanent mapping state, which is only guaranteed to occur when the
Network Address Port Translation (NAPT) form of NAT is used."

"... however when the
   merging networks were already using address translation it will
   create huge problems due to admistrative difficulties of the merged
   address space."

I'm a bit confused by this text. Is the "address translation" being
referred to being used towards the Internet, not the address translation
that has temporarily been put in place between the two organisations ?
I.e. the two organisations are each using 10/8, and have NAT boxes at
their Internet connections. They then want to connect together, also
using (two instances) of NAT, to make the "other" 10/8 appear to be some
other, non-local address space. Assuming that one of the 10/8s is
renumbered, and NAT between the organisation is removed, is the "address
translation" above referring to the remaining Internet NAT ?

3.3  DHCPv6 prefix delegation

At the moment, this section describes what the Prefix Delegation
function does, however I don't think it really connects it with the NAT
function it is substituting for, namely the ability to just plug a
NA(PT) box in and have access to the Internet work straight away.

I think a small amount of text exanding that description would be
helpful, similar to the first paragraphs of " 3.1  Privacy addresses
(RFC 3041)" and "3.2  Unique Local Addresses".

3.4  Untraceable IPv6 addresses

I think this section / feature might be misnamed. These addresses aren't
completely untraceable, rather, they are only traceable to to the edge
of the network assigned the /48. A better description or name might be
"Hidden Internal Topology IPv6 addresses". Or maybe not :-) "Opaque
Subnet IPv6 Addresses" ? Anyway, something that doesn't suggest that
they're completely untraceable.

I also think that the last paragraph would be better positioned as the
first in this section.

I think the statement,

"These should be globally routable IPv6 addresses which can be
   randomly and independently assigned to IPv6 devices."

could be a bit more descriptive by adding ", within the internal
topology." I think this also further makes it clear that this
untraceability property extends to the whole of the Internet.

4.2  IPv6 and Simple security

Very minor, "::/64" should probably be "(/64)" eg.

"3.  The size of the typical subnet (/64) will make a network ping"

I realise a few of the authors probably have English as their second
language, so I'm guessing this isn't intentional :

"This simple rule would create similar protection and security holes
   the typical IPv4 NAT device will offer ..."

This made me chuckle a bit when I first read it, as to a first language
English speaker, it reads like the security holes of a typical IPv4 NAT
device are something worth aiming for, as though they are good features.
Unfortunately some native English speakers who might not be aware of
NAT's limitations and may be becoming aware of them via this draft may
also read it that using IPv6 in this way is also "as bad as NAT".

I'd suggest dropping the "and security holes" :

"This simple rule would create similar protection the typical IPv4 NAT
device will offer ..."

Actually, it may be best to qualify the type of NAT being used. In this
section it is only really NAPT that is guaranteed to provide this style
of "reflexive" protection.

4.3  User/Application tracking

"IPv6 enables the collection of information about data flows."

I'm not really sure that IPv6 "enables" it, in the sense that it is a
feature of IPv6. Proper end-to-end, visible addressing does facilitate
it, although it would either require a host based reporting mechanism,
or the insertion of more than just a router  e.g. a firewall in line
with the traffic flows.

I'd suggest slighly refocusing this section to state that assigning and
making visible (ie. not NATting them) unique IPv6 end-node addresses can
facilitate User/Application tracking, but also make it clear that an
additional device or service needs to be added to do that as it is not
an inherent feature of IPv6.

While I understand the purpose of this section regarding matching a
possible use of NAT, it reads a bit too pro-privacy intrusion to me,
although that may be a personal value judgment rather than something
that needs to be changed in the RFC. It also may be worth adding that
Privacy Addresses and IPsec, which _are_ standard features of IPv6, may
limit or prevent the ability to perform User / Application tracking, at
least by network located devices. (hmm, these days it seems, I keep
coming across examples of where things are best done at the ends or on
the hosts, this being another one.)

4.4  Privacy and topology hiding using IPv6

Along the lines of using Mobile IPv6, another possibly simpler solution,
assuming the administrator is willing to wear the administrative
overhead, would be to have hosts act as end-points to statically
configured IPv6 in IPv6 or GRE tunnels. I'm not sure how widely
implemented Mobile IPv6 is, I know that most IPv6 capable OSes would
support this manually configured tunnel method today.

4.5  Independent control of addressing in a private network

Sort of minor :

" ... and may shrink/grow these
   as their network user base/etc changes.  In v6, it's all /64."

conflicts a bit with 

"3.  The size of the typical subnet ::/64 will make a network ping" 

in "4.2  IPv6 and Simple security"

I say "sort of" minor because I think it is necessary to either have the
RFC take the position that all IPv6 subnets will be /64s (making the
first quote above correct), or take the position that most subnets, but
not all, will be /64s. 

I'm also a bit conscious of this point as I recently saw some IPv6
addressing discussion on the nanog mailing list. I read that somebody
was considering allocating out something like /124s to their residential
customers, because they couldn't see a need for a customer to connect
more than 16 devices to their home LAN. The point that person has missed
is that the /64 is a /64 not because it needs to be, rather, it is
convenient for it to be, similar to 802.1 MAC addresses being 48 bits in
size for convenience rather than necessity. 

This "give customers _only_ what (I think) they need" mentality is
certainly quite understandable for IPv4. It obviously mostly isn't in
IPv6. It's possibly out of scope for this RFC, although I think it could
be argued that IPv6 Network Architecture Protection could include
ensuring that features such as privacy addresses, or easy renumbering of
the network without having to renumber subnets is a architectual
property of IPv6 that should be preserved, by avoiding naive address
allocation methods. Possibly specifying some rules or strong guidelines
regarding what prefix lengths are appropriate would be useful, assuming
that "all subnets are /64s" isn't the position taken.

4.6   Global address pool conservation

I've just got to this section which discusses the global address
space size. Possibly a bit of the above text, specifically regarding a
/64 being sized mostly for convenience rather than necessity, could be useful
to add to this section.

5.2  Small private networks

5.3  Single user connection

In 5.2 seems to suggest a single /64 might be satisfactory for a single
device in the last paragraph, and I think in 5.3 it implies it. I can
imagine a scenario where, specifically in the case of 5.3, a person has
a blue tooth capable phone, that could also act as an IPv6 router for
other blue tooth devices capable such as a PDA, allowing the PDA to have
a "proper" IPv6 connection to the mobile phone network. Technically
they're a single user, yet they need more than a single /64. In this
case the mobile phone would need to be allocated at least a /63, and
therefore, for convenience reasons, a /48 assignment to the phone would
probably be better. I think it could be worth describing this or a
similar scenario as to why a /48 is a useful prefix length for even a
single user. (Technically the blue tooth phone could possible act as a
bridge for the PDA, although the PDA and the phone may also have ULAs,
so the phone is likely to have IPv6 forwarding / processing /
firewalling capabilities anyway. It may be better and more secure to
have the blue tooth phone act as a IPv6 router.)

5.4  ISP/Carrier customer networks

Minor :

"When IPv6 NAP is utilized in these three domains then for the first
   category it will be possible to use the same solutions as described
   in chapter 5.1."

"section 5.1" rather than "chaper 5.1" ?

"Using these local scope   addresses would also prevent
<insert>them</insert> from being accessed from the^H^H^H an external  
network."

"These will typically be assigned with prefix lengths terminating on
nibble boundaries to be consistent with the DNS PTR records."

Is this suggesting non-/48 or /64 assignments to end-users, as /48s and /64s fall on
octet rather than nibble boundaries ?

This section also mentions 3GPP and multi-subnet scenarios, which I
commented on above. I'd think that if this multi-subnet scenario can
exist in a 3GPP scenario, it could also exist in others that we haven't
thought of (e.g. Wimax maybe ?), so I'd still think some discussion of a
"single user, multi-device" scenario could be useful in section 5.3,
even if it didn't use a mobile phone / PDA situation as an example,
because it is covered in this section.

That's it I think. Sorry for the length. Thanks for reading this far,
very much appreciated. Namaste.

HTH,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Aug 2005 15:17:55 +0100

Some more comments on this draft.  Apologies for the lateness.

-- 
Tim/::1

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
   that some connectivity and security concerns can only be solved by
   using a NAT device or by using logically separated LAN address
   spaces.  This document describes the market-perceived reasons to
   utilize a NAT device in an IPv4 environment and shows how these needs
   can be met and even exceeded with IPv6.  The use of the facilities
   from IPv6 described in this document avoids the negative impacts of
   translation and may be described as Network Architecture Protection
   (NAP).

>>  Does it explain why IPv6 NAT is not needed also?
>>  Add reference to rfc2775 maybe?

   As far as security and privacy is concerned, this document considers
   how to mitigate a number of threats.  Some are obviously external,
   such as having a hacker trying to penetrate your network, or having a
   worm infected machine outside your network trying to attack it.  Some
   are local such as a disgruntled employee disrupting business
   operations, or the unintentional negligence of a user downloading
   some malware which then proceeds to attack any device on the LAN.
   Some may be embedded such as having some firmware in a domestic
   appliance "call home" to its manufacturer without the user's consent.

>>  Note the threats that are user-initiated (e.g. web browser download) are
>>  different to those that are 'pushed' into a site.  IPv6 does not really 
>>  help the former, but may help against the latter, and also the internal
>>  spread of such threats (e.g. worms that search for hosts on a subnet/link
>>  to infect).

   IPv6 Network Architecture Protection can be summarized in the
   following table.  It presents the marketed functions of NAT with a
   cross-reference of how those are delivered in both the IPv4 and IPv6
   environments.

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

>>  Why does DHCP limit the number of downstream devices?   Why not use
>>  DHCP with IPv6?  

   +------------------|-----------------------|-----------------------+
   |  Topology hiding |  NAT transforms       |  Untraceable addresses|
   |                  |  subnet bits in the   |  using IGP host routes|
   |                  |  address              |  /or MIPv6 tunnels for|
   |                  |                       |  stationary systems   |
   |                  |  see section 2.4      |  see section 4.4      |

>>  Host route scalability limited though?

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

>>  Or do we encourage all sites to use 3177 addresses even if not connected?

   +------------------|-----------------------|-----------------------+
   |  Global Address  |  RFC 1918             |  340,282,366,920,938, |
   |  Pool            |                       |  463,463,374,607,431, |
   |  Conservation    |                       |  768,211,456          |
   |                  |                       |  (3.4*10^38) addresses|
   |                  |  see section 2.6      |  see section 4.6      |

>>  2^128 addresses doesn't help if sites get given too big a prefix ;)

>>  What about internal site benefits?   Like resilience to 'ping and infect'
>>  type worms on a subnet/link do to link size, or port scanning reslience,
>>  for which IPv4 has no 'equivalent'?  Add these to the table and refer
>>  to text?   Should all text sections appear in the summary table?

2.1  Simple gateway between Internet and internal network

   A NAT device can connect a private network with any kind of address
   (ambiguous [RFC 1918] or global registered address) towards the
   Internet.  The address space of the private network can be built from
   globally unique addresses, from ambiguous address space or from both
   simultaneously.  Without specific configuration from public to
   private, the NAT device enables access between the client side of an
   application in the private network with the server side in the public
   Internet.

>>  Explain somewhere what is meant by 'ambiguous address space'?

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

   It is frequently believed that through its session-oriented
   operation, NAT puts in an extra barrier to keep the private network
   protected from evil outside influences.  Since a NAT device typically
   keeps state only for individual sessions, attackers, worms, etc.
   cannot exploit this state to attack a host in general and on any
   port.  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 are actually false.

>>  But aren't these 'trojans' applicable to IPv6 systems too?   Is NAT 
>>  a special case?

   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 2 or
   more devices need to host the same application this complexity shifts
   from difficult to impossible.

>>  And the chances for misconfiguration grow.    Though for every such
>>  mapping you are likely? to need an equivalent firewall rule in an
>>  IPv6 network?

2.4  Privacy and topology hiding

   There is a similarity with privacy based on application level
   proxies.  When using an application level gateway for browsing the
   web for example, the 'privacy' of a web user can be provided by
   masking the true identity of the original web user towards the
   outside world (although the details of what is - or is not - logged
   at the NAT/proxy will be different).

   Some enterprises prefer to hide as much as possible of their internal
   network topology from outsiders.  Mostly this is achieved by blocking
   "traceroute" etc., but NAT of course entirely hides the internal
   subnet topology, which some network managers believe is a useful
   precaution to mitigate scanning attacks.  Scanning for IPv6 can be
   much harder in comparison with IPv4 as described in [17]

>>  There's a new I-D now on how to best configure IPv6 access devices to
>>  ensure ICMP filtering is done properly (e.g. doesn't break PMTU
>>  discovery) - cite it somewhere?

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.

>>  But in some cases even 16M 'net 10' addresses are not enough?

   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.

>>  Only if the site is generally client devices, rather than servers;
>>  in the latter case you generally wouldn't use NAT though.

2.6  Global address pool conservation

   Due to the ongoing depletion of the IPv4 address range, the remaining
   pool of unallocated IPv4 addresses is below 30%.  While mathematical
   models based on historical IPv4 prefix consumption periodically
   attempt to predict the future exhaustion date of the IPv4 address
   pool, a direct result of this continuous resource consumption is that
   the administrative overhead for acquiring globally unique IPv4
   addresses will continue increasing in direct response to tightening
   allocation policies.  In response to the increasing administrative
   overhead many Internet Service Providers (ISPs) have already resorted
   to the ambiguous addresses defined in RFC 1918 behind a NAT for the
   various services they provide as well as connections for their end
   customers.  In turn this has restricted the number of and types of
   applications that can be deployed by these ISPs and their customers.
   Forced into this limiting situation such customers can rightly claim
   that despite the optimistic predictions of mathematical models the
   global pool of IPv4 addresses is effectively already exhausted.

>>  Note RFC1918 may be used for end customers, or for ISP infrastructure,
>>  sometimes for one, not the other.   Managing two sets of RFC1918 
>>  networks is more complex.    Some ISPs seem to be considering IPv6 for
>>  their infrastructure management?

2.7  Multihoming and renumbering with NAT

   This solution may be sufficient for some networks; however when the
   merging networks were already using address translation it will
   create huge problems due to admistrative difficulties of the merged
   address space.

>>  Especially since they'll often both be using 10.0.0.* for example.

3.1  Privacy addresses (RFC 3041)

   While the primary implementation and source of randomized RFC 3041
   addresses is expected to be from end systems running stateless
   autoconfiguration, there is nothing that prevents a DHCP server from
   running the RFC 3041 algorithm for any new IEEE identifier it hears,
   then remembering that for future queries.  This would allow using
   them in DNS for registered services since the assumption of a server
   based deployment would be a persistent value that minimizes DNS
   churn.  A DHCP based deployment would also allow for local policy to
   periodically change the entire collection of end device addresses
   while maintaining some degree of central knowledge and control over
   which addresses should be in use at any point in time.

>> Yes, DHCPv6 supports allocating privacy addresses.   Note 3041 is 
   being updated at this time.   Many sites will NOT want to have such
   addresses used (due to management issues) so would probably run
   full DHCPv6 for address management.

3.2  Unique Local Addresses

   Local network and application services stability during periods of
   intermittent connectivity between one or more providers requires
   address management autonomy.  Such autonomy in a single routing
   prefix environment would lead to massive expansion of the global
   routing tables, so IPv6 provides for simultaneous use of multiple
   prefixes.  The Unique Local Address prefix (ULA) [12] has been set
   aside for use in local communications.  The ULA address prefix for
   any network is routable over a locally defined collection of routers.
   These prefixes are NOT to be routed on the public global Internet as
   that would have a serious negative impact on global routing.

>> Well, they can be routed anywhere you can convince ISPs to do so for
   you... :)

   ULAs have the following characteristics:
   o  Globally unique prefix
      *  Allows networks to be combined or privately interconnected
         without creating any address conflicts or requiring renumbering
         of interfaces using these prefixes
      *  If accidentally leaked outside of a network via routing or DNS,
         there is no conflict with any other addresses
   o  ISP independent and can be used for communications inside of a
      network without having any permanent or intermittent Internet
      connectivity

>> delete 'or intermittent'

   o  Well known prefix to allow for easy filtering at network
      boundaries
   o  In practice, applications may treat these addresses like global
      scoped addresses

>> They should treat them as globals, because they have *global* scope, but
   the reality is more complex :(   

   These should be globally routable IPv6 addresses which can be
   randomly and independently assigned to IPv6 devices.

   The random assignment has as purpose to confuse the outside world on
   the structure of the local network.  However for the local network
   there is 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 aggregation
   device like a Mobile IPv6 Home Agent.

>> I really don't like this text being in the draft.

   The vulnerability of an IPv6 host is similar as for an IPv4 host
   directly connected towards the Internet, and firewall and IDS systems
   are recommended.  A proxy may be used for certain applications, but
   has 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.

>> Is 'suffix' the right word?

   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.

>> Availability of AH and ESP functionality is 'mandated', usage is not.

   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.

>> So long as 3041 isn't used.

   When a network manager also wishes to conceal the internal IPv6
   topology, by using explicit host routes it is possible to locate
   nodes on one segment while they appear externally to be on another.
   An alternative method to hide the internal topology would be to use
   Mobile IPv6 internally without route optimization where the public
   facing addresses are consolidated on an edge Home Agent (HA), then
   use MIPv6 in bidirectional tunnel mode between the HA and topology
   masked node using the ULA as a COA.  This truly masks the internal
   topology as all nodes with global access appear to share a common
   subnet.  There is no reason that rack mounted devices couldn't be
   considered mobile nodes to mask the internal topology.  It looks
   equivalent to running a VPN to a central server, however it does not
   involve any encryption or significant overhead.

>> Again, I don't like this.  The 'cost' for the gain is very, very high.

   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
   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
   lead to the IPv4 practice 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 IPv4 constricting scenarios of multiple devices
   sharing a scarce global address.

>> Note RFC3177 is under -bis revision at the moment.

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 [9] 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

Van de Velde, et al.    Expires December 3, 2005               [Page 16]

Internet-Draft    IPv6 Network Architecture Protection         june 2005

   the processes for adding and removing active prefixes at a site have
   been documented [11] and [18].

>> IPv4 has no lifetime or deprecation indicators like IPv6.  With IPv6
   multiaddressing is likely to be common.

   The IPv6 address space allocated by the ISP will be dependent upon
   the connecting Service provider.  This may result in a renumbering
   effort if the network changes from Service Provider.  When changing
   ISPs or ISPs readjusting their addressing pool, DHCP-PD [10] can be
   used as the zero-touch external mechanism for prefix change in
   conjunction with a ULA prefix for internal connection stability.
   With appropriate management of the lifetime values and overlap of the
   external prefixes, a smooth make-before-break transition is possible
   as existing communications will continue on the old prefix as long as
   it remains valid, while any new communications will use the new
   prefix.

>> I think the renumbering tests we did show that ULAs are not necessary.
   ULA also adds 'cost' in terms of complexity, since they are *global*
   scope addresses now.

5.  Case Studies

   It is possible to divide the type of networks in different
   categories.  This can be done on various criteria.  The criteria used
   within this document are based on the number of components or
   connections.  For each of these category of networks we can use IPv6
   Network Architecture Protection to achieve a secure and flexible
   infrastructure, which provides an enhanced network functionality in
   comparison with the usage of address translation.

   o  Medium/large private networks (typically >10 connections)
   o  Small private networks (typically 1 to 10 connections)
   o  Single user connection (typically 1 connection)
   o  ISP/Carrier customer networks

>> You mean devices/nodes, or connections as in network links offsite?
>> Our site has 20,000 nodes, and 1 connection.  It is not 'small private'.

   The summarization benefit for the ISP is happening based on the IPv6
   allocation rules.  This means that the ISP will provide the
   enterprise with an IPv6 address-range (typically a one or multiple
   range(s) of '/48') from its RIR assigned IPv6 address-space.  The
   goal of this allocation mechanism is to decrease the total amount of
   entries in the internet routing table.

>> summarization -> aggregation?

   To mask the identity of a user on a network of this type, the usage
   of IPv6 privacy extensions may be advised.  This technique is useful
   when an external element wants to track and collect all information
   sent and received by a certain host with known IPv6 address.  Privacy
   extensions add a random factor to the host part of an IPv6 address
   and will make it very hard for an external element to keep
   correlating the IPv6 address to a host on the inside network.  The
   usage of IPv6 privacy extensions does not mask the internal network
   structure of an enterprise network.

>> And the ISP just tracks prefix usage for billing/etc?

   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. 

>> Again, yuk.  Do we need this?

   o  DHCPv6 Prefix-Delegation
   o  ISP provides a static IPv6 address-range

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

>> dynamic, or automatic?   I hope it's automatic and static.
>> DHCP-PD != dynamic/changing allocations ?

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

         For the static configuration the mechanisms used could be the
   same as for the medium/large enterprises.  Typically the need for
   masking the topology will not be of high priority for these users,
   and the usage of IPv6 privacy extensions could be sufficient.

>> A manual rather than static setup?

      For both alternatives the ISP has the unrestricted capability for
   summarization of its RIR allocated IPv6 prefix, while the small

>> summarization -> aggregation?

      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.).  This is expected
   to be rare though, because in the IPv6 world the assumption is that
   there is an unrestricted availability of a large amount of globally
   routable and unique address space.  If scarcity was the motivation
   with IPv4 to provide RFC 1918 addresses, in this environment the ISP
   will not be motivated to allocate private addresses towards the
   single user connection because there are enough global addresses
   available at essentially the same cost.  Also if the single device
   wants to mask its identity to the called party or its attack profile
   over a short time window it will need to enable IPv6 privacy
   extensions, which in turn leads to the need for a minimum allocation
   of a /64 prefix rather than a single address.

>> Agree we should emphasise a minimum /64.

   In IPv6 world the assumption is that there is unrestricted
   availability of a large amount of globally routable and unique IPv6
   addresses.  The ISP will not be motivated to allocate private
   addresses towards the single user connection because he has enough
   global addresses available, if scarcity was the motivation with IPv4
   to provide RFC 1918 addresses.  If the single user wants to mask his
   identity, he may choose to enable IPv6 privacy extensions.

>> Can he, if the ISP may try to enforce the use of a single address?

   When looking in chapter 2.3 of RFC3314 'Recommendations for
   IPv6 in 3GPP Standards' [14] it is found that the IPv6 WG recommends
   that one or more /64 prefixes should be assigned to each primary PDP
   context.  This will allow sufficient address space for a 3GPP-
   attached node to allocate privacy addresses and/or route to a multi-
   link subnet, and  will discourage the use of NAT within 3GPP-attached
   devices.

>> I guess an ISP/carrier may use RFC1918 addresses for its infrastructure
>> independently of assignemnts to end customers.

6.  IPv6 gap analysis

      Like IPv4 and any major standards effort, IPv6 standardization
   work continues as deployments are ongoing.  This section discusses
   several topics for which additional standardization, or documentation
   of best practice, is required to fully realize the benefits of NAP.
   None of these items are show-stoppers for immediate usage of NAP in
   roles where there are no current gaps.

>> Maybe this should all be punted to a separate draft??   It would be 
>> nice to see NAP as a long-lived document, and this section will be
>> quite fluid?   Or call 'Recommendations for further work'?   Hmmm.

Other comments:

>>  Maybe mention that in the 'real world' IPv4 NAT + IPv6 globals are likely
>>  to run dual-stack.  What is the implication on security there?   How can
>>  firewalls/CPE equipment be configured consistently between the two?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Aug 2005 09:59:33 +0200

Yes, this is a fairly silly way to state it.

We should perhaps put ULAs, draft-narten-iana-rir-ipv6-considerations,
and draft-narten-ipv6-3177bis-48boundary as the references here.

    Brian