RFC 5375
IPv6 Unicast Address Assignment Considerations
hiii bestie 🎀 okay so this RFC is literally the addressing plan guide for IPv6, and I'm obsessed. Let's get into it 💅
- RFC number: 5375
- Title: IPv6 Unicast Address Assignment Considerations
- Authors: G. Van de Velde and C. Popoviciu (Cisco Systems), T. Chown (University of Southampton), and O. Bonness and C. Hahn (T-Systems Enterprise Services GmbH)
- Stream: Network Working Group
- Category: Informational
- Date: December 2008
- Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🦋
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💜
Copyright Notice 🌈
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 📜
Abstract 🦋
okay so every IP network has an addressing plan, and that's a big deal 😭 IPv6 comes with a new address architecture and new allocation policies, so if you're bringing it into your network, you need to rethink how you do addressing. If nobody gives you guidance on this part of the design, IPv6 rollout could get slower, and nobody wants that 💀 This document gives you the info and recommendations for planning the addressing side of an IPv6 deployment. It also walks through IPv6 addressing case studies for both an enterprise network and an ISP network 🔥
Table of Contents 🎀
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network-Level Addressing Design Considerations . . . . . . . . 4
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network-Level Design Considerations . . . . . . . . . . . 6
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18
A.1.4. Node Configuration Considerations . . . . . . . . . . 18
A.2. Service Provider Considerations . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . 23
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30
B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.4. EUI-64 'u' and 'g' Bits . . . . . . . . . . . . . . . 31
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32
B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 341. Introduction ✨
okay so the Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC4291] defines three main types of addresses: unicast, anycast, and multicast. This doc is all about unicast addresses 💖 Right now there are two main allocated types: Globally Unique Addresses ('globals') [RFC3587] and Unique Local IPv6 Addresses (ULAs) [RFC4193]. There was also the 'experimental' 6bone address space [RFC3701] for a while, but its use has been deprecated since June 2006 [RFC3701] 🥀
This document covers the stuff you should think about during IPv6 deployment when you're designing and planning an addressing scheme for an IPv6 network. Your network's addressing plan might be for an IPv6-only network, or for a dual-stack setup where some or all devices have addresses in both protocols 🌸 All of this helps an IPv6 network designer assign the IPv6 address space allocated to their organization efficiently and carefully 🫶
The address assignment considerations get analyzed separately for the two big components of an IPv6 unicast address: 'Network-Level Addressing' (the allocation of subnets) and the 'interface-id' (identifying the interface within a subnet). So the document also talks about address assignment to nodes and interfaces in an IPv6 network 🧚 Last, it gives two examples of deployed addressing plans, one for a service provider (ISP) network and one for an enterprise network 👑
Parts of this document point out the differences that an experienced IPv4 network designer should think about when planning an IPv6 deployment. For example:
- IPv6 devices will more likely be multi-addressed compared to their IPv4 counterparts. 🦋
- The practically unlimited size of an IPv6 subnet (2^64 bits) means you don't have to size subnets to device counts for the sake of (IPv4) address conservation. Iconic 💅
- The vastly increased subnet size affects the threat of address-based host scanning and other scanning techniques, as discussed in [RFC5157]. Not me thinking about scanners at 2am 💀
We're not going to discuss how a site or ISP should go about getting its globally routable IPv6 address prefix. In each case, the prefix received is either provider assigned (PA) or provider independent (PI) 🍓
We also aren't discussing PI policy. The observations and recommendations here are mostly independent of whether the address block is PA or PI. For now, we assume that when an IPv6 network changes provider, it will typically need to go through a renumbering process, as described in [RFC4192]. A separate document [THINKABOUT] makes recommendations to make the IPv6 renumbering process easier ✨
This document doesn't cover implementation stuff related to moving from the now obsoleted site-local addresses to ULAs. Some implementations know about site-local addresses even though they're deprecated, and don't know about ULAs even though they're the current specification. So switching between these address types can cause difficulties 😭
2. Network-Level Addressing Design Considerations 🌈
This section talks about the kinds of IPv6 addresses used at the network level for the IPv6 infrastructure. The kinds you can consider are Globally Unique Addresses and ULAs. We also comment on the deprecated 6bone address space here 🥀
2.1. Globally Unique Addresses 💜
The most commonly used unicast addresses will be Globally Unique Addresses ('globals'). No significant considerations are needed if the organization has an address space assignment and a single prefix is deployed through a single upstream provider 🎀
However, a multihomed site might deploy addresses from two or more service-provider-assigned IPv6 address ranges. Here, the network administrator needs to be aware of where and how these ranges are used in the multihomed infrastructure environment. How multiple prefixes get used can depend on why you're multihoming, like resilience failover, load balancing, policy-based routing, or multihoming during an IPv6 renumbering event 🔥 IPv6 has better support for multi-addressed hosts through the IPv6 default address selection methods described in RFC 3484 [RFC3484]. A multihomed host can therefore have two or more addresses, one per prefix (provider), and pick source and destination addresses to use as described in that RFC 🫶 Multihoming also brings some operational and administrative burdens beyond choosing multiple addresses per interface [RFC4218] [RFC4219] 😭
2.2. Unique Local IPv6 Addresses 🎀
okay so ULAs are the glow-up for the old site-local addresses in the IPv6 addressing architecture, and the reasons are all in [RFC3879] 💅. ULAs are lowkey better because they give you a high probability of a globally unique prefix 🌸. That matters when there's leakage (deliberate or accidental) or when networks get merged 🫶.
ULAs are kind of like the private address space [RFC1918] that IPv4 networks use 🦋. The twist is that in IPv6 networks we may expect to see ULAs used alongside global addresses, with ULAs used internally and globals used externally ✨. Thus, using ULAs does not imply using NAT for IPv6 💖. No cap, that's a big deal.
The ULA address range lets network admins 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 [RFC3177] 👑.
A site that wants to use ULAs can have (a) multiple /48 prefixes (e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56 or /64) 🍓. In all of the above cases, the ULAs can be randomly chosen according to the principles specified in [RFC4193] 🌈. However, in case (a) the use of randomly chosen ULAs will provide suboptimal aggregation capabilities 💀.
ULAs give you 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, ULAs may be deployed on their own 🌸. In a connected network that also deploys global addresses, both may be deployed, so hosts become multi-addressed (one global and one ULA), 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 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 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 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, ULAs allow easier network mergers than 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 Address Space 🌈
The 6bone address space was used before the Regional Internet Registries (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 has been deprecated as of 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 Design Considerations 💅
IPv6 gives network administrators a significantly larger address space, so they can get super creative with how they define logical and practical addressing plans 🦋. The subnetting of assigned prefixes can be done based on various logical schemes that involve factors such as:
- Using existing systems
- translate the existing subnet numbers into IPv6 subnet IDs
- translate the VLAN IDs into IPv6 subnet IDs
- Redesign
- allocate according to your need
- Aggregation
- Geographical Boundaries - by assigning a common prefix to all subnets within a geographical area.
- Organizational Boundaries - by assigning a common prefix to an entire organization or group within a corporate infrastructure.
- Service Type - by reserving certain prefixes for predefined services such as: VoIP, content distribution, wireless services, Internet 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 💀.
Logical addressing plans like these have the potential to simplify network operations and service offerings, and to simplify network management and troubleshooting ✨. A very large network would 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 🌸:
- 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 🍓.
- Network growth - The allocation mechanism for flexible growth of a network prefix, documented in 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) 🧚.
- ULA usage in large networks - Networks that have a large number of 'sites' that each deploy a ULA prefix that 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 from using a single ULA prefix for all 'sites', as a ULA still provides 16 bits for subnetting to be used internally 🫶.
- 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., 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 🦋.
- 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 that receives a /48 and is situated in a home with multiple LANs of different media types (sensor network, wired, Wi-Fi, etc.), or has a need for traffic segmentation (home, work, kids, 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 [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, a site will receive a /48 prefix [RFC3177]; however, different RIR service regions policies may suggest alternative default assignments or let the ISPs decide on what they believe is more appropriate for their specific case (see Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]) 💖. The default provider allocation via the RIRs is currently a /32 [RIPE_Nov07] 🍓. These allocations are indicators for a first allocation for a network 🧚. Different sizes may be obtained based on the anticipated address usage [RIPE_Nov07] 🌸. At the time of writing, there are examples of allocations as large as /19 having been made from RIRs to providers 🦋.
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 Host-Density (HD) value [RFC3194] for IPv6 is 0.94 compared to the current value of 0.96 for IPv4 🎀. Note that with IPv6, HD is calculated for sites (e.g., on a basis of /56), instead of for addresses as with IPv4 🔥.
3. Subnet Prefix Considerations 🎀
okay so bestie, the first big question in an IPv4 addressing plan is how long each subnet prefix should be 🌸 Unlike IPv4, the IPv6 addressing architecture [RFC4291] says that every subnet using Globally Unique Addresses and ULAs ALWAYS has a prefix length of 64 bits 💅 (this also goes for the deprecated 6bone and site-local addresses, fr fr). The only exception is special addresses that start with the binary value 000, like IPv4-compatible IPv6 addresses 🦋 These exceptions are mostly outside the scope of this doc, so we're not going there today ✨
Using a prefix length other than /64 will break a LOT of IPv6 features 😭 That includes Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others 💀 A bunch of other features that are in development or being proposed also rely on /64 prefixes, so it's giving "stick with the 64" energy 🫶
Here's the tea though: lots of IPv6 implementations will let the admin configure a subnet prefix shorter or longer than 64 bits 🙈 Using prefixes shorter than /64 would rarely be useful, so see Appendix B.1 for the discussion 🍓
Some network admins have used prefixes longer than /64 on links that connect routers, usually just two routers on a point-to-point link 🔥 On links where every address is assigned by manual configuration AND every node on the link is a router (not an end host) that the network knows about, admins don't need any of the IPv6 features that rely on /64 prefixes, so this can work ✨ But using prefixes longer than /64 is not recommended for general use, and using them on links with end hosts would be an especially bad idea 😭 Why? Because it's really hard to predict which IPv6 features the hosts will use in the future 💜
Appendix B.2 covers some practical stuff you have to think about when you use prefixes longer than /64 in limited cases 🧚 A bunch of IPv6 features use interface identifiers with a special form (like a certain fixed value in some bit positions). So when you use a longer-than-/64 prefix, it's prudent to avoid certain subnet prefix values. That way, nodes that assume the prefix is /64 won't wrongly think the addresses in that subnet have a special form 🙈 Appendix B.2 lists the subnet prefix values that are currently believed to be potentially problematic, BUT the list isn't exhaustive and it's expected to grow over time 🌈
Using /64 subnets is strongly recommended, even for links that only connect routers 👑 A deployment that follows the current IPv6 specs can't use other prefix lengths. The V6OPS WG thinks that, despite the drawbacks (and a potentially expensive network redesign if IPv6 features that rely on /64 subnets are needed later), some network administrators will still use prefixes longer than /64 🫠
3.1. Considerations for /64 Prefixes 🍓
Based on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix length to allocate to interfaces and nodes ✨
When you're using a /64 subnet length, address assignment for those addresses can be done by manual configuration, by a Dynamic Host Configuration Protocol [RFC3315], by stateless autoconfiguration [RFC4862], or by a combination of these [RFC3736] 💖
Note that RFC 3177 strongly prescribes 64-bit subnets for general usage 📣 Also, stateless autoconfiguration on most link layers (Ethernet included) is only defined for 64-bit subnets. In theory, some future autoconfiguration mechanisms might allow longer-than-64-bit prefix lengths, but the use of such prefixes is not recommended at this time 🦋
4. Allocation of the IID of an IPv6 Address 💅
To get a complete IPv6 address, an interface has to be associated with a prefix AND an Interface Identifier (IID) 🧚 Section 3 of this document analyzed the prefix selection considerations. This section talks about 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 fewest caveats for the network administrator is EUI-64 [RFC4862] 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. Once that allocation has been made, the EUI-64 [RFC4862] allocation procedure can assign the remaining 64 IID bits in a stateless manner 💖 All the considerations for selecting a valid IID have already been baked into the EUI-64 methodology, so you're literally covered 💅
4.2. Using Privacy Extensions 🔥
The main purpose of IIDs generated based on RFC 4941 [RFC4941] is to provide privacy to the entity using an IPv6 address 🦋 There aren't any particular constraints on using IPv6 addresses with IIDs as defined in [RFC4941], BUT there are some implications to be aware of when using privacy addresses as documented in Section 4 of RFC 4941 [RFC4941] 🌸
4.3. Manual/Dynamic Assignment Option 🍓
This section covers IID allocations that are NOT implemented through stateless address configuration (Section 4.1). They apply regardless of the prefix length used on the link 💜 It's out of scope for this section to discuss the various assignment methods (e.g., manual configuration, DHCPv6, etc.) 🧚
In this situation, a human does the actual allocation, and you have to think about the complete IPv6 address so that it doesn't overlap with any of the well-known IPv6 addresses 👑:
- Subnet Router Anycast Address (Appendix B.2.5.1)
- Reserved Subnet Anycast Address (Appendix B.2.5.2)
- Addresses used by Embedded-RP (Appendix B.2.6)
- Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses (Appendix B.2.7)
When using an address assigned by a human, it is recommended to choose IPv6 addresses 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 makes it harder for malicious third parties to guess targets for attack, which reduces security threats to a certain extent 🫶
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 Addresses (HBAs) 😭 That means it becomes impossible to use protocols that depend on them. This one is SERIOUS bestie, do NOT skip it 🚨
6. Acknowledgements 💜
Constructive feedback and contributions were received during the 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, and the IESG 🙌✨
7. Informative References 📚
Okay bestie, here's the reading list 🧚 Every single source is below, exactly as the document lists them, so you can go deep on whatever catches your eye 💖
[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 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, "Site Multihoming by IPv6 Intermediation
(shim6) Charter", <http://www.ietf.org/html.charters/
shim6-charter.html>.
[ARIN] ARIN, "ARIN Number Resource Policy Manual",
Version 2008.4, September 2008,
<http://www.arin.net/policy/nrpm.html>.
[RIPE_Nov07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
Assignment Policy", ripe-421, November 2007,
<http://www.ripe.net/ripe/docs/ipv6policy.html>.
[RIPE_Jul07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
Assignment Policy", ripe-412, July 2007,
<http://www.ripe.net/ripe/docs/ripe-412.html>.
[APNIC_IPv6] APNIC, "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", Work in Progress, March 2007.Appendix A. Case Studies 🌸
This appendix is giving two case studies 💅 Both are IPv6 addressing schemas built on the statements and considerations in this document, and they show how it got used in two specific network scenarios 🦋 They're meant as basic considerations for an admin designing an IPv6 addressing schema for an enterprise or ISP network. They are not a general design proposal for every kind of IPv6 network, so don't copy-paste them blindly 🙈 All the subnet sizes here are just for practical visualization and do not dictate RIR policy ✨
A.1. Enterprise Considerations 🎓
In this section we look at a campus network deploying IPv6 alongside its existing IPv4 protocols in a dual-stack environment 🌈 The example is the University of Southampton (UK), with a focus on one large department inside that network. The deployment currently covers around 1,000 hosts and over 1,500 users 🔥
A.1.1. Obtaining General IPv6 Network Prefixes 🍓
For a campus, the site usually gets its connectivity from its National Research and Education Network (NREN) 🧚 Southampton connects to JANET, the UK academic network, through its local regional network LeNSE (Learning Network South East). JANET currently holds a /32 allocation from RIPE NCC. The current recommended practice is for sites to receive a /48 allocation, so Southampton got one of those for its own use 💖 The regional network also has its own allocation from the NREN provider.
No ULA addressing is used on site 🫶 The campus isn't multihomed (JANET is the only provider), and it doesn't expect to change service provider. So it doesn't plan to use ULAs for the (perceived) benefit of making renumbering easier 🙈 Honestly, the campus has renumbered twice using the renumbering procedure [RFC4192] mentioned above, and it's worked out fine, with provisos documented in [THINKABOUT] ✨ The campus doesn't see any need to deploy ULAs for in-band or out-of-band network management either, because there are plenty of IPv6 prefixes in the site allocation for the infrastructure 💅 In some cases, using private IP address space in IPv4 causes problems, so the University of Southampton believes that having lots of global IPv6 address space for infrastructure may be a real benefit for many sites 👑
No 6bone addressing is used on site anymore. Since the 6bone phaseout of June 2006 [RFC3701], most transit ISPs have started filtering attempted use of those prefixes 💀
Southampton does take part in global and organizational scope IPv6 multicast networks 🌈 Multicast address allocations aren't discussed here, since they're out of scope for this document. Still, IPv6 has real advantages for multicast group address allocation, and it's worth noting 🦋 In IPv4, a site needs techniques like GLOP [RFC3180] to pick a globally unique multicast group. That gets messy if the site doesn't use the Border Gateway Protocol (BGP) [RFC4271] and doesn't have an Autonomous System Number (ASN) 😭 In IPv6, unicast-prefix-based IPv6 multicast addresses let a site pick a globally unique group address based on its own unicast site or link prefix, which is so iconic 🔥 Embedded-RP is also in use, it's seen as a potential advantage for IPv6 and multicast, and it's been tested successfully across providers between sites (including paths to and from the US and UK) 🎀
A.1.2. Forming an Address (Subnet) Allocation Plan ✨
okay so the campus has a /16 for IPv4 🌸, which on paper gives you 256 subnets of 256 addresses each. ngl the real subnetting is way muddier because of IPv4 address conservation 😭. Subnets get sized to the hosts living in them, so a /26 IPv4 prefix is used if a subnet has 35 hosts. It's efficient, yes, but it means more management stress when physical deployments change, and IPv4 subnets need resizing (up or down) even when DHCP is in use 💀
the /48 IPv6 prefix is way bigger than the IPv4 allocation the site already has 👑. It's loosely like a 'Class A' IPv4 prefix, because it gets you 2^16 (over 65,000) subnets. The difference is that each subnet has an effectively unlimited address size (2^64), compared to just 256 in IPv4 🦋. Because the subnets are so huge, /64 IPv6 prefixes can go on every subnet, and nobody has to resize them later 🙌. The extra room also means subnets can be handed out more generously to schools and departments. Address conservation still matters, but it's no longer a blocker for network management. Address (subnet) allocation is now about embracing the available address space and planning for future expansion 🌈
in the dual-stack network, the team chose to deploy IP subnets congruently for IPv4 and IPv6 🧚. That's because the systems are still in the same administrative domains and the same geography. IPv6-only subnets aren't expected in production for a while yet, apart from the test beds and some early Mobile IPv6 trials. With congruent addressing, the firewall policies also line up for IPv4 and IPv6 traffic at the site border 🔥
the subnet allocation plan split the address space per school or department 💅. A /56 went to the school level of the university, and there are around 30 schools right now. A /56 of IPv6 address space works out to 256 /64 subnet allocations. More /56 allocations were made for central IT infrastructure, the network infrastructure, and the server side systems 🍓
A.1.3. Other Considerations 🎀
the network uses a Demilitarized Zone (DMZ) topology to protect 'public' systems to some degree 🛡️. Again, this topology is congruent with the IPv4 network.
there are no specific transition methods deployed internally on campus. Everything is using the conventional dual-stack approach, and there's no use of ISATAP [RFC5214], for example 🙅♀️
for the early Mobile IPv6 trials, there's one allocated prefix for Home Agent (HA) use. However, there hasn't been any detailed thinking yet about how Mobile IPv6 usage might grow, or whether more subnets (or even every subnet) will need HA support 🤔
the university runs a tunnel broker [RFC3053] service on behalf of the United Kingdom Education and Research Network Association (UKERNA) for JANET sites. It uses separate address space from JANET, not the university site allocation 🦋
A.1.4. Node Configuration Considerations 🫶
right now, stateless autoconfiguration is used on most subnets for IPv6 hosts ✨. There's no DHCPv6 service deployed yet, just tests of early code releases. The plan is to deploy DHCPv6 for address assignment once robust client and server code is available. At the time of writing, that's looking promising, for example via the Internet Systems Consortium (ISC) implementation 👑. The University of Southampton is also looking into a common integrated DHCP/DNS management platform, even if the servers themselves aren't co-located. That includes integrated DHCPv4 and DHCPv6 server configuration, as discussed in [RFC4477] 🧚. For now, clients with statelessly autoconfigured addresses get added to the DNS manually, though dynamic DNS is an option. The network administrators would prefer DHCP, because they believe it gives them more management control 💅
about the implications of the larger IPv6 subnet address space on scanning attacks [RFC5157]: all the hosts are dual-stack, so they're potentially exposed over both protocols anyway 😬. All addresses are published in DNS, and the site doesn't operate a two-faced DNS 🙈
there's internal usage of RFC 4941 privacy addresses [RFC4941] (certain platforms ship with it on by default) 🌸. Network administrators may want to disable it, perhaps via DHCP, to ease management complexity. However, the team wants to determine whether that's feasible on all systems, for example guests on the wireless LAN or other user-maintained systems. Network management and monitoring should be simpler without RFC 4941 in operation, since it's easier to identify which physical hosts are using which addresses 🔍. Note that RFC 4941 is only an issue for outbound connections, and there's potential to assign privacy addresses via DHCPv6 ✨
manually configured server addresses are used so the addresses don't change when the network adaptor changes 🔧. With IPv6 you can pick ::53 for a DNS server, or you can pick 'random' addresses for obfuscation. That's not an issue for publicly advertised addresses (dns, mx, web, etc.), though 🌈
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 💖
Appendix A.2.1 starts with some thoughts on the objective requirements of such an addressing schema, and derives a few general rules of thumb to keep in mind when designing an ISP IPv6 addressing plan 🧠
Appendix A.2.2 illustrates the findings of Appendix A.2.1 with an exemplary IPv6 addressing schema for an MPLS-based ISP. That ISP offers Internet services as well as network access services to several millions of customers 🚀
A.2.1. Investigation of Objective Requirements for an IPv6 Addressing Schema of a Service Provider 🔥
the first step of designing an IPv6 addressing plan for a service provider should be identifying all technical, operational, political, and business requirements that have to be satisfied by the services this addressing schema supports 📝
depending on the different technical constraints and business models, plus the different weights of these requirements (from the point of view of the service provider), it's very likely that different addressing schemas will be developed and deployed by different ISPs 🦋. Still, the addressing schema of Appendix A.2.2 is one possible example 💅
for this document, it's assumed that our exemplary ISP has to fulfill several roles for its customers, such as:
- Local Internet Registry
- Network Access Provider
- Internet Service Provider
A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR Perspective of the Service Provider 👑
in its role as Local Internet Registry (LIR), the service provider has to care about the policy constraints of the RIRs and the IETF standards for 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:
- As recommended in RFC 3177 [RFC3177] and in several RIR policies, "Common" customers sites (normally private customers) should receive a /48 prefix from the aggregate of the 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.) 🎀
- "Big customers" (like big enterprises, governmental agencies, etc.) may receive shorter prefixes according to their needs, when their needs can be documented and justified to the RIR 🏢
- 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. (Note: The currently valid IPv6 HD-ratio of 0.94 means an effective usage rate of about 22% of a /20 prefix of the service provider, on the basis of /56 assignments.) 📊
- All assignments to customers have to be documented and stored in a database that can also be queried by the RIR 🗂️
- The LIR has to make available the means for supporting the reverse DNS mapping of the customer prefixes 🔁
- IPv6 Address Allocation and Assignment Policies can be found at the RIRs, and they're similar in many 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, the following basic requirements can be identified 💜
- 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. Only this provider aggregate will be routed and injected into the global routing table (DFZ, "Default-Free Zone"). This strong aggregation keeps the routing tables of the DFZ small and eases filtering and access control very much 🌈
- The IPv6 addressing schema of the SP should contain optimal flexibility, since the infrastructure of the SP will change over time with new customers, transport technologies, and business cases. Optimal flexibility is contrary to the recommendation of strong IPv6 address aggregation and efficient address usage, but each SP has to decide which of these requirements to prioritize ⚖️
- While keeping the multilevel network hierarchy of an ISP in mind, note that due to addressing efficiency reasons, not all hierarchy levels can and should be mapped into the IPv6 addressing schema of an ISP. Sometimes it's much better to implement a more "flat" addressing for the ISP network than to lose big chunks of the IPv6 address aggregate in addressing each level of the network hierarchy. (Note: In special cases, it is even recommended for really "small" ISPs to design and implement a totally flat IPv6 addressing schema without any level of hierarchy.) 🍓
- A decoupling of provider network addressing and customer addressing is recommended. (Note: A strong aggregation (e.g., on POP, Aggregation Router (AG), or Label Edge Router (LER) level) limits the number of customer routes that are visible within the ISP network, but 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 Perspective of the Service Provider
okay so we already did the LIR and ISP hats for the SP 💅 but the SP is also a Network Access Provider, so it has its own pile of requirements to deal with 🧚 here are the basics:
- the SP's IPv6 addressing schema must be chosen so it can handle new requirements that come from the customer side 🦋 think a customer whose need for IPv6 addresses keeps growing, or a customer who changes the access network topology, like moving from one point of network attachment (POP) to another 🚚 (see Appendix A.2.3.4, "Changing the Point of Network Attachment" 💖)
- for each IPv6 address assignment to a customer, a "buffer zone" should be reserved, so the customer can grow inside its addressing range without renumbering or getting extra prefixes 🌸
- the SP's addressing schema must also deal with a single customer attaching to the SP network infrastructure more than once (multihomed network access with the same SP) 🔥
these few are just part of the list 📝 an SP has to look into and keep in mind while it defines its addressing architecture, and each SP will most likely add more constraints of its own 💀
A.2.1.4. A Few Rules of Thumb for Designing an ISP IPv6 Addressing Architecture
so based on all the requirements listed above for an ISP IPv6 addressing plan, these design "rules of thumb" came out of it 👑
- no "One size fits all" 🙅♀️ every ISP has to build its own IPv6 address allocation schema based on its real business needs. one addressing plan that fits every kind of ISP (small / big, routed / MPLS-based, access / transit, LIR / No LIR, etc.) just isn't practical, bestie 😭
- the levels of IPv6 address aggregation in the ISP addressing schema should strongly match the network structure that's actually implemented, and their number should be kept as low as possible for efficiency reasons ⚡ the SP's own infrastructure is assumed to be addressed in a pretty flat way, while the customer part of the addressing architecture should have several levels of aggregation 🧱
- keep the number of IPv6 customer routes inside your network as small as possible 🎀 a totally flat customer addressing architecture with no middle aggregation level will create tons of customer routes inside the SP network 🙈 you need a fair trade-off between aggregation levels (which affects the size of the SP's internal routing table) and address conservation 🫶
- the ISP IPv6 addressing schema should give maximal flexibility ✨ it has to support different sizes of customer IPv6 address aggregates ("big" customers vs. "small" customers), allow for future growth (for example, of customer aggregates), and cope with possible topological or infrastructural changes 🌈
- a limited number of aggregation levels and sizes of customer aggregates makes the schema easier to manage 🍓 but this has to be weighed against the previous "rule of thumb", flexibility 💜
A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider
in this example, the service provider runs an MPLS-based backbone and uses IPv6 Provider Edge Routers (6PE) [RFC4798] to give IPv6 backbone transport between the different locations (POPs) of a fully dual-stacked network access and aggregation area 🛣️✨
on top of that, the service provider is assumed to:
- have received a /20 from its RIR 🎉
- operate its own LIR 👑
- have to address its own IPv6 infrastructure 🏗️
- delegate prefixes from this aggregate to its customers 🎀
this addressing schema is here to show how the SP's /20 IPv6 prefix can address the SP's own infrastructure and delegate IPv6 prefixes to customers, following the requirements and rules of thumb from above as far as possible 💅
the figure below sums up the device types in an SP network and what a typical MPLS-based SP network design looks like 🦋 the network hierarchy of the SP has to be considered when designing an IPv6 addressing schema, because it sets the basic shape of the schema and the different 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 |
+-------------------------------------------------------------------+
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
Exemplary Service Provider Networkthese are the big decisions to keep in mind when designing the exemplary SP IPv6 addressing plan for customer prefixes 🧁
- the prefixes given to all customers behind the same LER (or LER-BB) get aggregated under one LER prefix 💫 this keeps the number of labels needed for 6PE limited, which gives strong MPLS label conservation 🏷️
- the SP's /20 prefix gets split into 3 different pools that are used to hand out IPv6 prefixes to the SP's customers 🍰
- a pool (e.g., /24) for the really "big" customers (as defined in Appendix A.2.2.1.1) who need IPv6 prefixes larger than /48 (e.g., /32) 🐘 these customers are assumed to connect to several POPs of the access network, so their customer prefix shows up in each of those POPs 🌍
- a pool (e.g., /24) for the LERs with direct customer connections (e.g., dedicated line access) and no extra aggregation area between the customer and the LER 🔌 these LERs mostly serve a limited number of customers because they only have so many interfaces/ports 🙃
- a larger pool (e.g., 14*/24) for LERs (or LER-BBs) that serve a high number of customers who are usually connected through some kind of aggregation network (e.g., DSL customers behind a BB-RAR or dial-in customers behind a RAR) 📞💕
- the IPv6 address delegation inside each pool (whether it's the end customer delegation or the aggregates dedicated to the LER itself) should be planned with an extra buffer zone of 100-300% for future growth 🌱 in other words, 1 or 2 additional prefix bits should be reserved, depending on the expected future growth rate of the customer or the device aggregate 📈
A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the Service Provider
A.2.2.1.1. "Big" Customers
the SP's "big" customers get their prefix from the /24 IPv6 address aggregate that's been reserved for them 👑 a customer counts as "big" if it has a very complex network infrastructure, huge IPv6 address needs (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 that customer 🔒 for instance, if a customer gets a /34, the /32 prefix that contains that /34 is reserved for the customer's future use 🧠
the prefixes for "big" customers can be picked from the matching "big customer" pool either with an equidistant algorithm or with mechanisms similar to the Sparse Allocation Algorithm (SAA) [RIPE_Nov07] 🌟
A.2.2.1.2. "Common" Customers 💅
Okay so every customer that isn't a "big" customer counts as a "common" customer 🫶. They're the majority, so they each get a /48 out of the IPv6 customer address pool of the LER where they're directly connected or aggregated 🌸.
Again, a 100-300% future growing range is reserved for each customer ✨, so a "common" customer gets a /48 allocation but has a /47 or /46 reserved in the background.
(Note: If it's obvious that a "common" customer is very unlikely to need a /47 or /46 later, then no growing buffer should be reserved for them, and only a /48 gets assigned without any growing buffer 🙈.)
In network access scenarios where the customer is directly connected to the LER, the customer prefix is taken straight out of the customer IPv6 address aggregate (for example, a /38) of that LER 💖.
For other cases (for example, the customer is attached to a RAR that is itself aggregated to an AG or to a LER-BB), at least 2 different approaches are possible 🦋.
- 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, so you get 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: Of course, this approach requires 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, meaning an AG or RAR) is exhausted, the related LER (or AG or RAR) prefix is shortened by 1 or 2 bits (for example, 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 can be requested from the corresponding pool of the next-higher hierarchy level 🔄.
- "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 🍓. Of course, this approach leads to a higher number of customer routes at the LER and aggregation network level, but it takes a great amount of complexity out of the addressing schema 😌. Nevertheless, the aggregation of the customer prefixes into one prefix at the LER level is still realized as required above.
Note: The handling of changes (for example, technically triggered changes) within the ISP access network is discussed briefly in Appendix A.2.3.5 👀.
If the actual observed growing rates show that the reserved growing zones aren't needed, then they can be freed up and used for assignments of 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 the SP's 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 SP's network infrastructure by assigning a /48 to every POP/location and using (for instance) a /56 for coding the corresponding router within that 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, it is left to each SP to decide what prefix length to assign to the routers and links within the POP 🤷♀️.)
The IIDs of the router interfaces may be generated by using EUI-64 or through plain manual configuration, for example to code additional network or operational information into the IID 🧩.
Again, it is assumed that 100-300% growing zones are needed for each level of the network 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 the SP's own IPv6 network infrastructure leaves enough space to code additional functionalities, like security levels or private and 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 (for example, PPP links, dedicated lines, etc.) may be addressed using /126 prefixes out of the first /64 of the access routers, which could be reserved for this reason 🔐.
A.2.3. Additional Remarks 📝
A.2.3.1. ULA
There are no compelling reasons for service providers to use ULAs. See Section 2.2 🚫.
ULAs could be used inside the SP network to have an additional "site-local scoped" IPv6 address for the SP's own infrastructure. For instance, this could be for network management reasons, and it gives you an addressing schema that can't be reached from outside the SP network 🛡️.
When ULAs are used, it's possible to map the proposed internal IPv6 addressing of the SP's own network infrastructure (as described in 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 addressing issues are out of the scope of this document 🙅♀️.
A.2.3.3. POP Multihoming
POP multihoming (or better, LER multihoming) of customers with the same SP can be realized within the proposed IPv6 addressing schema of the SP in one of two ways. You can assign multiple LER-dependent prefixes to the customer (that is, treat each customer location as a single customer), or you can choose 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, which requires an explicit MPLS label 😬.
Note: The negative effects (described above) of POP/LER multihoming on the addressing architecture in the SP access network are not resolved by implementing the Site Multihoming by IPv6 Intermediation (SHIM6) approach. SHIM6 only targets a mechanism for dealing with multiple prefixes in end systems. The SP is expected to have unaggregated customer prefixes in its internal routing tables 🫠.
A.2.3.4. Changing the Point of Network 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, two different approaches can be applied, assuming that the customer uses PA addresses out of the SP aggregate 🚚:
- 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 attachment. To minimize the administrative burden for the customer, the prefix should be the same size as the former one. This conserves the IPv6 address aggregation within the SP network (and the MPLS label space) but adds extra burden to the customer. Hence, this approach will most likely only be chosen for "small customers" with temporary addressing needs and/or prefix delegation with address autoconfiguration 🥺.
- The customer does not need to renumber its network and keeps its address aggregate.
This approach leads to additional, more-specific routing entries within the IGP routing table of the LER, and will hence consume additional MPLS labels, but it's totally transparent to the customer ✨. Because this results in additional administrative effort and will stress the router resources (label space, memory) of the ISP, this solution will only be offered to the most valuable customers of an ISP (for example, "big customers" or "enterprise customers") 💼.
Nevertheless, the ISP again has to find a fair trade-off between customer renumbering and sub-optimal address aggregation (that is, the generation of additional more-specific routing entries within the IGP and the waste of MPLS label space) ⚖️.
A.2.3.5. Restructuring of SP (Access) Network and Renumbering
A technically triggered restructuring of the SP (access) network (for instance, because of a split of equipment or the installation of new equipment) should not lead to a customer network renumbering 🙏. This challenge should be handled in advance through intelligent network design and IPv6 address planning 🧠.
In the worst case, customer network renumbering could be avoided by implementing 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 an SP needs some slight enhancements or modifications for the later phases of IPv6 integration. For instance, this is the case when the whole MPLS backbone infrastructure (LDP, IGP, etc.) is realized over IPv6 transport, and an IPv6 addressing of the LSRs is needed. Other changes may be necessary as well, but they should not be explained at this point 🤐.
Appendix B. Considerations for Subnet Prefixes Different than /64 🌷
B.1. Considerations for Subnet Prefixes Shorter than /64
An allocation of a prefix shorter than 64 bits to a node or interface is considered bad practice 🙅♀️. One exception to this is when using 6to4 technology, where a /16 prefix is used 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 a subnet prefix for an interface shorter than /64 is that it would allow more nodes to be attached to that interface compared to a prescribed length of 64 bits 👯. The prescribed /64 does include 2 functional bits, the g bit and the inverted u (universal/local) bit, and these can't be chosen at will 🔒. However, a larger address space than a /64 is unnecessary for most networks, considering that 2^62 provides plenty of node addresses 🤯.
The subnet prefix assignments can be made by manual configuration, by a stateful Host Configuration Protocol [RFC3315], by a stateful prefix delegation mechanism [RFC3633], or implied by stateless autoconfiguration from prefix Router Advertisements (RAs) 📡.
B.2. Considerations for Subnet Prefixes Longer than /64
The following subsections describe subnet prefix values that should be avoided in deployments, because nodes that assume the subnet prefix is /64 could treat them incorrectly 🚨.
B.2.1. /126 Addresses
126-bit subnet prefixes are typically used for point-to-point links, similar to the IPv4 address-conservative /30 allocation for point-to-point links 🔗. The usage of this subnet address length does not lead to any considerations beyond those discussed earlier in this section, particularly those related to the u and g bits (see B.2.4.
B.2.2. /127 Addresses ✨
okay so /127 addresses are the IPv6 version of the whole IPv4 RFC 3021 [RFC3021] vibe 💅. bestie, they're not valid, and they really should be strongly discouraged, as laid out in RFC 3627 [RFC3627] 🙈 not it.
B.2.3. /128 Addresses 🦋
a /128 prefix is a good fit when you know for a fact that one, and only one, address is enough 🎀 an off-link loopback address on a network device is a classic example.
when you're picking a 128-bit prefix, it's recommended to think about the 'u' and 'g' bits and make sure you don't overlap with any of these well-known addresses 👑
- Subnet Router Anycast Address
- Reserved Subnet Anycast Address
- Addresses used by Embedded-RP
- ISATAP Addresses
B.2.4. EUI-64 'u' and 'g' Bits 🌸
when you use subnet prefix lengths other than /64, the interface identifier can't be in Modified EUI-64 format, which is what [RFC4291] requires 😭 but nodes that don't know a prefix other than /64 is in use might still think it's an EUI-64. so it's prudent to keep these points in mind when you set the bits 🫶
the main reason people go longer than 64 bits is to conserve address space, but ngl that savings is tiny compared to the extra work you take on when you create and maintain an IPv6 addressing plan 💀
the address can get assigned either by manual configuration or by a stateful Host Configuration Protocol [RFC3315] ✨
when you assign a subnet prefix longer than 70 bits, RFC 4291 [RFC4291] says the 'u' and 'g' bits (the 71st and 72nd bits, respectively) need to be considered, and they should be set correctly 🔥
the 71st bit of an IPv6 address is the inverted 'u' (universal/local) bit, and it tells you whether the address is universally or locally administered. if it's 1, the IEEE has administered the address through a unique company ID. if it's 0, the address is locally administered, which means the network administrator overrode the manufactured address and specified a different one 🧚
the 'g' (individual/group) bit is the 72nd bit, and it tells you whether the address is an individual address (unicast) or a group address (multicast). if it's '0', it's a unicast address. if it's '1', it's a multicast address 💜
in current IPv6 protocol stacks, the 'u' and 'g' bits are pretty marginal, and getting them wrong typically won't throw an error. future implementations might act differently, though, if they process the 'u' and 'g' bits with IEEE-like behavior 👀
when you use subnet lengths longer than 64 bits, it's important to avoid picking addresses that might have a predefined use and could confuse IPv6 protocol stacks. the alternate usage might not be a simple unicast address in every case. these are the points you should consider when you pick a subnet length longer than 64 bits 🍓
B.2.5. Anycast Addresses 🌈
B.2.5.1. Subnet Router Anycast Address 💖
[RFC4291] gives the definition of the required Subnet Router Anycast Address like this 🎀
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+it's recommended to avoid giving this IPv6 address to a device that's expecting a normal unicast address 🙈
B.2.5.2. Reserved IPv6 Subnet Anycast Addresses ✨
[RFC2526] stated that inside each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses 👑
how a reserved subnet anycast address gets built depends on the type of IPv6 address used in the subnet, which you can tell from the format prefix in the addresses 🦋
the first type of Subnet Anycast addresses was defined like this for the Modified EUI-64 format 💅
| 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+the anycast address structure means it's important to avoid creating a subnet prefix where bits 65 to 121 are set to "1111110111...111" (57 bits in total), so nothing gets confused 😭
for other IPv6 address types (meaning ones with format prefixes other than the ones listed above), the interface identifier isn't in 64-bit extended unique identifier (EUI-64) format and might not be 64 bits long. the reserved subnet anycast addresses for those types are built like this 🌸
| n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+
| interface identifier field |again, it's recommended to avoid giving this IPv6 address to a device that's expecting a normal unicast address 🫶
B.2.6. Addresses Used by Embedded-RP (RFC 3956) 🧚
Embedded-RP [RFC3956] is the idea of putting the Rendezvous Point (RP) IPv6 address inside the IPv6 multicast group address 🌈 because the IPv6 address AND the IPv6 multicast address are both 128 bits long, the complete IPv6 address of the multicast RP can't just be embedded as-is 💀
that means there's a limit of 15 possible RP-addresses per prefix that can work with embedded-RP. the space for embedded-RP is based on the 4 low-order bits, and the rest of the Rendezvous Interface ID (RIID) is set to all '0'. the IPv6 multicast group address used by embedded-RP looks like this 💜
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
where: (RIID) = 4 bits.so if you pick a subnet prefix longer than 64 bits and any bits past the 64th bit are non-zero, that subnet can't use embedded-RP 🙈
also, it's discouraged to assign a matching embedded-RP IPv6 address to a device that isn't a real Multicast Rendezvous Point. it wouldn't cause major problems, but still 👀
B.2.7. ISATAP Addresses 🍓
ISATAP [RFC5214] is an experimental automatic tunneling protocol that gives you IPv6 connectivity over an IPv4 campus or enterprise environment 🌸 to take advantage of the underlying IPv4 infrastructure, the IPv6 addresses get built in a special format 🎀
an IPv6 ISATAP address has the IPv4 address embedded in it, following a predefined structure policy that marks it as an ISATAP address. the format looks like this ✨
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]when you use a subnet prefix longer than 64 bits, it's good engineering practice to make sure the part of the IPv6 prefix from bit 65 to the end of the host-ID doesn't match the well-known ISATAP [0000:5EFE] address when you assign an IPv6 address to a non-ISATAP interface 🫶
just so you know, the definition of ISATAP doesn't support multicast 💅
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 USA 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
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
that's the whole RFC, bestie!! 🌈💖✨
📦 where this page comes from
- ietf: rfc5375 2008-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms