Network Working Group                                    G. Van de Velde
Internet-Draft                                              C. Popoviciu
Expires: September 4, December 22, 2007                                 Cisco Systems
                                                                T. Chown
                                               University of Southampton
                                                              O. Bonness
                                                                 C. Hahn
                                      T-Systems Enterprise Services GmbH
                                                           March 3,
                                                           June 20, 2007

             IPv6 Unicast Address Assignment Considerations
                    <draft-ietf-v6ops-addcon-03.txt>
                    <draft-ietf-v6ops-addcon-04.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 4, December 22, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   One fundamental aspect of any IP communications infrastructure is its
   addressing plan.  With its new address architecture and allocation
   policies, the introduction of IPv6 into a network means that network
   designers and operators need to reconsider their existing approaches
   to network addressing.  Lack of guidelines on handling this aspect of
   network design could slow down the deployment and integration of
   IPv6.  This document aims to provide the information and
   recommendations relevant to planning the addressing aspects of IPv6
   deployments.  The document also provides IPv6 addressing case studies
   for both an enterprise and an ISP network.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Network Level Addressing Design Considerations . . . . . . . .  5
     2.1.  Global Unique Addresses  . . . . . . . . . . . . . . . . .  5
     2.2.  Unique Local IPv6 Addresses  . . . . . . . . . . . . . . .  6
     2.3.  6Bone Address Space  . . . . . . . . . . . . . . . . . . .  7
     2.4.  Network Level Design Considerations  . . . . . . . . . . .  7
       2.4.1.  Sizing the Network Allocation  . . . . . . . . . . . .  8
       2.4.2.  Address Space Conservation . . . . . . . . . . . . . .  8  9
   3.  Subnet Prefix Considerations . . . . . . . . . . . . . . . . .  8  9
     3.1.  Considerations for subnet prefixes shorter then /64  . . .  9
     3.2.  Considerations for /64 prefixes  . . . . . . . . . . . . .  9 10
     3.3.  Considerations for subnet prefixes longer then /64 . . . .  9 10
       3.3.1.  Anycast addresses  . . . . . . . . . . . . . . . . . . 10
       3.3.2.  Addresses used by Embedded-RP (RFC3956)  . . . . . . . 11 12
       3.3.3.  ISATAP addresses . . . . . . . . . . . . . . . . . . . 12
       3.3.4.  /126 addresses . . . . . . . . . . . . . . . . . . . . 12 13
       3.3.5.  /127 addresses . . . . . . . . . . . . . . . . . . . . 12 13
       3.3.6.  /128 addresses . . . . . . . . . . . . . . . . . . . . 12 13
   4.  Allocation of the IID of an IPv6 Address . . . . . . . . . . . 13
     4.1.  Automatic EUI-64 Format Option . . . . . . . . . . . . . . 13 14
     4.2.  Using Privacy Extensions . . . . . . . . . . . . . . . . . 13
     4.3.  Cryptographically Generated IPv6 Addresses . . . . . . . . 14
     4.4.
     4.3.  Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14
   5.  Case Studies . . . .  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Enterprise 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . 15
       5.1.1.  Obtaining general IPv6 network prefixes  . . . . 15
   7.  Acknowledgements . . . 15
       5.1.2.  Forming an address (subnet) allocation plan . . . . . 16
       5.1.3.  Other considerations . . . . . . . . . . . . . . . 15
   8.  References . . 17
       5.1.4.  Node configuration considerations . . . . . . . . . . 17
     5.2.  Service Provider Considerations . . . . . . . . . . . . . 18
       5.2.1.  Investigation of objective Requirements for an
               IPv6  addressing schema of a Service Provider . 15
     8.1.  Normative References . . . 18
       5.2.2.  Exemplary IPv6 address allocation plan for a
               Service Provider . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . 21
       5.2.3.  Additional Remarks . . . . . . . . . . . . . . . 15
   Appendix A.  Case Studies  . . . 25
   6.  IANA Considerations . . . . . . . . . . . . . . . . . 17
     A.1.  Enterprise Considerations  . . . . 27
   7.  Security Considerations . . . . . . . . . . . . 18
       A.1.1.  Obtaining general IPv6 network prefixes  . . . . . . . 28
   8.  Acknowledgements 18
       A.1.2.  Forming an address (subnet) allocation plan  . . . . . 19
       A.1.3.  Other considerations . . . . . . . . . . . . . . . . . 19
       A.1.4.  Node configuration considerations  . 28
   9.  References . . . . . . . . . 20
     A.2.  Service Provider Considerations  . . . . . . . . . . . . . 21
       A.2.1.  Investigation of objective Requirements for an
               IPv6  addressing schema of a Service Provider  . . . . 28
     9.1.  Normative References 21
       A.2.2.  Exemplary IPv6 address allocation plan for a
               Service Provider . . . . . . . . . . . . . . . . . . . 28
     9.2.  Informative References 24
       A.2.3.  Additional Remarks . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 33

1.  Introduction

   The Internet Protocol Version 6 (IPv6) Addressing Architecture [26]
   defines three main types of addresses: unicast, anycast and
   multicast.  This document focuses on unicast addresses, for which
   there are currently two principal allocated types: Global Unique
   Addresses [14] ('globals') and Unique Local IPv6 Addresses [24]
   (ULAs).  In addition until recently there has been 'experimental'
   6bone address space [3], though its use has been deprecated since
   June 2006 [17].

   The document covers aspects that should be considered during IPv6
   deployment for the design and planning of an addressing scheme for an
   IPv6 network.  The network's IPv6 addressing plan may be for an IPv6-
   only network, or for a dual-stack infrastructure where some or all
   devices have addresses in both protocols.  These considerations will
   help an IPv6 network designer to efficiently and prudently assign the
   IPv6 address space that has been allocated to their organization.

   The address assignment considerations are analyzed separately for the
   two major components of the IPv6 unicast addresses, namely 'Network
   Level Addressing' (the allocation of subnets) and the 'interface-id'.
   Thus the document includes a discussion of aspects of address
   assignment to nodes and interfaces in an IPv6 network.  Finally the
   document provides two examples of deployed address plans in a service
   provider (ISP) and an enterprise network.

   Parts of this document highlight the differences that an experienced
   IPv4 network designer should consider when planning an IPv6
   deployment, for example:

   o  IPv6 devices will more likely be multi-addressed in comparison
      with their IPv4 counterparts
   o  The practically unlimited size of an IPv6 subnet (2^64 bits)
      reduces the requirement to size subnets to device counts for the
      purposes of (IPv4) address conservation
   o  Even though there is no broadcast for the IPv6 protocol, there is
      still need to consider the number of devices in a given subnet due
      to traffic storm and level of traffic generated by hosts
   o  The implications of the vastly increased subnet size on the threat
      of address-based host scanning and other scanning techniques, as
      discussed in [30].

   We do not discuss here how a site or ISP should proceed with
   acquiring its globally routable IPv6 address prefix.  However, one
   should note that IPv6 networks currently receive their global unicast
   address allocation from their 'upstream' provider, which may be
   another ISP, a Local Internet Registry (LIR) or a Regional Internet
   Registry (RIR).  In each case
   the prefix received is provider assigned (PA).  Until very recently there has been no (PA) or provider independent (PI) address space for IPv6 generally available.  However
   ARIN is now providing PI address space allocations, subject to
   customers meeting certain requirements.
   (PI).

   We do not discuss PI policy here.  The observations and
   recommendations of this text are largely independent of the PA or PI
   nature of the address block being used.  At this time we assume that
   most commonly an IPv6 network which changes provider will need to
   undergo a renumbering process, as described in [23].  A separate
   document [32] makes recommendations to ease the IPv6 renumbering
   process.

   This document does not discuss implementation aspects related to the
   transition between the ULA addresses and the now obsoleted site-local
   addresses.  Most implementations know about Site-local addresses even
   though they are deprecated, and do not know about ULAs - even though
   they represent current specification.  As result transitioning
   between these types of addresses may cause difficulties.

2.  Network Level Addressing Design Considerations

   This section discusses the kind of IPv6 addresses used at the network
   level for the IPv6 infrastructure.  The kind of addresses that can be
   considered are Global Unique Addresses and ULAs.  We also comment
   here on the recently deprecated 6bone address space.

2.1.  Global Unique Addresses

   The most commonly used unicast addresses will be Global Unique
   Addresses ('globals').  No significant considerations are necessary
   if the organization has an address space assignment and a single
   prefix is deployed through a single upstream provider.

   However, a multihomed site may deploy addresses from two or more
   Service Provider assigned IPv6 address ranges.  Here, the network
   Administrator must have awareness on where and how these ranges are
   used on the multihomed infrastructure environment.  The nature of the
   usage of multiple prefixes may depend on the reason for multihoming
   (e.g. resilience failover, load balancing, policy-based routing, or
   multihoming during an IPv6 renumbering event).  IPv6 introduces
   improved support for multi-addressed hosts through the IPv6 default
   address selection methods described in RFC3484 [12].  A multihomed
   host may thus have two addresses, one per prefix (provider), and
   select source and destination addresses to use as described in that
   RFC.  However multihoming also has some operative and administrative
   burdens besides chosing multiple addresses per interface [33]
   [34][35].

2.2.  Unique Local IPv6 Addresses

   ULAs have replaced the originally conceived Site Local addresses in
   the IPv6 addressing architecture, for reasons described in [19].
   ULAs improve on site locals by offering a high probability of the
   global uniqueness of the prefix used, which can be beneficial in the
   case of (deliberate or accidental) leakage, or where networks are
   merged.  ULAs are akin to the private address space [1] assigned for
   IPv4 networks, except that in IPv6 networks we may expect to see ULAs
   used alongside global addresses, with ULAs used internally and
   globals used externally.  Thus use of ULAs does not imply use of NAT
   for IPv6.

   The ULA address range allows network administrators to deploy IPv6
   addresses on their network without asking for a globally unique
   registered IPv6 address range.  A ULA prefix is 48 bits, i.e. a /48,
   the same as the currently recommended allocation for a site from the
   globally routable IPv6 address space [9].

   ULAs provide the means

   A site willing to deploy use ULA address space can have either (a) multiple
   /48 prefixes (e.g. a /44) and wishes to use ULAs, or (b) has one /48
   and wishes to use ULAs or (c) a site has a less-than-/48 prefix (e.g.
   a /56 or /64) and wishes to use ULAs.  In all above cases the ULA
   addresses can be randomly chosen according the principles specified
   in [19].  Using a random chosen ULA address will be conform in case
   (a) provide suboptimal aggregation capability, while in case (c)
   there will be overconsumption of address space.

   ULAs provide the means to deploy a fixed addressing scheme that is
   not affected by a change in service provider and the corresponding PA
   global addresses.  Internal operation of the network is thus
   unaffected during renumbering events.  Nevertheless, this type of
   address must be used with caution.

   A site using ULAs may or may not also deploy globals. global addresses.  In an
   isolated network ULAs may be deployed on their own.  In a connected
   network, that also deploys global addresses, both may be deployed,
   such that hosts become multiaddressed (one global and one ULA
   address) and the IPv6 default address selection algorithm will pick
   the appropriate source and destination addresses to use, e.g.  ULAs
   will be selected where both the source and destination hosts have ULA
   addresses.  Because a ULA and a global site prefix are both /48
   length, an administrator can choose to use the same subnetting (and
   host addressing) plan for both prefixes.

   As an example of the problems ULAs may cause, when using IPv6
   multicast within the network, the IPv6 default address selection
   algorithm prefers the ULA address as the source address for the IPv6
   multicast streams.  This is NOT a valid option when sending an IPv6
   multicast stream to the IPv6 Internet for two reasons.  For one,
   these addresses are not globally routable so RPF checks for such
   traffic will fail outside the internal network.  The other reason is
   that the traffic will likely not cross the network boundary due to
   multicast domain control and perimeter security policies.

   In principle ULAs allow easier network mergers than RFC1918 addresses
   do for IPv4 because ULA prefixes have a high probability of
   uniqueness, if the prefix is chosen as described in the RFC.

   The usage of ULAs should be carefully considered even when not
   attached to the IPv6 Internet due to the potential for added
   complexity when connecting to the Internet at as some point in IPv6 specifications were
   created before the
   future. existence of ULA addresses.

2.3.  6Bone Address Space

   The 6Bone address space was used before the RIRs started to
   distribute 'production' IPv6 prefixes.  The 6Bone prefixes have a
   common first 16 bits in the IPv6 Prefix of 3FFE::/16.  This address
   range is deprecated as of 6th June 2006 [17] and should must not be avoided used on
   any new IPv6 network deployments.  Sites using 6bone address space
   should renumber to production address space using procedures as
   defined in [23].

2.4.  Network Level Design Considerations

   IPv6 provides network administrators with a significantly larger
   address space, enabling them to be very creative in how they can
   define logical and practical address plans.  The subnetting of
   assigned prefixes can be done based on various logical schemes that
   involve factors such as:
   o  Using existing systems
      *  translate the existing subnet number into IPv6 subnet id
      *  translate the VLAN id into IPv6 subnet id
   o  Rethink
      *  allocate according to your need
   o  Aggregation
      *  Geographical Boundaries - by assigning a common prefix to all
         subnets within a geographical area
   o
      *  Organizational Boundaries - by assigning a common prefix to an
         entire organization or group within a corporate infrastructure
   o
      *  Service Type - by reserving certain prefixes for predefined
         services such as: VoIP, Content Distribution, wireless
         services, Internet Access, etc Security areas etc.  This type of
         addressing may create dependencies on IP addresses that can
         make renumbering harder if the nodes or interfaces supporting
         those services on the network are sparse within the topology.

   Such logical addressing plans have the potential to simplify network
   operations and service offerings, and to simplify network management
   and troubleshooting.  A very large network would also have no need to
   consider using private address space for its infrastructure devices,
   simplifying network management.

   The network designer must however keep in mind several factors when
   developing these new addressing schemes: schemes for networks with and without
   global connectivity:
   o  Prefix Aggregation - The larger IPv6 addresses can lead to larger
      routing tables unless network designers are actively pursuing
      aggregation.  While prefix aggregation will be enforced by the
      service provider, it is beneficial for the individual
      organizations to observe the same principles in their network
      design process
   o  Network growth - The allocation mechanism for flexible growth of a
      network prefix, documented in RFC3531 [13] can be used to allow
      the network infrastructure to grow and be numbered in a way that
      is likely to preserve aggregation (the plan leaves 'holes' for
      growth)
   o  ULA usage in large networks - Networks which have a large number
      of 'sites' that each deploy a ULA prefix which will by default be
      a 'random' /48 under fc00::/7 will have no aggregation of those
      prefixes.  Thus the end result may be cumbersome because the
      network will have large amounts of non-aggregated ULA prefixes.
      However, there is no rule to disallow large networks to use a
      single ULA for all 'sites', as a ULA still provides 16 bits for
      subnetting to be used internally
   o  It is possible that as registry policies evolve, a small site may
      experience an increase in prefix length when renumbering, e.g.
      from /48 to /56.  For this reason, the best practice is number
      subnets compactly rather than sparsely, and to use low-order bits
      as much as possible when numbering subnets.  In other words, even
      if a /48 is allocated, act as though only a /56 is available.
      Clearly, this advice does not apply to large sites and enterprises
      that have an intrinsic need for a /48 prefix.

2.4.1.  Sizing the Network Allocation

   We do not discuss here how a network designer sizes their application
   for address space.  By default a site will receive a /48 prefix [9] ,
   however different RIR service regions policies may suggest
   alternative default assignments or let the ISPs to decide on what
   they believe is more appropriate for their specific case [28].  The
   default provider allocation via the RIRs is currently a /32 [31].
   These allocations are indicators for a first allocation for a
   network.  Different sizes may be obtained based on the anticipated
   address usage [31].  There are examples of allocations as large as
   /19 having been made from RIRs to providers at the time of writing.

2.4.2.  Address Space Conservation

   Despite the large IPv6 address space which enables easier subnetting,
   it still is important to ensure an efficient use of this resource.
   Some addressing schemes, while facilitating aggregation and
   management, could lead to significant numbers of addresses being
   unused.  Address conservation requirements are less stringent in IPv6
   but they should still be observed.

   The proposed HD [10] value for IPv6 is 0.94 compared to the current
   value of 0.96 for IPv4.  Note that for IPv6 HD is calculated for
   sites (i.e. (e.g. on a basis of /48), instead of based on addresses like
   with IPv4.

3.  Subnet Prefix Considerations

   This section analyzes the considerations applied to define the subnet
   prefix of the IPv6 addresses.  The boundaries of the subnet prefix
   allocation are specified in RFC4291 [26].  In this document we
   analyze their practical implications.  Based on RFC4291 [26] it is
   legal for any IPv6 unicast address starting with binary address '000'
   to have a subnet prefix larger than, smaller than or of equal to 64
   bits.  Each of these three options is discussed in this document.

3.1.  Considerations for subnet prefixes shorter then /64

   An allocation of a prefix shorter then 64 bits to a node or interface
   is considered bad practice.  One exception to this statement is when
   using 6to4 technology where a /16 prefix is utilised for the pseudo-
   interface [8].  The shortest subnet prefix that could theoretically
   be assigned to an interface or node is limited by the size of the
   network prefix allocated to the organization.  One
   exception to this recommendation is when using 6to4 technology where
   a /16 prefix is utilised for the pseudo-interface [8].

   A possible reason for choosing the subnet prefix for an interface
   shorter then /64 is that it would allow more nodes to be attached to
   that interface compared to a prescribed length of 64 bits.  This
   however is unnecessary for most networks considering that 2^64
   provides plenty of node
   addresses for a well designed IPv6 network.  Layer two technologies
   are unlikely to support such large numbers of nodes within a single
   link (e.g.  Ethernet limited to 48-bits of hosts) addresses.

   The subnet prefix assignments can be made either by manual
   configuration, by a stateful Host Configuration Protocol [11] or [11], by a
   stateful prefix delegation mechanism [16]. [16] or implied by stateless
   autoconfiguration from prefix RAs.

3.2.  Considerations for /64 prefixes

   Based on RFC3177 [9], 64 bits is the prescribed subnet prefix length
   to allocate to interfaces and nodes.

   When using a /64 subnet length, the address assignment for these
   addresses can be made either by manual configuration, by a stateful
   Host Configuration Protocol [11] [18] or by stateless
   autoconfiguration [2].

   Note that RFC3177 strongly prescribes 64 bit subnets for general
   usage, and that stateless autoconfiguration option is only defined
   for 64 bit subnets.  However, implementations could use proprietary
   mechanism for stateless autoconfiguration for different then 64 bit
   prefix length.

3.3.  Considerations for subnet prefixes longer then /64

   Address space conservation is the main motivation for using a subnet
   prefix length longer than 64 bits. bits, however this kind of address
   conservation is of futile benefit compared with the additional
   considerations one must make when creating and maintain an IPv6
   address plan.

   The address assignment can be made either by manual configuration or
   by a stateful Host Configuration Protocol [11].

   When assigning a subnet prefix of more then 80 bits, according to
   RFC4291 [26] "u" and "g" bits (respectively the 81st and 82nd bit)
   need to be taken into consideration and should be set correctly.  In
   currently implemented IPv6 protocol stacks, the relevance of the "u"
   (universal/local) bit and "g" (the individual/group) bit are marginal
   and typically will not show an issue when configured wrongly, however
   future implementations may turn out differently.

   When using subnet lengths longer then 64 bits, it is important to
   avoid selecting addresses that may have a predefined use and could
   confuse IPv6 protocol stacks.  The alternate usage may not be a
   simple unicast address in all cases.  The following points should be
   considered when selecting a subnet length longer then 64 bits.

3.3.1.  Anycast addresses

3.3.1.1.  Subnet Router Anycast Address

   RFC4291 [26] provides a definition for the required Subnet Router
   Anycast Address as follows:

    |                   n bits                   |   128-n bits   |
    +--------------------------------------------+----------------+
    |               subnet prefix                | 00000000000000 |
    +--------------------------------------------+----------------+

   It is recommended to avoid allocating this IPv6 address to a an device
   which is not expects to have a router. normal unicast address.  No additional
   dependencies for the subnet prefix while the EUI-64 and an IID
   dependencies will be discussed later in this document.

3.3.1.2.  Reserved IPv6 Subnet Anycast Addresses

   RFC2526 [4] stated that within each subnet, the highest 128 interface
   identifier values are reserved for assignment as subnet anycast
   addresses.

   The construction of a reserved subnet anycast address depends on the
   type of IPv6 addresses used within the subnet, as indicated by the
   format prefix in the addresses.

   The first type of Subnet Anycast addresses have been defined as
   follows for EUI-64 format:

    |           64 bits            |      57 bits     |   7 bits   |
    +------------------------------+------------------+------------+
    |        subnet prefix         | 1111110111...111 | anycast ID |
    +------------------------------+------------------+------------+

   The anycast address structure implies that it is important to avoid
   creating a subnet prefix where the bits 65 to 121 are defined as
   "1111110111...111" (57 bits in total) so that confusion can be
   avoided.

   For other IPv6 address types (that is, with format prefixes other
   than those listed above), the interface identifier is not in EUI-64
   format and may be other than 64 bits in length; these reserved subnet
   anycast addresses for such address types are constructed as follows:

    |           n bits             |    121-n bits    |   7 bits   |
    +------------------------------+------------------+------------+
    |        subnet prefix         | 1111111...111111 | anycast ID |
    +------------------------------+------------------+------------+
                                   |   interface identifier field  |

   In the case discussed above there is no additional dependency for the
   subnet prefix with the exception of the EUI-64 and an IID dependency.
   These will be discussed later in this document.

3.3.2.  Addresses used by Embedded-RP (RFC3956)

   Embedded-RP [20] reflects the concept of integrating the Rendezvous
   Point (RP) IPv6 address into the IPv6 multicast group address.  Due
   to this embedding and the fact that the length of the IPv6 address
   AND the IPv6 multicast address are 128 bits, it is not possible to
   have the complete IPv6 address of the multicast RP embedded as such.

   This resulted in a restriction of 15 possible RP-addresses per prefix
   that can be used with embedded-RP.  The space assigned for the
   embedded-RP is based on the 4 low order bits, while the remainder of
   the Interface ID is set to all '0'.

               [IPv6-prefix (64 bits)][60 bits all '0'][RIID]

                   Where: [RIID] = 4 bit.

   This format implies that when selecting subnet prefixes longer then
   64, and the bits beyond the 64th one are non-zero, the subnet can not
   use embedded-RP.

   In addition it is discouraged to assign a matching embedded-RP IPv6
   address to a device that is not a real Multicast Rendezvous Point,
   eventhough it would not generate major problems.

3.3.3.  ISATAP addresses

   ISATAP [25] is an experimental automatic tunneling protocol used to
   provide IPv6 connectivity over an IPv4 campus or enterprise
   environment.  In order to leverage the underlying IPv4
   infrastructure, the IPv6 addresses are constructed in a special
   format.

   An IPv6 ISATAP address has the IPv4 address embedded, based on a
   predefined structure policy that identifies them as an ISATAP
   address.

                [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
   When using subnet prefix length longer then 64 bits it is recommended
   that good
   engineering practice that the portion of the IPv6 prefix from bit 65
   to the end of the subnet prefix host-id does not match with the well-known ISATAP [0000:
   5EFE]
   [0000:5EFE] address portion. when assigning an IPv6 address to a non-ISATAP
   interface.

   In its actual definition there is no multicast support on ISATAP ISATAP.

3.3.4.  /126 addresses

   The 126 bit subnet prefixes are typically used for point-to-point
   links similar to a the IPv4 address conservative /30 allocation for
   point-to-point links.  The usage of this subnet address length does
   not lead to any additional considerations other than the ones
   discussed earlier in this section, particularly those related to the
   "u" and "g" bits.

3.3.5.  /127 addresses

   The usage of the /127 addresses is not valid and should be strongly
   discouraged as documented in RFC3627 [15].

3.3.6.  /128 addresses

   The 128 bit address prefix may be used in those situations where we
   know that one, and only one address is sufficient.  Example usage
   would be the off-link loopback address of a network device.

   When choosing a 128 bit prefix, it is recommended to take the "u" and
   "g" bits into consideration and to make sure that there is no overlap
   with either the following well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses

4.  Allocation of the IID of an IPv6 Address

   In order to have a complete IPv6 address, an interface must be
   associated a prefix and an Interface Identifier (IID).  Section 3 of
   this document analyzed the prefix selection considerations.  This
   section discusses the elements that should be considered when
   assigning the IID portion of the IPv6 address.

   There are various ways to allocate an IPv6 address to a device or
   interface.  The option with the least amount of caveats for the
   network administrator is that of EUI-64 [2] based addresses.  For the
   manual or dynamic options, the overlap with well known IPv6 addresses
   should be avoided.

4.1.  Automatic EUI-64 Format Option

   When using this method the network administrator has to allocate a
   valid 64 bit subnet prefix.  The EUI-64 [2] allocation procedure can
   from that moment onward assign the remaining 64 IID bits in a
   stateless manner.  All the considerations for selecting a valid IID
   have been incorporated in the EUI-64 methodology.

4.2.  Using Privacy Extensions

   The main purpose of IIDs generated based on RFC3041 [6] is to provide
   privacy to the entity using this address.  While there are no
   particular constraints in the usage of these addresses as defined in
   [6] there are some implications to be aware of when using privacy
   addresses as documented in section 4 of RFC3041 [6]:
   o  The privacy extension algorithm may complicate flexibility in
      future transport protocols
   o  These addresses may add complexity to the operational management
      and troubleshooting of the infrastructure (i.e. which address
      belongs to which real host)
   o  A reverse DNS lookup check may be broken when using privacy
      extensions [6]

4.3.   Cryptographically Generated IPv6 Addresses

   Cryptographically Generated Addresses (CGAs)  Manual/Dynamic Assignment Option

   This section discusses those IID allocations that are based upon RFC3972
   [22] and provide a method for binding a public signature key to an
   IPv6 not implemented
   through stateless address in configuration (Section 4.1).  They are
   applicable regardless of the Secure Neighbor Discovery (SEND) protocol [21].

   The basic idea prefix length used on the link.  It is
   out of scope for this section to generate discuss the interface identifier (i.e. various assignment
   methods (e.g. manual configuration, DHCPv6, etc).

   In this situation the
   rightmost 64 bits) of actual allocation is done by human intervention
   and consideration needs to be given to the complete IPv6 address by computing a cryptographic
   hash of the public key.  The resulting IPv6 address is called a
   cryptographically generated address (CGA).  The corresponding private
   key can then be used to sign messages sent from that address.

   Implications to be aware of when using CGA addresses are found in
   section 7 of RFC3972 [22]:
   o  When using CGA addresses the values of the "u" and "g" bits are
      ignored however it does not add any security or implementation
      implications
   o  There is no mechanism for proving that an address is not a CGA
   o  When it is discovered that a node has been compromised, a new
      signature key and a new CGA should be generated

   Due to the fact that CGA generated addresses are almost
   indistinguishable from a privacy address and has similar properties
   for many purposes, the same considerations as with privacy addresses
   are also valid for CGA generated addresses.

4.4.  Manual/Dynamic Assignment Option

   This section discusses those IID allocations that are not implemented
   through stateless address configuration (Section 4.1).  They are
   applicable regardless of the prefix length used on the link.  It is
   out of scope for this section to discuss the various assignment
   methods (e.g. manual configuration, DHCPv6, etc).

   In this situation the actual allocation is done by human intervention
   and consideration needs to be given to the complete IPv6 address so
   that it does not result in overlaps with any so
   that it does not result in overlaps with any of the well known IPv6
   addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses

   When using an address assigned by human intervention it is
   recommended to choose IPv6 addresses which are not obvious to guess
   and/or avoid any IPv6 addresses that embed IPv4 addresses used in the
   current infrastructure.  Following these two recommendations will
   make it more difficult for malicious third parties to guess targets
   for attack, and thus reduce security threats to a certain extent.

5.  Case Studies

5.1.  Enterprise  IANA Considerations

   In

   There are no extra IANA consideration for this section we consider a case study of a campus network that is
   deploying document.

6.  Security Considerations

   This IPv6 in parallel with existing IPv4 protocols in a dual-
   stack environment.  The specific example is the University of
   Southampton (UK), focusing on a large department within that network.
   The deployment currently spans around 1,000 hosts addressing document does not have any direct impact on
   Internet infrastructure security.

7.  Acknowledgements

   Constructive feedback and over 1,500
   users.

5.1.1.  Obtaining general IPv6 network prefixes

   In the case of a campus network, the site will typically take its
   connectivity contributions have been received from its National Research Marla
   Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete,
   Carlos Garcia Braschi, Brian Carpenter, Mark Smith, Janos Mohacsi,
   Jim Bound, Fred Templin and Education Network (NREN).
   Southampton connects to JANET, the UK academic network, via its local
   regional network LeNSE.  JANET currently has a /32 allocation from
   RIPE of 2001:630::/32.  The current recommended practice is for sites
   to receive a /48 allocation, Ginny Listman.

8.  References

8.1.  Normative References

8.2.  Informative References

   [1]   Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and on this basis Southampton has
   received such a prefix E.
         Lear, "Address Allocation for its own use, specifically 2001:630:
   d0::/48.  The regional network also uses its own allocation from the
   NREN provider.

   No ULA addressing is used on site.  The campus is not multihomed
   (JANET is the sole provider), nor does it expect to change service
   provider, Private Internets", BCP 5,
         RFC 1918, February 1996.

   [2]   Thomson, S. and thus does not plan to use ULAs for the (perceived)
   benefit of easing network renumbering.  Indeed, the campus has
   renumbered following the aforementioned renumbering procedure [23] on
   two occasions, T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [3]   Hinden, R., Fink, R., and this has proven adequate (with provisos documented
   in [32].  We also do not see any need to deploy ULAs for in or out of
   band network management; there are enough J. Postel, "IPv6 Testing Address
         Allocation", RFC 2471, December 1998.

   [4]   Johnson, D. and S. Deering, "Reserved IPv6 prefixes available in
   the site allocation Subnet Anycast
         Addresses", RFC 2526, March 1999.

   [5]   Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-
         Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021,
         December 2000.

   [6]   Narten, T. and R. Draves, "Privacy Extensions for the infrastructure.  In some cases, use of
   private IP address space Stateless
         Address Autoconfiguration in IPv4 creates problems, so we believe that
   the availability IPv6", RFC 3041, January 2001.

   [7]   Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
         Tunnel Broker", RFC 3053, January 2001.

   [8]   Carpenter, B. and K. Moore, "Connection of ample global IPv6 address space for
   infrastructure may be a benefit Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [9]   IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
         Allocations to Sites", RFC 3177, September 2001.

   [10]  Durand, A. and C. Huitema, "The H-Density Ratio for many sites.

   No 6bone addressing is used Address
         Assignment Efficiency An Update on site any more.  We note that since the
   6bone phaseout of June 2006 [17] most transit ISPs have begun
   filtering attempted use of such prefixes.

   Southampton does participate in global H ratio", RFC 3194,
         November 2001.

   [11]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and organization scope IPv6
   multicast networks.  Multicast address allocations are not discussed
   here as they are not in scope M.
         Carney, "Dynamic Host Configuration Protocol for the document.  We note that IPv6
   has advantages for multicast group address allocation.  In IPv4 a
   site needs to use techniques like GLOP to pick a globally unique
   multicast group to use.  This is problematic if
         (DHCPv6)", RFC 3315, July 2003.

   [12]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [13]  Blanchet, M., "A Flexible Method for Managing the site does not use
   BGP and have Assignment of
         Bits of an ASN.  In IPv6 unicast-prefix-based IPv6 multicast
   addresses empower a site to pick a globally unique group address
   based on its unicast own site or link prefix.  Embedded RP is also in
   use, is seen as a potential advantage for IPv6 Address Block", RFC 3531, April 2003.

   [14]  Hinden, R., Deering, S., and multicast, E. Nordmark, "IPv6 Global Unicast
         Address Format", RFC 3587, August 2003.

   [15]  Savola, P., "Use of /127 Prefix Length Between Routers
         Considered Harmful", RFC 3627, September 2003.

   [16]  Troan, O. and has
   been tested successfully across providers between sites (including
   paths to/from the US R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633,
         December 2003.

   [17]  Fink, R. and UK).

5.1.2.  Forming an address (subnet) allocation plan

   The campus has a /16 prefix R. Hinden, "6bone (IPv6 Testing Address
         Allocation) Phaseout", RFC 3701, March 2004.

   [18]  Droms, R., "Stateless Dynamic Host Configuration Protocol
         (DHCP) Service for IPv4 use; in principle 256 subnets of
   256 addresses.  In reality IPv6", RFC 3736, April 2004.

   [19]  Huitema, C. and B. Carpenter, "Deprecating Site Local
         Addresses", RFC 3879, September 2004.

   [20]  Savola, P. and B. Haberman, "Embedding the subnetting is muddier, because of
   concerns of IPv4 address conservation; subnets are sized to the hosts
   within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts
   in it.  While this is efficient, it increases management burden when
   physical deployments change, and IPv4 subnets require resizing (up or
   down), even with DHCP in use.

   The /48 IPv6 prefix is considerably larger than the IPv4 allocation
   already in place at the site.  It is loosely equivalent to a 'Class
   A' IPv4 prefix Rendezvous Point
         (RP) Address in that it has 2^16 (over 65,000) subnets, but has an
   effectively unlimited subnet address size (2^64) compared to 256 in
   the IPv4 equivalent.  The increased subnet size means that /64 IPv6
   prefixes can be used on all subnets, without any requirement to
   resize them at a later date.  The increased subnet volume allows
   subnets to be allocated more generously to schools Multicast Address", RFC 3956,
         November 2004.

   [21]  Arkko, J., Kempf, J., Zill, B., and departments in
   the campus.  While address conservation is still important, it is no
   longer an impediment on network management.  Rather, address (subnet)
   allocation is more about embracing the available address space P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [22]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, March 2005.

   [23]  Baker, F., Lear, E., and
   planning R. Droms, "Procedures for future expansion.

   In Renumbering
         an IPv6 Network without a dual-stack network, we choose to deploy our IP subnets
   congruently for IPv4 Flag Day", RFC 4192, September 2005.

   [24]  Hinden, R. and IPv6.  This is because the systems are still
   in the same administrative domains B. Haberman, "Unique Local IPv6 Unicast
         Addresses", RFC 4193, October 2005.

   [25]  Templin, F., Gleeson, T., Talwar, M., and the same geography.  We do not
   expect to have IPv6-only subnets in production use for a while yet,
   outside our test beds D. Thaler, "Intra-
         Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
         October 2005.

   [26]  Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

   [27]  Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
         Configuration Protocol (DHCP): IPv4 and our early Mobile IPv6 trials.  With
   congruent addressing, our firewall policies are also aligned for Dual-Stack
         Issues", RFC 4477, May 2006.

   [28]  ARIN, "http://www.arin.net/policy/nrpm.html#six54".

   [29]  De Clerq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
         "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider
         Edge Routers (6PE) (draft-ooms-v6ops-bgp-tunnel-06.txt)",
         June 2006.

   [30]  Chown, T., "IPv6 Implications for TCP/UDP Port Scanning
         (draft-ietf-v6ops-scanning-implications-00.txt)", June 2006.

   [31]  APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment
         Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003.

   [32]  Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to
         think about when Renumbering an IPv6 traffic at our site border.

   The subnet allocation plan required a division network
         (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007.

   [33]  "List of the address space
   per school or department.  Here a /56 was allocated Internet-Drafts relevant to the school
   level of the university; there are around 30 schools currently.  A
   /56 of IPv6 address space equates Multi6-WG
         (http://ops.ietf.org/multi6/draft-list.html )".

   [34]  Lear, E., "Things MULTI6 Developers should think about
         (draft-ietf-multi6-things-to-think-about-01)", January 2005.

   [35]  Nordmark, E. and T. Li, "Threats relating to 256 /64 size subnet allocations.
   Further /56 allocations were made for central IT infrastructure, IPv6 multihoming
         solutions (draft-ietf-multi6-multihoming-threats-03)",
         January 2005.

Appendix A.  Case Studies

   This appendix contains two case studies for IPv6 addressing schemas
   that have been based on the network infrastructure statements and the server side systems.

5.1.3.  Other considerations

   The network uses a Demilitarized Zone (DMZ) topology for some level of protection of 'public' systems.  Again, this topology is congruent
   with the IPv4 network.

   There are no
   draft.  These case studies illustrate how this draft has been used in
   two specific transition methods deployed internally to the
   campus; everything is using the conventional dual-stack approach.
   There is no use of ISATAP [25] network scenarios.  The case studies may serve as basic
   considerations for example.

   For an administrator who designs the Mobile IPv6 early trials, we have allocated one prefix addressing
   schema for
   Home Agent (HA) use.  We have not yet considered in detail how Mobile
   IPv6 usage may grow, and whether more an enterprise or even every subnet will
   require HA support.

   The university operates a tunnel broker [7] service on behalf of
   UKERNA for JANET sites.  This uses separate address space from JANET, ISP network, but are not our university site allocation.

5.1.4.  Node configuration considerations

   We currently use stateless autoconfiguration on most subnets for IPv6
   hosts.  There is no DHCPv6 service deployed yet, beyond tests of
   early code releases.  We plan intended to deploy DHCPv6
   serve as general design proposal for address assignment
   when robust client and server code is available (at the time every kind of
   writing the potential for IPv6 network.

A.1.  Enterprise Considerations

   In this looks good, e.g. via the ISC
   implementation).  We also are seeking section we consider a common integrated DHCP/DNS
   management platform, even if the servers themselves are not co-
   located, including integrated DHCPv4 and DHCPv6 server configuration,
   as discussed case study of a campus network that is
   deploying IPv6 in [27].  Currently we add client statelessly
   autoconfigured addresses to the DNS manually, though dynamic DNS parallel with existing IPv4 protocols in a dual-
   stack environment.  The specific example is
   an option.  Our administrators would prefer the use of DHCP because
   they believe it gives them more management control.

   Regarding the implications University of the larger IPv6 subnet address space
   Southampton (UK), focusing on
   scanning attacks [30], we note a large department within that all our network.
   The deployment currently spans around 1,000 hosts are dual-stack, and
   thus are potentially exposed over both protocols anyway.  We publish
   all addresses in DNS, and do not operate a two faced DNS.

   We have internal usage 1,500
   users.

A.1.1.  Obtaining general IPv6 network prefixes

   In the case of RFC3041 privacy addresses [6] currently
   (certain platforms currently ship with it on by default), but may
   wish to administratively disable this (perhaps via DHCP) to ease
   management complexity.  However, we need a campus network, the site will typically take its
   connectivity from its National Research and Education Network (NREN).
   Southampton connects to determine JANET, the feasibility UK academic network, via its local
   regional network LeNSE.  JANET currently has a /32 allocation from
   RIPE of this on all systems, e.g. 2001:630::/32.  The current recommended practice is for guests on wireless LAN or other
   user-maintained systems.  Network management sites
   to receive a /48 allocation, and monitoring should be
   simpler without RFC3041 in operation, in terms of identifying which
   physical hosts are using which addresses.  We note that RFC3041 is
   only an issue on this basis Southampton has
   received such a prefix for outbound connections, and that there its own use, specifically 2001:630:
   d0::/48.  The regional network also uses its own allocation from the
   NREN provider.

   No ULA addressing is potential
   to assign privacy addresses via DHCPv6.

   We manually configure server addresses to avoid address changes used on a site.  The campus is not multihomed
   (JANET is the sole provider), nor does it expect to change service
   provider, and thus does not plan to use ULAs for the (perceived)
   benefit of easing network adaptor.  With IPv6 you can choose renumbering.  Indeed, the campus has
   renumbered following the aforementioned renumbering procedure [23] on
   two occasions, and this has proven adequate (with provisos documented
   in [32].  We also do not see any need to pick ::53 deploy ULAs for
   a DNS server, in or can pick 'random' addresses for obfuscation, though
   that's not an issue for publicly advertised addresses (dns, mx, web,
   etc).

5.2.  Service Provider Considerations

   In this section an out of
   band network management; there are enough IPv6 addressing schema is sketched that could
   serve as an example prefixes available in
   the site allocation for an Internet Service Provider.

   Sub-section 5.2.1 starts with the infrastructure.  In some thoughts regarding objective
   requirements cases, use of such an addressing schema and derives a few general
   thumb rules that have to be kept
   private IP address space in mind when designing an ISP IPv6
   addressing plan.

   Sub-section 5.2.2 illustrates these findings IPv4 creates problems, so we believe that
   the availability of 5.2.1 with an
   exemplary ample global IPv6 addressing schema for an MPLS-based ISP offering
   Internet Services as well as Network Access services to several
   millions of customers.

5.2.1.  Investigation of objective Requirements address space for an IPv6
   infrastructure may be a benefit for many sites.

   No 6bone addressing
        schema is used on site any more.  We note that since the
   6bone phaseout of a Service Provider

   The first step June 2006 [17] most transit ISPs have begun
   filtering attempted use of such prefixes.

   Southampton does participate in global and organization scope IPv6
   multicast networks.  Multicast address allocations are not discussed
   here as they are not in scope for the document.  We note that IPv6 addressing plan design
   has advantages for multicast group address allocation.  In IPv4 a Service
   provider should identify all technical, operational, political and
   business requirements that have
   site needs to be satisfied by the services
   supported by this addressing schema.

   According use techniques like GLOP to pick a globally unique
   multicast group to use.  This is problematic if the different technical constraints site does not use
   BGP and business models
   as well have an ASN.  In IPv6 unicast-prefix-based IPv6 multicast
   addresses empower a site to pick a globally unique group address
   based on its unicast own site or link prefix.  Embedded RP is also in
   use, is seen as a potential advantage for IPv6 and multicast, and has
   been tested successfully across providers between sites (including
   paths to/from the different weights US and UK).

A.1.2.  Forming an address (subnet) allocation plan

   The campus has a /16 prefix for IPv4 use; in principle 256 subnets of these requirements (from
   256 addresses.  In reality the
   point subnetting is muddier, because of view
   concerns of IPv4 address conservation; subnets are sized to the corresponding Service Provider) it is very
   likely that different addressing schemas will be developed and
   deployed by different ISPs.  Nevertheless the addressing schema of
   sub-section 5.2.2 hosts
   within them, e.g. a /26 IPv4 prefix is one possible example.

   For used if a subnet has 35 hosts
   in it.  While this document is efficient, it increases management burden when
   physical deployments change, and IPv4 subnets require resizing (up or
   down), even with DHCP in use.

   The /48 IPv6 prefix is assumed considerably larger than the IPv4 allocation
   already in place at the site.  It is loosely equivalent to a 'Class
   A' IPv4 prefix in that our exemplary ISP it has 2^16 (over 65,000) subnets, but has to fulfill
   several roles for its customers as there are:

   o  Local Internet Registry
   o  Network Access Provider
   o  Internet Service Provider

5.2.1.1.  Requirements for an IPv6 addressing schema from the LIR
          perspective of the Service Provider

   In their role as LIR the Service Providers have
   effectively unlimited subnet address size (2^64) compared to care about the
   policy constraints of the RIRs and the standards of 256 in
   the IETF
   regarding IPv4 equivalent.  The increased subnet size means that /64 IPv6 addressing.  In this context, the following basic
   requirements and recommendations have
   prefixes can be used on all subnets, without any requirement to
   resize them at a later date.  The increased subnet volume allows
   subnets to be considered allocated more generously to schools and should be
   satisfied by departments in
   the IPv6 campus.  While address conservation is still important, it is no
   longer an impediment on network management.  Rather, address (subnet)
   allocation plan of a Service Provider:
   o  As recommended in RFC 3177 [9] is more about embracing the available address space and in several RIR policies
      "Common" customers sites (normally private customers) should
      receive
   planning for future expansion.

   In a /48 prefix from the aggregate of the Service Provider.
      (Note: The addressing plan must be flexible enough dual-stack network, we choose to deploy our IP subnets
   congruently for IPv4 and take into
      account IPv6.  This is because the possible change of systems are still
   in the minimum allocation size for end
      users currently under definition by same administrative domains and the RIRs.)
   o  "Big customers" (like big enterprises, governmental agencies etc.)
      may receive shorter prefixes according same geography.  We do not
   expect to their needs when this
      need could be documented have IPv6-only subnets in production use for a while yet,
   outside our test beds and justified to the RIR.
   o  The our early Mobile IPv6 address trials.  With
   congruent addressing, our firewall policies are also aligned for IPv4
   and IPv6 traffic at our site border.

   The subnet allocation schema has to be able to meet plan required a division of the HD-
      ratio that is proposed for IPv6.  This requirement corresponds address space
   per school or department.  Here a /56 was allocated to the demand for an efficient usage school
   level of the university; there are around 30 schools currently.  A
   /56 of IPv6 address aggregate by space equates to 256 /64 size subnet allocations.
   Further /56 allocations were made for central IT infrastructure, for
   the Service Provider.  (Note: network infrastructure and the server side systems.

A.1.3.  Other considerations

   The currently valid IPv6 HD-ratio of
      0.94 means an effective usage of about 31% of network uses a /20 prefix Demilitarized Zone (DMZ) topology for some level
   of the
      Service Provider on the basis protection of /48 assignments.)
   o  All assignments to customers have to be documented and stored into
      a database that can also be queried by 'public' systems.  Again, this topology is congruent
   with the RIR.
   o  The LIR has IPv4 network.

   There are no specific transition methods deployed internally to make available means for supporting the reverse DNS
      mapping of the customer prefixes.

5.2.1.2.  IPv6 addressing schema requirements from
   campus; everything is using the ISP perspective conventional dual-stack approach.
   There is no use of ISATAP [25] for example.

   For the Service Provider

   From ISP perspective the following basic requirements could be
   identified:
   o  The Mobile IPv6 address allocation schema must be able to realize early trials, we have allocated one prefix for
   Home Agent (HA) use.  We have not yet considered in detail how Mobile
   IPv6 usage may grow, and whether more or even every subnet will
   require HA support.

   The university operates a
      maximal aggregation tunnel broker [7] service on behalf of all IPv6
   UKERNA for JANET sites.  This uses separate address delegations space from JANET,
   not our university site allocation.

A.1.4.  Node configuration considerations

   We currently use stateless autoconfiguration on most subnets for IPv6
   hosts.  There is no DHCPv6 service deployed yet, beyond tests of
   early code releases.  We plan to customers
      into the deploy DHCPv6 for address aggregate assignment
   when robust client and server code is available (at the time of
   writing the Service Provider.  Only potential for this
      provider aggregate will be routed and injected into the global
      routing table (DFZ).  This strong aggregation keeps looks good, e.g. via the routing
      tables of ISC
   implementation).  We also are seeking a common integrated DHCP/DNS
   management platform, even if the DFZ small and eases filtering servers themselves are not co-
   located, including integrated DHCPv4 and access control
      very much.
   o  The IPv6 addressing schema of DHCPv6 server configuration,
   as discussed in [27].  Currently we add client statelessly
   autoconfigured addresses to the SP should contain maximal
      flexibility since DNS manually, though dynamic DNS is
   an option.  Our administrators would prefer the infrastructure use of DHCP because
   they believe it gives them more management control.

   Regarding the SP will change over
      the time with new customers, transport technologies and business
      cases.  The requirement implications of maximal flexibility is contrary to the
      requirements of strong larger IPv6 subnet address aggregation space on
   scanning attacks [30], we note that all our hosts are dual-stack, and efficient
      address usage,
   thus are potentially exposed over both protocols anyway.  We publish
   all addresses in DNS, and do not operate a two faced DNS.

   We have internal usage of RFC3041 privacy addresses [6] currently
   (certain platforms currently ship with it on by default), but at may
   wish to administratively disable this point each SP has (perhaps via DHCP) to decide which of
      these requirements ease
   management complexity.  However, we need to prioritize.

   o  Keeping determine the multilevel network hierarchy feasibility
   of an ISP in mind, due to
      addressing efficiency reasons not this on all hierarchy levels can systems, e.g. for guests on wireless LAN or other
   user-maintained systems.  Network management and monitoring should be mapped into the IPv6 addressing schema of an ISP.
      Sometimes it
   simpler without RFC3041 in operation, in terms of identifying which
   physical hosts are using which addresses.  We note that RFC3041 is much better to implement "flat" addressing
   only an issue for the
      ISP network than outbound connections, and that there is potential
   to loose big chunks of the IPv6 assign privacy addresses via DHCPv6.

   We manually configure server addresses to avoid address aggregate
      in addressing each level of network hierarchy.  Besides that changes on a
      decoupling
   change of provider network adaptor.  With IPv6 you can choose to pick ::53 for
   a DNS server, or can pick 'random' addresses for obfuscation, though
   that's not an issue for publicly advertised addresses (dns, mx, web,
   etc).

A.2.  Service Provider Considerations

   In this section an IPv6 addressing and customer addressing schema is recommended.  (Note: A strong aggregation e.g. on POP,
      aggregation router or Label Edge Router (LER) level limits the
      numbers sketched that could
   serve as an example for an Internet Service Provider.

   Sub-section A.2.1 starts with some thoughts regarding objective
   requirements of customer routes such an addressing schema and derives a few general
   thumb rules that are visible within the have to be kept in mind when designing an ISP network
      but brings also down the efficiency IPv6
   addressing plan.

   Sub-section A.2.2 illustrates these findings of the A.2.1 with an
   exemplary IPv6 addressing schema.
      That's why each schema for an MPLS-based ISP has to decide how many internal aggregation
      levels it wants offering
   Internet Services as well as Network Access services to deploy.)

5.2.1.3. several
   millions of customers.

A.2.1.  Investigation of objective Requirements for an IPv6  addressing
        schema requirements from the Network Access
          provider perspective of the a Service Provider

   As already done for

   The first step of the LIR IPv6 addressing plan design for a Service
   provider should identify all technical, operational, political and
   business requirements that have to be satisfied by the ISP roles services
   supported by this addressing schema.

   According to the different technical constraints and business models
   as well as the different weights of these requirements (from the
   point of view of the SP corresponding Service Provider) it is also
   necessary to identify requirements very
   likely that come from different addressing schemas will be developed and
   deployed by different ISPs.  Nevertheless the addressing schema of
   sub-section A.2.2 is one possible example.

   For this document it is assumed that our exemplary ISP has to fulfill
   several roles for its customers as there are:

   o  Local Internet Registry
   o  Network Access Provider role.  Some of the basic requirements are:
   o  The  Internet Service Provider

A.2.1.1.  Requirements for an IPv6 addressing schema from the LIR
          perspective of the SP must be flexible enough to
      adapt changes that are injected from Service Provider

   In their role as LIR the customer side.  This
      covers changes Service Providers have to addressing architecture or routing topology that
      are triggered from for instance care about the growing needs
   policy constraints of the customers
      regarding IPv6 addresses as well as changes that come from
      topological modifications (e.g. when RIRs and the customer moves from one
      point standards of network attachment (POP) to another).
   o  For each the IETF
   regarding IPv6 address assignment addressing.  In this context, the following basic
   requirements and recommendations have to customers a "buffer zone" must be reserved that allows considered and should be
   satisfied by the customer to grow in its addressing
      range without renumbering or assignment of additional prefixes.
   o  The IPv6 addressing schema of the SP must deal with multiple-
      attachments address allocation plan of a single customer to the SP network infrastructure
      (i.e. multi-homed network access with Service Provider:
   o  As recommended in RFC 3177 [9] and in several RIR policies
      "Common" customers sites (normally private customers) should
      receive a /48 prefix from the same SP).

   These few requirements are only part aggregate of all the requirements a Service Provider has to investigate Provider.

      (Note: The addressing plan must be flexible enough and keep in mind during take into
      account the
   definition phase possible change of its addressing architecture.  Each SP will most
   likely add more constraints to this list.

5.2.1.4.  A few thumb rules the minimum allocation size for designing an IPv6 ISP addressing
          architecture

   As outcome of end
      users currently under definition by the above enumeration of requirements regarding an ISP
   IPv6 addressing plan RIRs.)
   o  "Big customers" (like big enterprises, governmental agencies etc.)
      may receive shorter prefixes according to their needs when this
      need could be documented and justified to the following design "thumb rules" have been
   derived: RIR.
   o  No "One size fits all" Each ISP must develop its own  The IPv6 address allocation schema depending on its concrete business needs.  It is
      not practicable has to design one addressing plan be able to meet the HD-
      ratio that fits is proposed for all
      kinds of ISPs (Small / big, Routed / MPLS-based, access / transit,
      LIR / No-LIR, etc.).
   o  The levels IPv6.  This requirement corresponds to
      the demand for an efficient usage of the IPv6 address aggregation within the ISP addressing
      schema should strongly correspond to aggregate by
      the implemented network
      structure and their number should be minimized because of
      efficiency reasons.  It is assumed that the SPs own infrastructure
      will be addressed in Service Provider.  (Note: The currently valid IPv6 HD-ratio of
      0.94 means an effective usage of about 31% of a fairly flat way whereas the part /20 prefix of the
      customer addressing architecture should contain several levels
      Service Provider on the basis of
      aggregation. /48 assignments.)
   o  Keep  All assignments to customers have to be documented and stored into
      a database that can also be queried by the number RIR.
   o  The LIR has to make available means for supporting the reverse DNS
      mapping of IPv6 customer routes inside your network as
      small as necessary.  A totally flat the customer prefixes.

A.2.1.2.  IPv6 addressing
      architecture without any intermediate aggregation level will lead
      to lots of customer routes inside the SP network.  A fair trade-
      off between address aggregation levels (and hence the size of schema requirements from the
      internal routing table ISP perspective
          of the SP) and address conservation of Service Provider

   From ISP perspective the
      addressing architecture has to following basic requirements could be found.
   identified:
   o  The ISP IPv6 addressing address allocation schema should provide maximal flexibility.
      This has to must be realized for supporting different sizes able to realize a
      maximal aggregation of customer all IPv6 address aggregates ("big" customers vs. "small" customers) as
      well as delegations to allow future growing rates (e.g. customers
      into the address aggregate of customer
      aggregates) the Service Provider.  Only this
      provider aggregate will be routed and possible topological or infrastructural changes.
   o  A limited number of injected into the global
      routing table (DFZ).  This strong aggregation levels and sizes of customer
      aggregates will ease keeps the management routing
      tables of the addressing schema.
      This has to be weighed against the previous "thumb rule" -
      flexibility.

5.2.2.  Exemplary IPv6 address allocation plan for a Service Provider

   In this example, the Service Provider is assumed to operate an MPLS
   based backbone DFZ small and implements 6PE [29] to provide IPv6 backbone
   transport between the different locations (POPs) of a fully dual-
   stacked network access eases filtering and aggregation area.

   Besides that it is assumed that the Service Provider:
   o  has received a /20 from its RIR
   o  operates its own LIR access control
      very much.
   o  has to address its own  The IPv6 infrastructure
   o  delegates prefixes from this aggregate to its customers

   This addressing schema of the SP should illustrate how contain optimal
      flexibility since the /20 IPv6 prefix infrastructure of the SP can be used to address will change over
      the SP-own infrastructure time with new customers, transport technologies and business
      cases.  The requirement of optimal flexibility is contrary to
   delegate IPv6 prefixes to its customers following the above mentioned
      requirements of strong IPv6 address aggregation and thumb rules as far as possible.

   The below figure summarizes the device types in an efficient
      address usage, but at this point each SP network and the
   typical network design has to decide which of a MPLS-based service provider.  The
      these requirements to prioritize.
   o  Keeping the multilevel network hierarchy of the SP has an ISP in mind, due to
      addressing efficiency reasons not all hierarchy levels can and
      should be taken mapped into account for the design of an IPv6 addressing schema and defines its basic shape and the various
   levels of aggregation.

   +------------------------------------------------------------------+
   |               LSRs of the MPLS Backbone of an ISP.
      Sometimes it is much better to implement a more "flat" addressing
      for the SP                |
   +------------------------------------------------------------------+
      |        |             |              |                 |
      |        |             |              |                 |
   +-----+  +-----+     +--------+     +--------+         +--------+
   | LER |  | LER |     | LER-BB |     | LER-BB |         | LER-BB |
   +-----+  +-----+     +--------+     +--------+         +--------+
    |   |    |   |        |    |      /     |              |     |
    |   |    |   |        |    |     /      |              |     |
    |   |    |   |  +------+  +------+   +------+          |     |
    |   |    |   |  |BB-RAR|  |BB-RAR|   |  AG  |          |     |
    |   |    |   |  +------+  +------+   +------+          |     |
    |   |    |   |    |  |      |  |      |    |           |     |
    |   |    |   |    |  |      |  |      |    |           |     |
    |   |    |   |    |  |      |  | +-----+  +-----+  +-----+  +-----+
    |   |    |   |    |  |      |  | | RAR |  | RAR |  | RAR |  | RAR |
    |   |    |   |    |  |      |  | +-----+  +-----+  +-----+  +-----+
    |   |    |   |    |  |      |  |  |   |    |   |    |   |    |   |
    |   |    |   |    |  |      |  |  |   |    |   |    |   |    |   |
   +-------------------------------------------------------------------+
   |                       Customer networks                           |
   +-------------------------------------------------------------------+
   Figure: Exemplary Service Provider Network

   LSR    ... Label Switch Router
   LER    ... Label Edge Router
   LER-BB ... Broadband ISP network than to loose big chunks of the IPv6 address
      aggregate in addressing each level of network hierarchy.  (Note:
      In special cases it is even recommendable for really "small" ISPs
      to design and implement a totally flat IPv6 addressing schema
      without any level of hierarchy.)
   o  Besides that a decoupling of provider network addressing and
      customer addressing is recommended.  (Note: A strong aggregation
      e.g. on POP, aggregation router or Label Edge Router
   RAR    ... Remote Access Router
   BB-RAR ... Broadband Remote Access Router
   AG     ... Aggregation Router

   Basic design decisions for (LER) level
      limits the exemplary Service Provider IPv6
   address plan regarding numbers of customer prefixes take into consideration:
   o  The prefixes assigned to all customers behind the same LER (e.g.
      LER or LER-BB) are aggregated under one LER prefix.  This ensures routes that are visible within the number
      ISP network but brings also down the efficiency of labels that have the IPv6
      addressing schema.  That's why each ISP has to be used decide how many
      internal aggregation levels it wants to deploy.)

A.2.1.3.  IPv6 addressing schema requirements from the Network Access
          provider perspective of the Service Provider

   As already done for 6PE is limited the LIR and hence provides a strong MPLS label conservation.
   o  The /20 prefix the ISP roles of the SP it is separated into 3 different pools that
      are used to allocate IPv6 prefixes also
   necessary to identify requirements that come from its Network Access
   Provider role.  Some of the customers basic requirements are:
   o  The IPv6 addressing schema of the SP:
      *  A pool (e.g. /24) SP must be chosen in a way that
      it can handle new requirements that are triggered from customer
      side.  This can be for satisfying instance the addressing growing needs of really
         "big" the customers (as defined in 5.2.2.1 sub-section A.) that
         need
      regarding IPv6 prefixes larger than /48 addresses as well as customer driven modifications
      within the access network topology (e.g. /32).  These customers
         are assumed when the customer moves
      from one point of network attachment (POP) to another).  (See
      section A.2.3.4 "Changing Point of Network Attachment".)
   o  For each IPv6 address assignment to customers a "buffer zone"
      should be connected to several POPs of the access
         network, so reserved that this allows the customer prefix will be visible to grow in each its
      addressing range without renumbering or assignment of additional
      prefixes.
   o  The IPv6 addressing schema of these POPs.
      *  A pool (e.g. /24) for the LERs SP must deal with direct multiple-
      attachments of a single customer connections
         (e.g. dedicated line access) and without an additional
         aggregation area between to the customer and SP network infrastructure
      (i.e. multi-homed network access with the LER.  (These LERs same SP).

   These few requirements are mostly connected to a limited number of customers because only part of all the limited number requirements a
   Service Provider has to investigate and keep in mind during the
   definition phase of interfaces/ports.)
      * its addressing architecture.  Each SP will most
   likely add more constraints to this list.

A.2.1.4.  A larger pool (e.g. 14*/24) few thumb rules for LERs (e.g.  LER-BB) that serve
         a high number designing an IPv6 ISP addressing
          architecture

   As outcome of customers the above enumeration of requirements regarding an ISP
   IPv6 addressing plan the following design "thumb rules" have been
   derived:
   o  No "One size fits all".  Each ISP must develop its own IPv6
      address allocation schema depending on its concrete business
      needs.  It is not practicable to design one addressing plan that are normally connected via some
         kind
      fits for all kinds of aggregation network (e.g.  DSL customers behind a BB-
         RAR or Dial-In customers behind a RAR).
      * ISPs (Small / big, Routed / MPLS-based,
      access / transit, LIR / No-LIR, etc.).
   o  The levels of IPv6 address delegation within each Pool (end customer
         delegation or also address aggregation within the aggregates that are dedicated ISP addressing
      schema should strongly correspond to the
         LERs itself) implemented network
      structure and their number should be chosen with an additional buffer zone minimized because of
         100% - 300% for future growth.  I.e. 1 or 2 additional prefix
         bits should
      efficiency reasons.  It is assumed that the SPs own infrastructure
      will be reserved according to addressed in a fairly flat way whereas the expected future growth
         rate part of the corresponding
      customer / the corresponding network
         device aggregate.

5.2.2.1.  Defining an IPv6 address allocation plan for customers addressing architecture should contain several levels of
      aggregation.
   o  Keep the
          Service Provider

5.2.2.1.1.  'Big' customers

   SP's "big" customers receive their prefix from the /24 number of IPv6 address
   aggregate that has been reserved for their "big" customers.  A customer is considered routes inside your network as "big"
      small as necessary.  A totally flat customer if it has a very complex
   network infrastructure and/or huge IPv6 address needs (e.g. because
   of very large customer numbers) and/or several uplinks addressing
      architecture without any intermediate aggregation level will lead
      to different
   POPs lots of customer routes inside the SP network.

   The assigned IPv6 address prefixes can have a prefix length in the
   range 32-48 and for each assignment a 100 or 300% future growing zone
   is marked as "reserved" for this customer.  This means for instance
   that with a delegation of a /34 to a customer the corresponding /32
   prefix (which contains this /34) is reserved for the customers future
   usage.

   The prefixes for the "big" customers can be chosen from the
   corresponding "big customer" pool by either using an equidistant
   algorithm or using mechanisms similar to  A fair trade-
      off between address aggregation levels (and hence the Sparse Allocation
   Algorithm (SAA) [31].

5.2.2.1.2.  'Common' customers

   All customers that are not "big" customers are considered as "common"
   customers.  They represent size of the majority
      internal routing table of customers hence they
   receive a /48 out the SP) and address conservation of the
      addressing architecture has to be found.
   o  The ISP IPv6 addressing schema should provide maximal flexibility.
      This has to be realized for supporting different sizes of customer
      IPv6 address pool aggregates ("big" customers vs. "small" customers) as
      well as to allow future growing rates (e.g. of the LER where
   they are directly connected customer
      aggregates) and possible topological or aggregated.

   Again a 100 infrastructural changes.
   o  A limited number of aggregation levels and sizes of customer
      aggregates will ease the management of the addressing schema.
      This has to be weighed against the previous "thumb rule" - 300% future growing
      flexibility.

A.2.2.  Exemplary IPv6 address range is reserved for
   each customer, so that a "common" customer receives a /48 allocation
   but has plan for a /47 or /46 reserved. Service Provider

   In this example, the network access scenarios where the customer Service Provider is directly
   connected assumed to operate an MPLS
   based backbone and implements 6PE [29] to provide IPv6 backbone
   transport between the LER the customer prefix is directly taken out different locations (POPs) of a fully dual-
   stacked network access and aggregation area.

   Besides that it is assumed that the Service Provider:
   o  has received a /20 from its RIR
   o  operates its own LIR
   o  has to address its own IPv6 infrastructure
   o  delegates prefixes from this aggregate to its customers

   This addressing schema should illustrate how the
   customer /20 IPv6 address aggregate (e.g. /38) prefix of
   the corresponding LER.

   In all other cases (e.g. the customer is attached SP can be used to a RAR that is
   themselves aggregated address the SP-own infrastructure and to an AG or
   delegate IPv6 prefixes to a LER) at least 2 different
   approaches are its customers following the above mentioned
   requirements and thumb rules as far as possible.

   1) Mapping

   The below figure summarizes the device types in a SP network and the
   typical network design of Aggregation Network Hierarchy into Customer IPv6
   Addressing Schema. a MPLS-based service provider.  The aggregation network
   hierarchy could of the SP has to be mapped taken into account for the design of an
   IPv6 addressing schema and defines its basic shape and the customer prefix pools various
   levels of aggregation.

   +------------------------------------------------------------------+
   |               LSRs of each network level in
   order to achieve a maximal aggregation at the LER level as well as at MPLS Backbone of the intermediate levels.  (Example: Customer - /48, SP                |
   +------------------------------------------------------------------+
      |        |             |              |                 |
      |        |             |              |                 |
   +-----+  +-----+     +--------+     +--------+         +--------+
   | LER |  | LER |     | LER-BB |     | LER-BB |         | LER-BB |
   +-----+  +-----+     +--------+     +--------+         +--------+
    |   |    |   |        |    |      /     |              |     |
    |   |    |   |        |    |     /      |              |     |
    |   |    |   |  +------+  +------+   +------+          |     |
    |   |    |   |  |BB-RAR|  |BB-RAR|   |  AG  |          |     |
    |   |    |   |  +------+  +------+   +------+          |     |
    |   |    |   |    |  |      |  |      |    |           |     |
    |   |    |   |    |  |      |  |      |    |           |     |
    |   |    |   |    |  |      |  | +-----+  +-----+  +-----+  +-----+
    |   |    |   |    |  |      |  | | RAR - /38, AG -
   /32, LER-BB - /30).  At each network level an adequate growing zone
   should be reserved.  (Note: This approach requires of course some
   "fine tuning" of the addressing schema based on a very good knowledge
   of the |  | RAR |  | RAR |  | RAR |
    |   |    |   |    |  |      |  | +-----+  +-----+  +-----+  +-----+
    |   |    |   |    |  |      |  |  |   |    |   |    |   |    |   |
    |   |    |   |    |  |      |  |  |   |    |   |    |   |    |   |
   +-------------------------------------------------------------------+
   |                       Customer networks                           |
   +-------------------------------------------------------------------+
   Figure: Exemplary Service Provider network topology including actual growing
   ranges and rates.)

   When the IPv6 customer address pool of a LER (or another device of
   the aggregation network - AG or RAR) is exhausted, the related Network

   LSR    ... Label Switch Router
   LER
   (or    ... Label Edge Router
   LER-BB ... Broadband Label Edge Router
   RAR    ... Remote Access Router
   BB-RAR ... Broadband Remote Access Router
   AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to
   /37 or /36) so that the originally reserved growing zone can be used
   for further IPv6 address allocations to customers.  In the case where
   this growing zone is exhausted as well a new prefix range from the
   corresponding pool of the next higher hierarchy level can be
   requested.

   2) "Flat" Customer     ... Aggregation Router

   Basic design decisions for the exemplary Service Provider IPv6 Addressing Schema.
   address plan regarding customer prefixes take into consideration:
   o  The other option is prefixes assigned to
   allocate all customers behind the customer prefixes directly out of the customer IPv6
   address pool of the same LER where the customers (e.g.
      LER or LER-BB) are attached and aggregated and to ignore the intermediate aggregation network
   infrastructure.  This approach leads of course to a higher amount of
   customer routes at LER and aggregation network level but takes a
   great amount of complexity out of the addressing schema.
   Nevertheless the aggregation of the customer prefixes to under one prefix
   at LER level is realized as required above.

   (Note: The handling of (e.g. technically triggered) changes within
   the ISP access network is shortly discussed in section 5.2.3.5.)
   If the actual observed growing rates show that the reserved growing
   zones are not needed than these growing areas can be freed and used
   for assignments for prefix pools to other devices at the same level
   of the network hierarchy.

5.2.2.2.  Defining an IPv6 address allocation plan for the Service
          Provider Network Infrastructure

   For the IPv6 addressing of SPs own network infrastructure a /32 (or
   /40) from the "big" customers address pool can be chosen. prefix.  This SP infrastructure prefix is used to code ensures
      that the network
   infrastructure number of the SP by assigning a /48 to every POP/location and
   using for instance a /56 for coding the corresponding router within
   this POP.  Each SP internal link behind a router interface could be
   coded using a /64 prefix.  (Note: While it is suggested labels that have to choose a
   /48 be used for addressing the POP/location 6PE is limited
      and hence provides a strong MPLS label conservation.
   o  The /20 prefix of the SP network it is left separated into 3 different pools that
      are used to
   each SP allocate IPv6 prefixes to decide what prefix length the customers of the SP:
      *  A pool (e.g. /24) for satisfying the addressing needs of really
         "big" customers (as defined in A.2.2.1 sub-section A.) that
         need IPv6 prefixes larger than /48 (e.g. /32).  These customers
         are assumed to assign be connected to the routers and
   links within this POP.)

   The IIDs several POPs of the router interfaces may access
         network, so that this customer prefix will be generated by using EUI-64 or
   through plain manual configuration e.g. visible in each
         of these POPs.

      *  A pool (e.g. /24) for coding the LERs with direct customer connections
         (e.g. dedicated line access) and without an additional
         aggregation area between the customer and the LER.  (These LERs
         are mostly connected to a limited number of customers because
         of the limited number of interfaces/ports.)
      *  A larger pool (e.g. 14*/24) for LERs (e.g.  LER-BB) that serve
         a high number of customers that are normally connected via some
         kind of aggregation network (e.g.  DSL customers behind a BB-
         RAR or operational information into Dial-In customers behind a RAR).
      *  The IPv6 address delegation within each Pool (end customer
         delegation or also the IID.

   It is assumed aggregates that again 100 are dedicated to the
         LERs itself) should be chosen with an additional buffer zone of
         100% - 300% growing zones for each level of
   network hierarchy and future growth.  I.e. 1 or 2 additional prefix
         bits may should be assigned reserved according to POPs
   and/or routers if needed.

   Loopback interfaces of routers may be chosen from the first /64 expected future growth
         rate of the /56 router prefix (in corresponding customer / the example above).

   (Note: The /32 prefix that has been chosen for addressing SPs own
   IPv6 corresponding network infrastructure gives enough place to code additional
   functionalities like security levels or private and test
   infrastructure although such approaches haven't been considered in
   more detail
         device aggregate.

A.2.2.1.  Defining an IPv6 address allocation plan for the above described SP until now.)

   Point-to-point links to customers (e.g.  PPP links, dedicated line
   etc.) may be addressed using /126 prefixes out of the first /64 of
   the access routers that could be reserved for this reason.

5.2.3.  Additional Remarks

5.2.3.1.  ULA

   From the actual view point of SP there is no compelling reason why
   ULAs should be used
          Service Provider

A.2.2.1.1.  'Big' customers

   SP's "big" customers receive their prefix from a SP.  Look at section 2.2.

   ULAs could be used inside the SP network in order to have an
   additional "site-local scoped" /24 IPv6 address for SPs own
   infrastructure for instance for network management reasons and maybe
   also in order to have an addressing schema
   aggregate that couldn't be reached
   from outside the SP network.

   In the case when ULAs are used it has been reserved for their "big" customers.  A
   customer is possible to map the proposed
   internal IPv6 addressing of SPs own network infrastructure considered as
   described in 5.2.2.2 above directly to the ULA addressing schema by
   substituting the /48 POP prefix with "big" customer if it has a /48 ULA site prefix.

5.2.3.2.  Multicast very complex
   network infrastructure and/or huge IPv6 Multicast-related addressing issues are out of the scope address needs (e.g. because
   of this
   document.

5.2.3.3.  POP Multi-homing

   POP (or better LER) Multi-homing very large customer numbers) and/or several uplinks to different
   POPs of customers with the same SP can be
   realized within the proposed network.

   The assigned IPv6 addressing schema of the SP by
   assigning multiple LER-dependent address prefixes to this customer (i.e.
   considering can have a prefix length in the
   range 32-48 and for each customer location as assignment a single-standing customer) 100 or
   by choosing 300% future growing zone
   is marked as "reserved" for this customer.  This means for instance
   that with a delegation of a /34 to a customer the corresponding /32
   prefix out of (which contains this /34) is reserved for the pool of "big" customers. customers future
   usage.

   The second solution has the disadvantage that in every LER where prefixes for the
   customer is attached this prefix will appear inside "big" customers can be chosen from the IGP routing
   table requiring
   corresponding "big customer" pool by either using an explicit MPLS label.

   (Note: The described negative POP/LER Multi-homing effects equidistant
   algorithm or using mechanisms similar to the
   addressing architecture in the SP access network Sparse Allocation
   Algorithm (SAA) [31].

A.2.2.1.2.  'Common' customers

   All customers that are not tackled by
   implementing "big" customers are considered as "common"
   customers.  They represent the Shim6 Site Multi-homing approach since this approach
   targets only on majority of customers hence they
   receive a mechanism for dealing with multiple prefixes in end
   systems -- /48 out of the SP will nevertheless have unaggregated IPv6 customer
   prefixes in its internal routing tables.)

