IPv6 Operations
Network Working Group                                    G. Van de Velde
Internet-Draft
Request for Comments: 5375                                  C. Popoviciu
Intended status:
Category: Informational                                    Cisco Systems
Expires: March 26, 2009
                                                                T. Chown
                                               University of Southampton
                                                              O. Bonness
                                                                 C. Hahn
                                      T-Systems Enterprise Services GmbH
                                                      September 22,
                                                           December 2008

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

Status of this This Memo

   By submitting this Internet-Draft, each author represents that

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any
   applicable patent or other IPR claims kind.  Distribution of which he or she this
   memo is aware
   have been or will be disclosed, unlimited.

Copyright Notice

   Copyright (c) 2008 IETF Trust 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 persons identified 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 the
   document authors.  All rights reserved.

   This document is inappropriate subject to use Internet-Drafts as reference
   material or BCP 78 and the IETF Trust's Legal
   Provisions Relating to cite them other than as "work IETF Documents (http://trustee.ietf.org/
   license-info) in progress."

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

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

   This Internet-Draft will expire on March 26, 2009. this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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  3
   2.  Network Level  Network-Level Addressing Design Considerations . . . . . . . .  5  4
     2.1.  Globally Unique Addresses  . . . . . . . . . . . . . . . .  5  4
     2.2.  Unique Local IPv6 Addresses  . . . . . . . . . . . . . . .  5
     2.3.  6Bone  6bone Address Space  . . . . . . . . . . . . . . . . . . .  7  6
     2.4.  Network Level  Network-Level Design Considerations  . . . . . . . . . . .  7  6
       2.4.1.  Sizing the Network Allocation  . . . . . . . . . . . .  8
       2.4.2.  Address Space Conservation . . . . . . . . . . . . . .  9  8
   3.  Subnet Prefix Considerations . . . . . . . . . . . . . . . . .  9  8
     3.1.  Considerations for /64 Prefixes  . . . . . . . . . . . . . 10
     3.2.
   4.  Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
       3.2.1.
     4.1.  Automatic EUI-64 Format Option . . . . . . . . . . . . 11
       3.2.2. . . 10
     4.2.  Using Privacy Extensions . . . . . . . . . . . . . . . 11
       3.2.3. . . 10
     4.3.  Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
     3.3.  IANA
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     3.4.  Security Considerations 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . 12
     3.5.  Acknowledgements . . . . . . 11
   7.  Informative References . . . . . . . . . . . . . . . 12
   4.  References . . . . . 12
   Appendix A.  Case Studies  . . . . . . . . . . . . . . . . . . . . 16
     A.1.  Enterprise Considerations  . 12
     4.1.  Normative References . . . . . . . . . . . . . . . 16
       A.1.1.  Obtaining General IPv6 Network Prefixes  . . . . 12
     4.2.  Informative References . . . 16
       A.1.2.  Forming an Address (Subnet) Allocation Plan  . . . . . 17
       A.1.3.  Other Considerations . . . . . . . . . . 12
   Appendix A.  Case Studies . . . . . . . 18
       A.1.4.  Node Configuration Considerations  . . . . . . . . . . 18
     A.2.  Service Provider Considerations  . . . 15
     A.1.  Enterprise Considerations . . . . . . . . . . 19
       A.2.1.  Investigation of Objective Requirements for an
               IPv6 Addressing Schema of a Service Provider . . . . . . 15
       A.1.1.  Obtaining General IPv6 Network Prefixes  . . . . . . . 16
       A.1.2.  Forming an Address (subnet) Allocation Plan  . . . . . 16
       A.1.3.  Other Considerations . . . . . . . . . . . . . . . . . 17
       A.1.4.  Node Configuration Considerations  . . . . . . . . . . 18
     A.2.  Service Provider Considerations  . . . . . . . . . . . . . 18
       A.2.1.  Investigation of objective Requirements for an
               IPv6  addressing schema of a Service Provider  . . . . 19
       A.2.2.  Exemplary IPv6 Address Allocation Plan for a
               Service Provider . . . . . . . . . . . . . . . . . . . 22 23
       A.2.3.  Additional Remarks . . . . . . . . . . . . . . . . . . 26 28
   Appendix B.  Considerations for Subnet Prefixes Different then than
                /64 . . . . . . . . . . . . . . . . . . . . . . . . . 29 30
     B.1.  Considerations for Subnet Prefixes Shorter then than /64  . . . 29 30
     B.2.  Considerations for Subnet Prefixes Longer then than /64 . . . . 29 31
       B.2.1.  /126 Addresses . . . . . . . . . . . . . . . . . . . . 29 31
       B.2.2.  /127 Addresses . . . . . . . . . . . . . . . . . . . . 29 31
       B.2.3.  /128 Addresses . . . . . . . . . . . . . . . . . . . . 29 31
       B.2.4.  EUI-64 'u' and 'g' bits Bits  . . . . . . . . . . . . . . . 30 31
       B.2.5.  Anycast Addresses  . . . . . . . . . . . . . . . . . . 31 32
       B.2.6.  Addresses Used by Embedded-RP (RFC3956) (RFC 3956) . . . . . . . 32 33
       B.2.7.  ISATAP Addresses . . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 35 34

1.  Introduction

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

   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 addresses -- namely,
   'Network-Level Addressing' (the allocation of subnets) and the
   'interface-id' (the identification of the interface within a subnet).  Thus
   Thus, the document includes a discussion of aspects of address
   assignment to nodes and interfaces in an IPv6 network.  Finally  Finally, the
   document provides two examples of deployed address addressing 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 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 conservation.

   o  The implications of the vastly increased subnet size has implications on the threat of
      address-based host scanning and other scanning techniques, as
      discussed in [RFC5157].

   We do not discuss here how a site or ISP should proceed with
   acquiring its globally routable IPv6 address prefix.  In each case case,
   the prefix received is either provider assigned (PA) or provider
   independent (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 time, we assume that
   most commonly
   when an IPv6 network which changes provider provider, typically it will need to
   undergo a renumbering process, as described in [RFC4192].  A separate
   document [THINKABOUT] makes recommendations to ease the IPv6
   renumbering process.

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

2.  Network Level  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 Globally Unique Addresses and ULAs.  We also comment
   here on the deprecated 6bone address space.

2.1.  Globally Unique Addresses

   The most commonly used unicast addresses will be Globally 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
   service-provider-assigned IPv6 address ranges.  Here, the network
   Administrator
   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.
   (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 RFC 3484 [RFC3484].  A
   multihomed host may thus have two or more addresses, one per prefix
   (provider), and select source and destination addresses to use as
   described in that RFC.  However  However, multihoming also has some
   operational and administrative burdens besides chosing choosing multiple
   addresses per interface [RFC4219][RFC4218]. [RFC4218] [RFC4219].

2.2.  Unique Local IPv6 Addresses

   ULAs have replaced the originally conceived Site Local site-local addresses in
   the IPv6 addressing architecture, for reasons described in [RFC3879].
   ULAs improve on site locals site-locals by offering a high probability of the
   global uniqueness of the prefix used, which can be beneficial in the
   case of when
   there is (deliberate or accidental) leakage, leakage or where when networks are
   merged.  ULAs are akin to the private address space [RFC1918]
   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  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. i.e., a /48,
   the same as the currently recommended allocation for a site from the
   globally routable IPv6 address space [RFC3177].

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

   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 global addresses.  In an
   isolated network network, ULAs may be deployed on their own.  In a connected
   network,
   network that also deploys global addresses, both may be deployed,
   such that hosts become multiaddressed multi-addressed (one global and one ULA
   address) ULA), and
   the IPv6 default address selection algorithm will pick the
   appropriate source and destination addresses to use, e.g. e.g., ULAs will
   be selected where both the source and destination hosts have ULA
   addresses. ULAs.
   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 routable, so Reverse Path Forwarding
   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 principle, ULAs allow easier network mergers than RFC1918 RFC 1918
   addresses do for IPv4 because ULA prefixes have a high probability of
   uniqueness, if the prefix is chosen as described in the RFC.

2.3.  6Bone  6bone Address Space

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

2.4.  Network Level  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 addressing 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 numbers into IPv6 subnet id IDs

      *  translate the VLAN id IDs into IPv6 subnet id IDs

   o  Redesign

      *  allocate according to your need

   o  Aggregation

      *  Geographical Boundaries - by assigning a common prefix to all
         subnets within a geographical area area.

      *  Organizational Boundaries - by assigning a common prefix to an
         entire organization or group within a corporate infrastructure infrastructure.

      *  Service Type - by reserving certain prefixes for predefined
         services such as: VoIP, Content Distribution, content distribution, wireless
         services, Internet Access, Security areas access, 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 not need to consider
   using private address space for its infrastructure devices, thereby
   simplifying network management.

   The network designer must however keep in mind several factors when
   developing these new addressing schemes for networks with and without
   global connectivity:

   o  Prefix Aggregation 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 process.

   o  Network growth - The allocation mechanism for flexible growth of a
      network prefix, documented in RFC3531 RFC 3531 [RFC3531] 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) growth).

   o  ULA usage in large networks - Networks which that have a large number of
      'sites' that each deploy a ULA prefix which that will by default be a
      'random' /48 under fc00::/7 will have no aggregation of those
      prefixes.  Thus  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 from using a
      single ULA prefix for all 'sites', as a ULA still provides 16 bits
      for subnetting to be used internally internally.

   o  Compact numbering of small sites - It is possible that as registry
      policies evolve, a small site may experience an increase in prefix
      length when renumbering, e.g. e.g., from /48 to /56.  For this reason,
      the best practice is to 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.

   o  Consider assigning more than one /64 to a site - A small site may
      want to enable routing amongst interfaces connected to a gateway
      device.  For example, a residential gateway
      which that receives a /48, /48
      and is situated in a home with multiple LANs of different media
      types (sensor network, wired, wifi, Wi-Fi, etc.), or has a need for
      traffic segmentation (home, work, kids, etc.) and etc.), could benefit
      greatly from multiple subnets and routing in IPv6.  Ideally,
      residential networks would be given an address range of a /48 or
      /56 [reference2] [RIPE_Nov07] such that multiple /64 subnets could be used
      within the residence.

2.4.1.  Sizing the Network Allocation

   We do not discuss here how a network designer sizes their application
   for address space.  By default default, a site will receive a /48 prefix
   [RFC3177] , however
   [RFC3177]; 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 [ARIN]. (see
   Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]).  The default
   provider allocation via the RIRs is currently a /32
   [reference2]. [RIPE_Nov07].
   These allocations are indicators for a first allocation for a
   network.  Different sizes may be obtained based on the anticipated
   address usage [reference2].  There [RIPE_Nov07].  At the time of writing, there are
   examples of allocations as large as /19 having been made from RIRs to providers
   at the time of writing.
   providers.

2.4.2.  Address Space Conservation

   Despite the large IPv6 address space 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
   IPv6, but they should still be observed.

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

3.  Subnet Prefix Considerations

   An important part of an IPv4 addressing plan is deciding the length
   of each subnet prefix.  Unlike in IPv4, the IPv6 addressing
   architecture [RFC4291] specifies that all subnets using Globally
   Unique Addresses and ULAs always have the same prefix length of 64
   bits.  (This applies also applies to the deprecated 6Bone 6bone and Site Local site-local
   addresses.)
   The only exception to this rule are special addresses starting with
   the binary value 000, such as IPv4-Compatible IPv4-compatible IPv6 Addresses. addresses.  These
   exceptions are largely beyond the scope of this document.

   Using a subnet prefix length other than a /64 will break many
   features of IPv6, amongst other things including Neighbor Discovery (ND), Secure Neighborship Neighbor
   Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of
   Mobile IPv6 [RFC4866], PIM-SM Protocol Independent Multicast - Sparse Mode
   (PIM-SM) with Embedded-RP [RFC3956], and SHIM6 [SHIM6]. Site Multihoming by IPv6
   Intermediation (SHIM6) [SHIM6], among others.  A number of other
   features currently in development, or being proposed, also rely on
   /64 subnet prefixes.

   Nevertheless, many IPv6 implementations do not prevent the
   administrator from configuring a subnet prefix length shorter or
   longer than 64 bits.  Using subnet prefixes shorter than /64 would
   rarely be useful; see Appendix B.1 for discussion.

   However, some network administrators have used prefixes longer than
   /64 for links connecting routers, usually just two routers on a
   point-to-point link.  On links where all the addresses are assigned
   by manual configuration, and all nodes on the link are routers (not
   end hosts) that are known by the network network, administrators do not need
   any of the IPv6 features that rely on /64 subnet prefixes, this can
   work.  Using subnet prefixes longer than /64 are is not recommended for
   general use, and using them for links containing end hosts would be
   an especially bad idea, as it is difficult to predict what IPv6
   features the hosts will use in the future.

   Appendix B.2 describes some practical considerations that need to be
   taken into account when using prefixes longer than /64 in limited
   cases.  In particular, a number of IPv6 features use interface
   identifiers that have a special form (such as a certain fixed value
   in some bit positions).  When using prefixes longer than /64, it is
   prudent to avoid certain subnet prefix values so that nodes who
   assume that the prefix is /64 will not incorrectly identify the
   addresses in that subnet as having a special form.  Appendix B.2
   describes the subnet prefix values that are currently believed to be
   potentially problematic; however, the list is not exhaustive and can
   be expected to grow in the future.

   Using /64 subnets is strongly recommended, also for links connecting
   only routers.  A deployment compliant with the current IPv6
   specifications cannot use other prefix lengths.  However, the V6OPS
   WG believes that despite the drawbacks (and a potentially expensive
   network redesign, if IPv6 features relying on /64 subnets are needed
   in the future), that some networks administrators will use prefixes longer
   than /64.

3.1.  Considerations for /64 Prefixes

   Based on RFC3177 RFC 3177 [RFC3177], 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 Dynamic
   Host Configuration Protocol [RFC3315] [RFC3736] or [RFC3315], by stateless autoconfiguration [RFC4862].
   [RFC4862], or by a combination thereof [RFC3736].

   Note that RFC3177 RFC 3177 strongly prescribes 64 bit 64-bit subnets for general
   usage, and that stateless autoconfiguration option on most link layers
   (including Ethernet) is only defined for 64 bit 64-bit subnets.  While in
   theory it might be possible that some future autoconfiguration
   mechanisms would allow longer than 64 bit 64-bit prefix lengths to be used,
   the use of such prefixes is not recommended at this time.

3.2.

4.  Allocation of the IID of an IPv6 Address

   In order to have a complete IPv6 address, an interface must be
   associated with 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 [RFC4862] based addresses.
   For the manual or dynamic options, the overlap with well known well-known IPv6
   addresses should be avoided.

3.2.1.

4.1.  Automatic EUI-64 Format Option

   When using this method method, the network administrator has to allocate a
   valid 64 bit 64-bit subnet prefix.  The  Once that allocation has been made, the
   EUI-64 [RFC4862] 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 into the EUI-64 methodology.

3.2.2.

4.2.  Using Privacy Extensions

   The main purpose of IIDs generated based on RFC4941 RFC 4941 [RFC4941] is to
   provide privacy to the entity using this an IPv6 address.  While there are
   no particular constraints in the usage of these IPv6 addresses with IIDs as
   defined in
   [RFC4941] [RFC4941], there are some implications to be aware of when
   using privacy addresses as documented in section Section 4 of RFC4941 RFC 4941
   [RFC4941]

3.2.3.

4.3.  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. (e.g., manual configuration, DHCPv6, etc).

   In this situation situation, the actual allocation is done by human intervention
   intervention, and consideration needs to be given to the complete
   IPv6 address so that it does not result in overlaps with any of the well known
   well-known IPv6 addresses:

   o  Subnet Router Anycast Address (Appendix B.2.5.1.) B.2.5.1)

   o  Reserved Subnet Anycast Address (Appendix B.2.5.2.) B.2.5.2)

   o  Addresses used by Embedded-RP (Appendix B.2.6.) B.2.6)

   o  ISATAP  Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses
      (Appendix B.2.7.) B.2.7)

   When using an address assigned by human intervention intervention, it is
   recommended to choose IPv6 addresses which that are not obvious to guess
   and/or to 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.

3.3.  IANA Considerations

   There are no extra IANA consideration for this document.

3.4.

5.  Security Considerations

   This document doesn't add any new security considerations that aren't
   already outlined in the security considerations of the references.

   It must be noted that using subnet prefixes other than /64 breaks
   security mechanisms such as Cryptographically Generated Addresses
   (CGAs) and Hash Based Hash-Based Addresses (HBAs), and thus makes it impossible
   to use protocols that depend on them.

3.5.

6.  Acknowledgements

   Constructive feedback and contributions have been received during
   IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola,
   John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian
   Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny
   Listman, Salman Assadullah, Krishnan Thirukonda Thirukonda, and the IESG.

4.  References

4.1.  Normative References

4.2.

7.  Informative References

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

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

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

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

   [RFC3056]       Carpenter, B. and K. Moore, "Connection of IPv6
                   Domains via IPv4 Clouds", RFC 3056, February 2001.

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

   [RFC3180]       Meyer, D. and P. Lothberg, "GLOP Addressing in
                   233/8", BCP 53, RFC 3180, September 2001.

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

   [RFC3315]       Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                   C., and M. Carney, "Dynamic Host Configuration
                   Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

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

   [RFC3531]       Blanchet, M., "A Flexible Method for Managing the
                   Assignment of Bits of an IPv6 Address Block",
                   RFC 3531, April 2003.

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

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

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

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

   [RFC3736]       Droms, R., "Stateless Dynamic Host Configuration
                   Protocol (DHCP) Service for IPv6", RFC 3736,
                   April 2004.

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

   [RFC3956]       Savola, P. and B. Haberman, "Embedding the Rendezvous
                   Point (RP) Address in an IPv6 Multicast Address",
                   RFC 3956, November 2004.

   [RFC3971]       Arkko, J., Kempf, J., Zill, B., and P. Nikander,
                   "SEcure Neighbor Discovery (SEND)", RFC 3971,
                   March 2005.

   [RFC4192]       Baker, F., Lear, E., and R. Droms, "Procedures for
                   Renumbering an IPv6 Network without a Flag Day",
                   RFC 4192, September 2005.

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

   [RFC4218]       Nordmark, E. and T. Li, "Threats Relating to IPv6
                   Multihoming Solutions", RFC 4218, October 2005.

   [RFC4219]       Lear, E., "Things Multihoming in IPv6 (MULTI6)
                   Developers Should Think About", RFC 4219,
                   October 2005.

   [RFC4271]       Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
                   Protocol 4 (BGP-4)", RFC 4271, January 2006.

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

   [RFC4477]       Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
                   Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Dual-
                   Stack Issues", RFC 4477, May 2006.

   [RFC4798]       De Clercq, J., Ooms, D., Prevost, S., and F. Le
                   Faucheur, "Connecting IPv6 Islands over IPv4 MPLS
                   Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
                   February 2007.

   [RFC4862]       Thomson, S., Narten, T., and T. Jinmei, "IPv6
                   Stateless Address Autoconfiguration", RFC 4862,
                   September 2007.

   [RFC4866]       Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
                   Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4941]       Narten, T., Draves, R., and S. Krishnan, "Privacy
                   Extensions for Stateless Address Autoconfiguration in
                   IPv6", RFC 4941, September 2007.

   [RFC5214]       Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
                   Automatic Tunnel Addressing Protocol (ISATAP)",
                   RFC 5214, March 2008.

   [RFC5157]       Chown, T., "IPv6 Implications for Network Scanning",
                   RFC 5157, March 2008.

   [SHIM6]         IETF,
              "http://www.ietf.org/html.charters/shim6-charter.html". "Site Multihoming by IPv6 Intermediation
                   (shim6) Charter", <http://www.ietf.org/html.charters/
                   shim6-charter.html>.

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

   [reference2] "ARIN Number Resource Policy Manual",
                   Version 2008.4, September 2008,
                   <http://www.arin.net/policy/nrpm.html>.

   [RIPE_Nov07]    APNIC, ARIN, RIPE NCC, "www.ripe.net/ripe/docs/
              ipv6policy.html", July 2007.

   [reference3] "IPv6 Address Allocation and
                   Assignment Policy", ripe-421, November 2007,
                   <http://www.ripe.net/ripe/docs/ipv6policy.html>.

   [RIPE_Jul07]    APNIC, ARIN, RIPE NCC,
              "http://www.ripe.net/ripe/docs/ripe-412.html", "IPv6 Address Allocation and
                   Assignment Policy", ripe-412, July 2007.

   [reference4]
              ARIN, "http://www.arin.net/policy/nrpm.html#ipv6",
              March 2008.

   [reference5] 2007,
                   <http://www.ripe.net/ripe/docs/ripe-412.html>.

   [APNIC_IPv6]    APNIC,
              "http://www.apnic.net/policy/ipv6-address-policy.html",
              March 2007.

   [reference6]
              LACNIC, "http://lacnic.net/en/politicas/ipv6.html".

   [reference7]
              AFRINIC, "http://www.afrinic.net/docs/policies/
              afpol-v6200407-000.htm", March 2004. "IPv6 Address Allocation and Assignment
                   Policy", APNIC-089, August 2008, <http://
                   www.apnic.net/policy/ipv6-address-policy.html>.

   [LACNIC_IPv6]   LACNIC, "Internet Resource Management Policies in
                   Latin America and the Caribbean: IPv6 Address
                   Allocation and Assignment Policy",
                   <http://lacnic.net/en/politicas/ipv6.html>.

   [AFRINIC_IPv6]  AfriNIC, "AfriNIC IPv6 Address Allocation and
                   Assignment Policy", March 2004,
                   <http://www.afrinic.net/docs/policies/
                   afpol-v6200407-000.htm>.

   [THINKABOUT]    Chown, T., Thompson, M., Ford, A., and S. Venaas,
                   "Things to think about when Renumbering an IPv6 network
              (draft-chown-v6ops-renumber-thinkabout-05.txt)",
                   network", Work in Progress, March 2007.

Appendix A.  Case Studies

   This appendix contains two case studies for IPv6 addressing schemas
   that have been based on the statements and considerations of this
   draft.
   document.  These case studies illustrate how this draft document has been
   used in two specific network scenarios.  The case studies may serve
   as basic considerations for an administrator who designs the IPv6
   addressing schema for an enterprise or ISP network, but are not
   intended to serve as a general design proposal for every kind of IPv6
   network.  All subnet sizes used in this appendix are for practical
   visualization and do not dictate RIR policy.

A.1.  Enterprise Considerations

   In this section section, one considers a case study of a campus network that
   is deploying 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 and over 1,500
   users.

A.1.1.  Obtaining General IPv6 Network Prefixes

   In the case of a campus network, the site will typically take its
   connectivity from its National Research and Education Network (NREN).
   Southampton connects to JANET, the UK academic network, via its local
   regional network LeNSE. LeNSE (Learning Network South East).  JANET
   currently has a /32 allocation from RIPE NCC.  The current
   recommended practice is for sites to receive a /48 allocation, and allocation; on
   this basis basis, Southampton has received such a prefix for its own use.
   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, 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
   [RFC4192] on two occasions, and this has proven adequate (with
   provisos documented in [THINKABOUT]. [THINKABOUT]).  The campus do does not see any
   need to deploy ULAs for in in-band or out of band out-of-band network management;
   there are enough IPv6 prefixes available in the site allocation for
   the infrastructure.  In some cases, use of private IP address space
   in IPv4 creates problems, so University of Southampton believe believes that
   the availability of ample global IPv6 address space for
   infrastructure may be a benefit for many sites.

   No 6bone addressing is used on site any more.  Since the 6bone
   phaseout of June 2006 [RFC3701] [RFC3701], most transit ISPs have begun
   filtering attempted use of such prefixes.

   Southampton does participate in global and organization organizational scope IPv6
   multicast networks.  Multicast address allocations are not discussed
   here as they are not in scope for the document.  It is noted that
   IPv6 has advantages for multicast group address allocation.  In IPv4 IPv4,
   a site needs to use techniques like GLOP [RFC3180] to pick a globally
   unique multicast group to use.  This is problematic if the site does
   not use the Border Gateway Protocol (BGP) [RFC4271] and does not have
   an Autonomous System Number (ASN).  In IPv6 IPv6,0 unicast-prefix-based
   IPv6 multicast addresses empower a site to pick a globally unique
   group address based on its unicast own unicast site or link prefix.  Embedded RP
   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 US and UK).

A.1.2.  Forming an Address (subnet) (Subnet) Allocation Plan

   The campus has a /16 prefix for IPv4 use; in principle principle, 256 subnets
   of 256 addresses.  In reality reality, the subnetting is muddier, because of
   concerns of IPv4 address conservation; subnets are sized to the hosts
   within them, e.g. 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 when DHCP is 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 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 and departments in
   the campus.  While address conservation is still important, it is no
   longer an impediment on to network management.  Rather, address (subnet)
   allocation is more about embracing the available address space and
   planning for future expansion.

   In a dual-stack network, it was chosen to deploy our the IP subnets
   congruently for IPv4 and IPv6.  This is because the systems are still
   in the same administrative domains and the same geography.  It is not
   expected to have IPv6-only subnets in production use for a while yet,
   outside the test beds and some early Mobile IPv6 trials.  With
   congruent addressing, our the firewall policies are also aligned for IPv4
   and IPv6 traffic at the site border.

   The subnet allocation plan required a division of the address space
   per school or department.  Here  Here, a /56 was allocated to the school
   level of the university; there are around 30 schools currently.  A
   /56 of IPv6 address space equates to 256 /64 size subnet allocations.
   Further /56 allocations were made for central IT infrastructure, for the
   network infrastructure infrastructure, and the server side systems.

A.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 specific transition methods deployed internally to the
   campus; everything is using the conventional dual-stack approach.
   There is no use of ISATAP [RFC5214] for example.

   For the Mobile IPv6 early trials trials, there is one allocated prefix for
   Home Agent (HA) use.  However  However, there has been no detailed
   consideration yet regarding how Mobile IPv6 usage may grow, and
   whether more or subnets (or even every subnet subnet) will require HA support.

   The university operates a tunnel broker [RFC3053] service on behalf
   of UKERNA the United Kingdom Education and Research Network Association
   (UKERNA) for JANET sites.  This uses separate address space from
   JANET, not our the university site allocation.

A.1.4.  Node Configuration Considerations

   Currently

   Currently, stateless autoconfiguration is used on most subnets for
   IPv6 hosts.  There is no DHCPv6 service deployed yet, beyond tests of
   early code releases.  It is planned to deploy DHCPv6 for address
   assignment when robust client and server code is available (at the
   time of writing writing, the potential for this looks good, e.g. e.g., via the ISC
   Internet Systems Consortium (ISC) implementation).  University of
   Southampton is also investigating a common integrated DHCP/DNS
   management platform, even if the servers themselves are not co-located, co-
   located, including integrated DHCPv4 and DHCPv6 server configuration,
   as discussed in [RFC4477].  Currently  Currently, clients with statelessly
   autoconfigured addresses are added to the DNS manually, though
   dynamic DNS is an option.  The network administrators would prefer
   the use of DHCP because they believe it gives them more management
   control.

   Regarding the implications of the larger IPv6 subnet address space on
   scanning attacks [RFC5157], it is noted that all the hosts are dual-
   stack, and thus are potentially exposed over both protocols anyway.
   All addresses or are published in DNS, and hence do the site does not operate a two
   faced
   two-faced DNS.

   There

   Currently, there is internal usage of RFC4941 RFC 4941 privacy addresses
   [RFC4941]
   currently (certain platforms currently ship with it on by default), but network
   administrators may desire to administratively disable this (perhaps via DHCP) to ease
   management complexity.  However, it is desired to determine the
   feasibility of this on all systems, e.g. e.g., for guests on wireless LAN
   or other user-maintained systems.  Network management and monitoring
   should be simpler without RFC4941 RFC 4941 in operation, in terms of
   identifying which physical hosts are using which addresses.  Note
   that RFC4941 RFC 4941 is only an issue for outbound connections, and that
   there is potential to assign privacy addresses via DHCPv6.

   Manually configured server addresses are used to avoid address
   changes based upon change of network adaptor.  With IPv6 you can
   choose to pick
   ::53 for a DNS server, or you can pick 'random' addresses for
   obfuscation, though that's not an issue for publicly advertised
   addresses (dns, mx, web, etc). etc.).

A.2.  Service Provider Considerations

   In this section an IPv6 addressing schema is sketched that could
   serve as an example for an Internet Service Provider.

   Sub-section

   Appendix A.2.1 starts with some thoughts regarding objective
   requirements of such an addressing schema and derives a few general
   rules of thumb that have to be kept in mind when designing an ISP
   IPv6 addressing plan.

   Sub-section

   Appendix A.2.2 illustrates these the findings of Appendix A.2.1 with an
   exemplary IPv6 addressing schema for an MPLS-based ISP offering
   Internet Services services as well as Network Access network access services to several
   millions of customers.

A.2.1.  Investigation of objective Objective Requirements for an IPv6  addressing
        schema Addressing
        Schema of a Service Provider

   The first step of the IPv6 addressing plan design for a Service service
   provider should identify all technical, operational, political political, and
   business requirements that have to be satisfied by the 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 corresponding Service Provider) service provider), it is very
   likely that different addressing schemas will be developed and
   deployed by different ISPs.  Nevertheless  Nevertheless, the addressing schema of
   sub-section
   Appendix A.2.2 is one possible example.

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

   o  Local Internet Registry

   o  Network Access Provider

   o  Internet Service Provider

A.2.1.1.  Recommendations for an IPv6 Addressing Schema from the LIR
          Perspective of the Service Provider

   In their its role as Local Internet Registry (LIR) (LIR), the Service Providers
   have service provider
   has to care about the policy constraints of the RIRs and the
   standards of the IETF regarding IPv6 addressing.  In this context,
   the following basic recommendations have to be considered and should
   be satisfied by the IPv6 address allocation plan of a Service
   Provider: service
   provider:

   o  As recommended in RFC 3177 [RFC3177] and in several RIR policies policies,
      "Common" customers sites (normally private customers) should
      receive a /48 prefix from the aggregate of the Service Provider. service provider.
      (Note: The addressing plan must be flexible enough and take into
      account the possible change of the minimum allocation size for end
      users currently under definition by the RIRs.)

   o  "Big customers" (like big enterprises, governmental agencies agencies,
      etc.) may receive shorter prefixes according to their needs needs, when this
      need could
      their needs can be documented and justified to the RIR.

   o  The IPv6 address allocation schema has to be able to meet the HD-
      ratio that is proposed for IPv6.  This requirement corresponds to
      the demand for an efficient usage of the IPv6 address aggregate by
      the Service Provider. service provider.  (Note: The currently valid IPv6 HD-ratio of
      0.94 means an effective usage rate of about 31% 22% of a /20 prefix of
      the
      Service Provider service provider, on the basis of /48 /56 assignments.)

   o  All assignments to customers have to be documented and stored into
      a database that can also be queried by the RIR.

   o  The LIR has to make available the means for supporting the reverse
      DNS mapping of the customer prefixes.

   o  IPv6 Address Allocation and Assignment Policies can be found at
      RIRs and are similar in many aspects:
      [reference2][reference3][reference4] [reference5][reference6] aspects.  See [RIPE_Nov07],
      [RIPE_Jul07], [APNIC_IPv6], [LACNIC_IPv6], [AFRINIC_IPv6], and
      Section 6 of [ARIN].

A.2.1.2.  IPv6 Addressing Schema Recommendations from the ISP
          Perspective of the Service Provider

   From the ISP perspective perspective, the following basic requirements could can be
   identified:

   o  The IPv6 address allocation schema must be able to realize a
      maximal aggregation of all IPv6 address delegations to customers
      into the address aggregate of the Service Provider. service provider.  Only this
      provider aggregate will be routed and injected into the global
      routing table (DFZ). (DFZ, "Default-Free Zone").  This strong aggregation
      keeps the routing tables of the DFZ small and eases filtering and
      access control very much.

   o  The IPv6 addressing schema of the SP should contain optimal
      flexibility since the infrastructure of the SP will change over
      the
      time with new customers, transport technologies technologies, and business
      cases.  The requirement of optimal flexibility is contrary to the
      recommendation of strong IPv6 address aggregation and efficient
      address usage, but at this point each SP has to decide which of these
      requirements to prioritize.

   o  Keeping  While keeping the multilevel network hierarchy of an ISP in mind,
      note that due to addressing efficiency reasons reasons, not all hierarchy
      levels can and should be mapped into the IPv6 addressing schema of
      an ISP.  Sometimes it is much better to implement a more "flat"
      addressing for the ISP network than to loose lose big chunks of the IPv6
      address aggregate in addressing each level of network hierarchy.
      (Note: In special cases cases, it is even recommendable recommended for really "small"
      ISPs to design and implement a totally flat IPv6 addressing schema
      without any level of hierarchy.)

   o  Besides that a  A decoupling of provider network addressing and customer
      addressing is recommended.  (Note: A strong aggregation
      e.g. (e.g., on
      POP, aggregation router Aggregation Router (AG), or Label Edge Router (LER) level level)
      limits the numbers of customer routes that are visible within the
      ISP network network, but brings also brings down the efficiency of the IPv6
      addressing schema.  That's why each ISP has to decide how many
      internal aggregation levels it wants to deploy.)

A.2.1.3.  IPv6 Addressing Schema Recommendations from the Network Access
          provider
          Provider Perspective of the Service Provider

   As already done for the LIR and the ISP roles of the SP it is also
   necessary to identify requirements that come from its Network Access
   Provider role.  Some of the basic requirements are:

   o  The IPv6 addressing schema of the SP SP, it must be chosen in a way
      that it can handle new requirements that are triggered from
      customer side.  This  For instance, this can be for instance the customer's growing
      needs of the customers
      regarding for IPv6 addresses as well as customer driven customer-driven modifications
      within the access network topology (e.g. (e.g., when the customer moves
      from one point of network attachment (POP) to another).  (See
      section A.2.3.4
      Appendix A.2.3.4, "Changing the Point of Network Attachment".)

   o  For each IPv6 address assignment to customers customers, a "buffer zone"
      should be reserved that allows 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- multiple
      attachments of a single customer to the SP network infrastructure
      (i.e. multi-homed
      (i.e., multihomed network access with the same SP).

   These few requirements are only part of all the requirements a
   Service Provider service
   provider has to investigate and keep in mind during the definition
   phase of its addressing architecture.  Each SP will most likely add
   more constraints to this list.

A.2.1.4.  A Few Rules of Thumb for Designing an IPv6 ISP IPv6 Addressing
          Architecture

   As outcome a result of the above enumeration of requirements regarding an ISP
   IPv6 addressing plan plan, the following design "rules of thumb" 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 practical to design one addressing plan that
      fits for all kinds of ISPs (Small (small / big, Routed routed / MPLS-based,
      access / transit, LIR / No-LIR, No LIR, etc.).

   o  The levels of IPv6 address aggregation within the ISP addressing
      schema should strongly correspond to the implemented network
      structure
      structure, and their number should be minimized because of
      efficiency reasons.  It is assumed that the SPs SP's own
      infrastructure will be addressed in a fairly flat way way, whereas the
      part of the customer addressing architecture should contain
      several levels of aggregation.

   o  Keep the number of IPv6 customer routes inside your network as
      small as necessary. possible.  A totally flat customer 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 the
      internal routing table of 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 aggregates ("big" customers vs. "small" customers) as
      well as to allow future growing growth rates (e.g. (e.g., of customer
      aggregates) and possible topological or 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" - "rule of thumb" --
      flexibility.

A.2.2.  Exemplary IPv6 Address Allocation Plan for a Service Provider

   In this example, the Service Provider service provider is assumed to operate an MPLS MPLS-
   based backbone and implements 6PE to implement IPv6 Provider Edge Routers (6PE)
   [RFC4798] to provide IPv6 backbone transport between the different
   locations (POPs) of a fully dual-
   stacked dual-stacked network access and
   aggregation area.

   Besides that

   In addition, it is assumed that the Service Provider: 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 /20 IPv6 prefix of
   the SP can be used to address the SP-own SP's own infrastructure and to
   delegate IPv6 prefixes to its customers customers, following the above above-
   mentioned requirements and rules of thumb as far as possible.

   The below figure below summarizes the device types in a an SP network and the
   typical network design of a MPLS-based service provider.  The network
   hierarchy of the SP has to be taken into account for the design of an
   IPv6 addressing schema and schema; it defines its the basic shape of the addressing
   schema and the various levels of aggregation.

   +------------------------------------------------------------------+
   |               LSRs of the MPLS Backbone of 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 Label Edge Router
   RAR    ...     Remote Access Router
   BB-RAR ...  Broadband Remote Access Router
   AG     ...      Aggregation Router

   Basic

                    Exemplary Service Provider Network

   The following should be taken into consideration when making the
   basic design decisions for the exemplary Service Provider service provider IPv6
   address
   addressing plan regarding customer prefixes take into consideration: prefixes.

   o  The prefixes assigned to all customers behind the same LER (e.g.
      LER or (or
      LER-BB) are aggregated under one LER prefix.  This ensures that
      the number of labels that have to be used for 6PE is limited and
      hence provides a strong MPLS label conservation.

   o  The /20 prefix of the SP is separated into 3 different pools that
      are used to allocate IPv6 prefixes to the customers of the SP:
      *

      1.  A pool (e.g. (e.g., /24) for satisfying the addressing needs of
          really "big" customers (as defined in A.2.2.1 sub-section A.) Appendix A.2.2.1.1) that
          need IPv6 prefixes larger than /48 (e.g. (e.g., /32).  These
          customers are assumed to be connected to several POPs of the
          access network, so that this customer prefix will be visible
          in each of these POPs.

      *

      2.  A pool (e.g. (e.g., /24) for the LERs with direct customer
          connections
         (e.g. (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.)
      *

      3.  A larger pool (e.g. (e.g., 14*/24) for LERs (e.g.  LER-BB) (or LER-BBs) that serve
          a high number of customers that are normally connected via
          some kind of aggregation network (e.g. (e.g., DSL customers behind a BB-
         RAR
          BB-RAR or Dial-In dial-in customers behind a RAR).
      *

   o  The IPv6 address delegation within each Pool (end pool (the end customer
      delegation or also the aggregates that are dedicated to the
         LERs LER itself)
      should be chosen with an additional buffer zone of
         100% - 300% 100-300% for
      future growth.  I.e.  That is, 1 or 2 additional prefix bits should be
      reserved according to the expected future growth rate of the
      corresponding customer / or the corresponding network device
      aggregate.

A.2.2.1.  Defining an IPv6 Address Allocation Plan for Customers of the
          Service Provider

A.2.2.1.1.  'Big'  "Big" Customers

   The SP's "big" customers receive their prefix from the /24 IPv6
   address aggregate that has been reserved for their "big" customers.
   A customer is considered as a "big" customer if it has a very complex
   network infrastructure and/or huge IPv6 address needs (e.g. (e.g., because
   of very large customer numbers) and/or several uplinks to different
   POPs of 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  For instance, 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 customer's
   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 the Sparse Allocation
   Algorithm (SAA) [reference2]. [RIPE_Nov07].

A.2.2.1.2.  'Common'  "Common" Customers

   All customers that are not "big" customers are considered as "common"
   customers.  They represent the majority of customers customers, hence they
   receive a /48 out of the IPv6 customer address pool of the LER where
   they are directly connected or aggregated.

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

   (Note: If it is obvious that the likelyhood likelihood of needing a /47 or /46
   in the future is very small for a "common" customer, than then no growing
   buffer should be reserved for it it, and only a /48 will be assigned
   without any growing buffer.)

   In the network access scenarios where the customer is directly
   connected to the LER LER, the customer prefix is directly taken out of
   the customer IPv6 address aggregate (e.g. (e.g., /38) of the corresponding
   LER.

   In all

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

   1)  Mapping of Aggregation Network Hierarchy into Customer IPv6
       Addressing Schema.  The aggregation network hierarchy could be
       mapped into the design of the customer 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 level, an adequate growing zone should be reserved.
       (Note: This Of course, this approach requires of course some "fine tuning" of
       the addressing schema based on a very good knowledge of the
       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 LER (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g.
       (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
       well, a new prefix range from the corresponding pool of the next next-
       higher hierarchy level can be requested.

   2)  "Flat" Customer IPv6 Addressing Schema.  The other option is to
       allocate all the customer prefixes directly out of the customer
       IPv6 address pool of the LER where the customers are attached and
       aggregated and to ignore the intermediate aggregation network
       infrastructure.  This  Of course, this approach leads of course to a higher
       amount of customer routes at the LER and aggregation network level
       level, but it takes a great amount of complexity out of the
       addressing schema.
   Nevertheless  Nevertheless, the aggregation of the customer
       prefixes to one prefix at the LER level is realized as required
       above.

   (Note:

   Note: The handling of (e.g. technically triggered) changes (e.g., technically triggered changes)
   within the ISP access network is shortly discussed briefly in section A.2.3.5.)
   Appendix A.2.3.5.

   If the actual observed growing rates show that the reserved growing
   zones are not needed than these growing areas needed, then they can be freed and used for assignments
   for prefix pools to other devices at the same level of the network
   hierarchy.

A.2.2.2.  Defining an IPv6 Address Allocation Plan for the Service
          Provider Network Infrastructure

   For the IPv6 addressing of SPs the SP's own network infrastructure 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 (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 to choose a
   /48 for addressing the POP/location of the SP network network, it is left to
   each SP to decide what prefix length to assign to the routers and
   links within this the POP.)

   The IIDs of the router interfaces may be generated by using EUI-64 or
   through plain manual configuration e.g. configuration, e.g., for coding additional
   network or operational information into the IID.

   It

   Again, it is assumed that again 100 - 300% 100-300% growing zones are needed for each
   level of network hierarchy hierarchy, and 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 (or /40) prefix that has been chosen for addressing
   SPs
   the SP's own IPv6 network infrastructure gives leaves enough place space to code
   additional functionalities like security levels or private and test
   infrastructure
   infrastructure, although such approaches haven't been considered in
   more detail for the above described above-described SP until now.)

   Point-to-point links to customers (e.g. (e.g., PPP links, dedicated line lines,
   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

   There are no compelling reason why
   ULAs should be used from a SP.  Look at section reasons for service providers to use ULAs.
   See Section 2.2.

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

   In the case when

   When ULAs are used used, it is possible to map the proposed internal IPv6
   addressing of SPs the SP's own network infrastructure as (as described in A.2.2.2 above
   Appendix A.2.2.2) directly to the ULA addressing schema by
   substituting the /48 POP prefix with a /48 ULA site prefix.

A.2.3.2.  Multicast

   IPv6 Multicast-related multicast-related addressing issues are out of the scope of this
   document.

A.2.3.3.  POP Multi-homing Multihoming

   POP multihoming (or better LER) Multi-homing better, LER multihoming) 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.
   (i.e., considering each customer location as a single-standing single 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 attached, this prefix will appear inside the IGP routing
   table
   table, thus requiring an explicit MPLS label.

   (Note:

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

A.2.3.4.  Changing the Point of Network Attachement Attachment

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

   1.)

   1)  The customer has to renumber its network with an adequate
       customer prefix out of the aggregate of the corresponding LER/RAR
       of its new network attachement. attachment.  To minimise minimize the administrative
       burden for the customer 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  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.)
       autoconfiguration.

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

       This apporach approach leads to additional more-specific routing entries
       within the IGP routing table of the LER and will hence consume
       additional MPLS labels - labels, but it is totally transparent to the
       customer.  Because this results in additional administrative
       effort and will stress the router resources (label space, memory)
       of the ISP ISP, this solution will only be offered to the most
       valuable customers of an ISP (like e.g. (e.g., "big customers" or
       "enterprise customers").

   Nevertheless

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

A.2.3.5.  Restructuring of SP (access) (Access) Network and Renumbering

   A technically triggered restructuring of the SP (access) network (for
   instance
   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 address planing. planning.

   In the worst case case, the customer network renumbering could be avoided
   through the implementation of more specific 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 the more-specific routes will not
   consume additional MPLS label space.)

A.2.3.6.  Extensions Needed for the Later IPv6 Migration Phases

   The proposed IPv6 addressing schema for a an SP needs some slight
   enhancements / modifications for the later phases of IPv6
   integration, for instance in the case instance, when the whole MPLS backbone
   infrastructure (LDP, IGP IGP, etc.) is realized over IPv6 transport transport, and
   an IPv6 addressing of the LSRs is needed.  Other changes may be
   necessary as well but should not be explained at this point.

Appendix B.  Considerations for Subnet Prefixes Different then than /64

B.1.  Considerations for Subnet Prefixes Shorter then than /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 utilized for the pseudo-
   interface [RFC3056].  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.

   A possible reason for choosing the subnet prefix for an interface
   shorter then than /64 is that it would allow more nodes to be attached to
   that interface compared to a prescribed length of 64 bits.  This
   however  The
   prescribed /64 does include 2 functional bits, the 'g' bit and the
   inverted 'u' (universal/local) bit and these can not be chosen at
   will.  However, a larger address space then a /64 is unnecessary for
   most networks networks, considering that 2^64 2^62 provides plenty of node
   addresses.

   The subnet prefix assignments can be made either by manual configuration, by
   a stateful Host Configuration Protocol [RFC3315], by a stateful
   prefix delegation mechanism [RFC3633] [RFC3633], or implied by stateless
   autoconfiguration from prefix RAs. Router Advertisements (RAs).

B.2.  Considerations for Subnet Prefixes Longer then than /64

   The following subsections describe subnet prefix values that should
   be avoided in deployments, deployments because nodes who assume that the subnet
   prefix is /64 could treat them incorrectly.

B.2.1.  /126 Addresses

   126 bit

   126-bit subnet prefixes are typically used for point-to-point links
   similar to a the IPv4 address conservative 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 beyond those discussed earlier in this
   section, particularly those related to the "u" 'u' and
   "g" bits. 'g' bits (see
   B.2.4.

B.2.2.  /127 Addresses

   The usage of the /127 addresses, the equivalent of IPv4's RFC3021
   [RFC3021] RFC 3021
   [RFC3021], is not valid and should be strongly discouraged as
   documented in RFC3627 RFC 3627 [RFC3627].

B.2.3.  /128 Addresses

   The 128 bit 128-bit address prefix may be used in those situations where we
   know that one, and only one 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" 'u' and
   "g"
   'g' bits into consideration and to make sure that there is no overlap
   with either any of the following well-known addresses:

   o  Subnet Router Anycast Address

   o  Reserved Subnet Anycast Address

   o  Addresses used by Embedded-RP

   o  ISATAP Addresses

B.2.4.  EUI-64 'u' and 'g' bits Bits

   When using subnet prefix lengths other than /64, the interface
   identifier cannot be in Modified EUI-64 format as required by
   [RFC4291].  However, nodes not aware that a prefix length other than
   /64 is used might still think it's an EUI-64; therefore, it's prudent
   to take into account the next considerations to set following points when setting the bits into account. bits.

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

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

   When assigning a subnet prefix of more then 70 bits, according to
   RFC4291 [RFC4291] RFC
   4291 [RFC4291], 'u' and 'g' bits (respectively the (the 71st and 72nd
   bit) bit,
   respectively) need to be taken into consideration and should be set correct.
   correctly.

   The 'u' (universal/local) bit is the 71st bit of a IPv6 address is the inverted 'u' (universal/local)
   bit and is used to determine whether the address is universally or
   locally administered.  If 0, 1, the IEEE, through the designation of a
   unique company ID, has administered the address.  If 1, 0, the address
   is locally administered.  The network administrator has overridden
   the manufactured address and specified a different address.

   The 'g' (the individual/group) bit is the 72st 72nd bit and is used to
   determine whether the address is an individual address (unicast) or a
   group address (multicast).  If '0', the address is a unicast address.
   If '1', the address is a multicast address.

   In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bit
   bits is marginal and typically will not show give an issue error when configured
   wrongly, however
   wrongly; however, future implementations may turn out differently if
   they would be processing process the 'u' and 'g' bit bits in IEEE like IEEE-like behavior.

   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.

B.2.5.  Anycast Addresses

B.2.5.1.  Subnet Router Anycast Address

   RFC4291

   RFC 4291 [RFC4291] 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 device
   which
   that expects to have a normal unicast address.  There is no
   additional dependency for the subnet prefix with the exception of the
   64-bit extended unique identifier (EUI-64) and an Interface
   Identifier (IID) dependency.  These will be discussed later in this
   document.

B.2.5.2.  Reserved IPv6 Subnet Anycast Addresses

   RFC2526

   RFC 2526 [RFC2526] 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 the Modified 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. in order to prevent confusion.

   For other IPv6 address types (that is, with format prefixes other
   than those listed above), the interface identifier is not in 64-bit
   extended unique identifier (EUI-64) format and may not be other than 64 bits in length; these
   length.  The 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  |

   It is recommended to avoid allocating this IPv6 address to a device
   which
   that expects to have a normal unicast address.  There is no
   additional dependency for the subnet prefix with the exception of the
   EUI-64 and an Interface Identifier (IID) dependency.  These will be
   discussed later in this document.

B.2.6.  Addresses Used by Embedded-RP (RFC3956) (RFC 3956)

   Embedded-RP [RFC3956] 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 results 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 low-order bits, while the remainder of
   the Rendezvous Interface ID (RIID) is set to all '0'.  The format of
   the IPv6 multicast group address used by embedded-RP is as follows:

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

                   Where:

                   where: (RIID) = 4 bit. bits.

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

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

B.2.7.  ISATAP Addresses

   ISATAP [RFC5214] 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.  The format is as follows:

                [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]

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

   Note that the definition of ISATAP does not support multicast.

Authors' Addresses

   Gunter Van de Velde
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium
   Phone: +32 2704 5473
   Email:
   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:
   EMail: cpopovic@cisco.com

   Tim Chown
   University of Southampton
   Highfield
   Southampton,
   Southampton  SO17 1BJ
   United Kingdom
   Phone: +44 23 8059 3257
   Email:
   EMail: tjc@ecs.soton.ac.uk

   Olaf Bonness

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

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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.