5.2.3.4.  Changing Point of Network Attachement

   In address pool of the possible case LER where
   they are directly connected or aggregated.

   Again a 100 - 300% future growing IPv6 address range is reserved for
   each customer, so that a "common" customer receives a /48 allocation
   but has to change its point a /47 or /46 reserved.

   (Note: If it is obvious that the likelyhood of
   network attachment to another POP/LER within needing a /47 or /46
   in the ISP access network
   two different approaches can future is very small for a "common" customer, than no growing
   buffer should be applied assuming that reserved for it and only a /48 will be assigned
   without any growing buffer.)

   In the customer
   uses PA addresses out of network access scenarios where the SP aggregate:

   1.)  The customer has is directly
   connected to renumber its network with an adequate the LER the customer prefix is directly taken out of the
   customer IPv6 address aggregate (e.g. /38) of the corresponding LER/RAR LER.

   In all other cases (e.g. the customer is attached to a RAR that is
   themselves aggregated to an AG or to a LER) at least 2 different
   approaches are possible.

   1) Mapping of
   its new Aggregation Network Hierarchy into Customer IPv6
   Addressing Schema.  The aggregation network attachement.  To minimise hierarchy could be mapped
   into the administrative burden
   for design of the customer the prefix pools of each network level in
   order to achieve a maximal aggregation at the LER level as well as at
   the intermediate levels.  (Example: Customer - /48, RAR - /38, AG -
   /32, LER-BB - /30).  At each network level an adequate growing zone
   should be reserved.  (Note: This approach requires of course some
   "fine tuning" of the addressing schema based on a very good knowledge
   of the same size as the former.
   This conserves Service Provider network topology including actual growing
   ranges and rates.)

   When the IPv6 customer address aggregation within pool of a LER (or another device of
   the SP aggregation network
   (and - AG or RAR) is exhausted, the MPLS label space) but adds additional burden related LER
   (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to
   /37 or /36) so that the
   customer.  Hence this approach will most likely only originally reserved growing zone can be chosen in the
   case of 'small customers' with temporary addressing needs and/or
   prefix delegation with address auto-configuration.

   2.)  The customer does not need to renumber its network and keeps its used
   for further IPv6 address aggregate.

   This apporach leads to additional more-specific routing entries
   within the IGP routing table of the LER and will hence consume
   additional MPLS labels - but it is totally transparent allocations to customers.  In the
   customer.  Because case where
   this results in additional administrative effort
   and will stress growing zone is exhausted as well a new prefix range from the router resources (label space, memory)
   corresponding pool of the ISP
   this solution will only next higher hierarchy level can be offered
   requested.

   2) "Flat" Customer IPv6 Addressing Schema.  The other option is to
   allocate all the most valuable customers customer prefixes directly out of
   an ISP (like e.g. "big customers" or "enterprise customers").

   Nevertheless the ISP has again to find a fair trade-off between customer renumbering and sub-optimal IPv6
   address aggregation (i.e. the
   generation pool of additional more-specific routing entries within the IGP
   and LER where the waste of MPLS Label space).

5.2.3.5.  Restructuring of SP (access) network customers are attached and Renumbering

   A technically triggered restructuring of
   aggregated and to ignore the SP (access) intermediate aggregation network (for
   instance because of split of equipment or installation
   infrastructure.  This approach leads of new
   equipment) should not lead course to a higher amount of
   customer network renumbering.  This
   challenge should be handled in advance by an intelligent network
   design routes at LER and IPv6 address planing.

   In the worst case the customer aggregation network renumbering could be avoided
   through level but takes a
   great amount of complexity out of the implementation addressing schema.
   Nevertheless the aggregation of more specific the customer routes. prefixes to one prefix
   at LER level is realized as required above.

   (Note:
   Since this kind The handling of network restructuring will mostly happen (e.g. technically triggered) changes within
   the ISP access network (at the level) below is shortly discussed in section A.2.3.5.)

   If the LER, actual observed growing rates show that the LER aggregation
   level will reserved growing
   zones are not needed than these growing areas can be harmed freed and the more-specific routes will not
   consume additional MPLS label space.)

5.2.3.6.  Extensions needed used
   for assignments for prefix pools to other devices at the later same level
   of the network hierarchy.

A.2.2.2.  Defining an IPv6 migration phases

   The proposed address allocation plan for the Service
          Provider Network Infrastructure

   For the IPv6 addressing schema of SPs own network infrastructure a /32 (or
   /40) from the "big" customers address pool can be chosen.

   This SP infrastructure prefix is used to code the network
   infrastructure of the SP by assigning a /48 to every POP/location and
   using for instance a /56 for coding the corresponding router within
   this POP.  Each SP internal link behind a router interface could be
   coded using a SP needs some slight
   enhancements / modifications /64 prefix.  (Note: While it is suggested to choose a
   /48 for addressing the later phases POP/location of IPv6
   integration, for instance in the case when the whole MPLS backbone
   infrastructure (LDP, IGP etc.) SP network it is realized over IPv6 transport an
   addressing left to
   each SP to decide what prefix length to assign to the routers and
   links within this POP.)

   The IIDs of the LSRs is needed.  Other changes router interfaces may be necessary as
   well but should not be explained at this point.

6.  IANA Considerations

   There are no extra IANA consideration for this document.

7.  Security Considerations

   This IPv6 addressing document does not have any direct impact on
   Internet infrastructure security.

8.  Acknowledgements

   Constructive feedback and contributions have been received from Marla
   Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete,
   Carlos Garcia Braschi, Brian Carpenter, Mark Smith and Ginny Listman.

9.  References

9.1.  Normative References

9.2.  Informative References

   [1]   Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
         Lear, "Address Allocation for Private Internets", BCP 5,
         RFC 1918, February 1996.

   [2]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [3]   Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address
         Allocation", RFC 2471, December 1998.

   [4]   Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
         Addresses", RFC 2526, March 1999.

   [5]   Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-
         Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021,
         December 2000.

   [6]   Narten, T. and R. Draves, "Privacy Extensions generated by using EUI-64 or
   through plain manual configuration e.g. for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [7]   Durand, A., Fasano, P., Guardini, I., coding additional network
   or operational information into the IID.

   It is assumed that again 100 - 300% growing zones for each level of
   network hierarchy and D. Lento, "IPv6
         Tunnel Broker", RFC 3053, January 2001.

   [8]   Carpenter, B. additional prefix bits may be assigned to POPs
   and/or routers if needed.

   Loopback interfaces of routers may be chosen from the first /64 of
   the /56 router prefix (in the example above).

   (Note: The /32 prefix that has been chosen for addressing SPs own
   IPv6 network infrastructure gives enough place to code additional
   functionalities like security levels or private and K. Moore, "Connection test
   infrastructure although such approaches haven't been considered in
   more detail for the above described SP until now.)

   Point-to-point links to customers (e.g.  PPP links, dedicated line
   etc.) may be addressed using /126 prefixes out of the first /64 of
   the access routers that could be reserved for this reason.

A.2.3.  Additional Remarks

A.2.3.1.  ULA

   From the actual view point of SP there is no compelling reason why
   ULAs should be used from a SP.  Look at section 2.2.

   ULAs could be used inside the SP network in order to have an
   additional "site-local scoped" IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [9]   IAB address for SPs own
   infrastructure for instance for network management reasons and IESG, "IAB/IESG Recommendations on maybe
   also in order to have an addressing schema that couldn't be reached
   from outside the SP network.

   In the case when ULAs are used it is possible to map the proposed
   internal IPv6 Address
         Allocations addressing of SPs own network infrastructure as
   described in A.2.2.2 above directly to Sites", RFC 3177, September 2001.

   [10]  Durand, A. and C. Huitema, "The H-Density Ratio for Address
         Assignment Efficiency An Update on the H ratio", RFC 3194,
         November 2001.

   [11]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
         Carney, "Dynamic Host Configuration Protocol for ULA addressing schema by
   substituting the /48 POP prefix with a /48 ULA site prefix.

A.2.3.2.  Multicast

   IPv6
         (DHCPv6)", RFC 3315, July 2003.

   [12]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [13]  Blanchet, M., "A Flexible Method Multicast-related addressing issues are out of the scope of this
   document.

A.2.3.3.  POP Multi-homing

   POP (or better LER) Multi-homing of customers with the same SP can be
   realized within the proposed IPv6 addressing schema of the SP by
   assigning multiple LER-dependent prefixes to this customer (i.e.
   considering each customer location as a single-standing customer) or
   by choosing a customer prefix out of the pool of "big" customers.
   The second solution has the disadvantage that in every LER where the
   customer is attached this prefix will appear inside the IGP routing
   table requiring an explicit MPLS label.

   (Note: The described negative POP/LER Multi-homing effects to the
   addressing architecture in the SP access network are not tackled by
   implementing the Shim6 Site Multi-homing approach since this approach
   targets only on a mechanism for Managing dealing with multiple prefixes in end
   systems -- the SP will nevertheless have unaggregated customer
   prefixes in its internal routing tables.)

A.2.3.4.  Changing Point of Network Attachement

   In the Assignment possible case that a customer has to change its point of
         Bits
   network attachment to another POP/LER within the ISP access network
   two different approaches can be applied assuming that the customer
   uses PA addresses out of the SP aggregate:

   1.)  The customer has to renumber its network with an IPv6 Address Block", RFC 3531, April 2003.

   [14]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast
         Address Format", RFC 3587, August 2003.

   [15]  Savola, P., "Use adequate
   customer prefix out of /127 Prefix Length Between Routers
         Considered Harmful", RFC 3627, September 2003.

   [16]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633,
         December 2003.

   [17]  Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
         Allocation) Phaseout", RFC 3701, March 2004.

   [18]  Droms, R., "Stateless Dynamic Host Configuration Protocol
         (DHCP) Service the aggregate of the corresponding LER/RAR of
   its new network attachement.  To minimise the administrative burden
   for IPv6", RFC 3736, April 2004.

   [19]  Huitema, C. and B. Carpenter, "Deprecating Site Local
         Addresses", RFC 3879, September 2004.

   [20]  Savola, P. the customer the prefix should be of the same size as the former.
   This conserves the IPv6 address aggregation within the SP network
   (and the MPLS label space) but adds additional burden to the
   customer.  Hence this approach will most likely only be chosen in the
   case of "small customers" with temporary addressing needs and/or
   prefix delegation with address auto-configuration.

   2.)  The customer does not need to renumber its network and B. Haberman, "Embedding keeps its
   address aggregate.

   This apporach leads to additional more-specific routing entries
   within the Rendezvous Point
         (RP) Address in an IPv6 Multicast Address", RFC 3956,
         November 2004.

   [21]  Arkko, J., Kempf, J., Zill, B., IGP routing table of the LER and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [22]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, March 2005.

   [23]  Baker, F., Lear, E., will hence consume
   additional MPLS labels - but it is totally transparent to the
   customer.  Because this results in additional administrative effort
   and R. Droms, "Procedures for Renumbering will stress the router resources (label space, memory) of the ISP
   this solution will only be offered to the most valuable customers of
   an IPv6 Network without ISP (like e.g. "big customers" or "enterprise customers").

   Nevertheless the ISP has again to find a Flag Day", RFC 4192, September 2005.

   [24]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", RFC 4193, October 2005.

   [25]  Templin, F., Gleeson, T., Talwar, M., fair trade-off between
   customer renumbering and D. Thaler, "Intra-
         Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
         October 2005.

   [26]  Hinden, R. sub-optimal address aggregation (i.e. the
   generation of additional more-specific routing entries within the IGP
   and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

   [27]  Chown, T., Venaas, S., the waste of MPLS Label space).

A.2.3.5.  Restructuring of SP (access) network and C. Strauf, "Dynamic Host
         Configuration Protocol (DHCP): IPv4 Renumbering

   A technically triggered restructuring of the SP (access) network (for
   instance because of split of equipment or installation of new
   equipment) should not lead to a customer network renumbering.  This
   challenge should be handled in advance by an intelligent network
   design and IPv6 Dual-Stack
         Issues", RFC 4477, May 2006.

   [28]  ARIN, "http://www.arin.net/policy/nrpm.html#six54".

   [29]  De Clerq, J., Ooms, D., Prevost, S., address planing.

   In the worst case the customer network renumbering could be avoided
   through the implementation of more specific customer routes.  (Note:
   Since this kind of network restructuring will mostly happen within
   the access network (at the level) below the LER, the LER aggregation
   level will not be harmed and F. Le Faucheur,
         "Connecting IPv6 Islands over IPv4 the more-specific routes will not
   consume additional MPLS using label space.)

A.2.3.6.  Extensions needed for the later IPv6 Provider
         Edge Routers (6PE) (draft-ooms-v6ops-bgp-tunnel-06.txt)",
         June 2006.

   [30]  Chown, T., "IPv6 Implications migration phases

   The proposed IPv6 addressing schema for TCP/UDP Port Scanning
         (draft-ietf-v6ops-scanning-implications-00.txt)", June 2006.

   [31]  APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment
         Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003.

   [32]  Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to
         think about a SP needs some slight
   enhancements / modifications for the later phases of IPv6
   integration, for instance in the case when Renumbering the whole MPLS backbone
   infrastructure (LDP, IGP etc.) is realized over IPv6 transport and an
   IPv6 network
         (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007.

   [33]  "List addressing of Internet-Drafts relevant to the Multi6-WG
         (http://ops.ietf.org/multi6/draft-list.html )".

   [34]  Lear, E., "Things MULTI6 Developers LSRs is needed.  Other changes may be
   necessary as well but should think about
         (draft-ietf-multi6-things-to-think-about-01)", January 2005.

   [35]  Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
         solutions (draft-ietf-multi6-multihoming-threats-03)",
         January 2005. not be explained at this point.

Authors' Addresses

   Gunter Van de Velde
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Phone: +32 2704 5473
   Email: gunter@cisco.com

   Ciprian Popoviciu
   Cisco Systems
   7025-6 Kit Creek Road
   Research Triangle Park, North Carolina  PO Box 14987
   USA

   Phone: +1 919 392-3723
   Email: cpopovic@cisco.com

   Tim Chown
   University of Southampton
   Highfield
   Southampton,   SO17 1BJ
   United Kingdom

   Phone: +44 23 8059 3257
   Email: tjc@ecs.soton.ac.uk

   Olaf Bonness
   T-Systems Enterprise Services GmbH
   Goslarer Ufer 35
   Berlin,   10589
   Germany

   Phone: +49 30 3497 3124
   Email: Olaf.Bonness@t-systems.com
   Christian Hahn
   T-Systems Enterprise Services GmbH
   Goslarer Ufer 35
   Berlin,   10589
   Germany

   Phone: +49 30 3497 3164
   Email: HahnC@t-systems.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).