IPv6 Addressing Considerations

By Ciprian Popoviciu and Gunter Van de Velde

Description

It is universally accepted that the most important driver for IPv6 adoption is the rapidly growing demand for IP address resources, a demand which cannot be met by IPv4. Designing a practical, meaningful, and efficient addressing scheme is an important step in planning and deploying the new protocol. You might find the process of designing an IPv6 addressing scheme challenging, having to negotiate changing standards and policies while learning to take a new perspective fitting for the size of the available resources.

This article discusses some of the major considerations related to IPv6 addressing, particularly relating to prefix length. These topics represent a subset of the detailed analysis performed in the IETF informational document IPv6 Unicast Address Assignment Consideration.

Policies

The easiest and possibly least controversial way to discuss the prefix length considerations in IPv6 is to start from the top, with IANA and RIR allocation policies. These policies observe several principles which encourage:

• Early good stewardship of the address space
• Aggressive aggregation practices to reduce the size of routing tables
• New perspectives in designing addressing schemes

Figure 1 highlights the hierarchical nature of the allocation policies, as well as the size of the allocations at each organizational boundary. Some allocation policies are a bit more specific when it comes to recommending the size of allocations made by ISPs. The RIR recommendations may distinguish between large sites (/48) such as enterprises, and small sites (/56), such as a residential user. Nevertheless, the policies make only recommendations about these boundaries, thus leaving it up to the ISPs to decide, for example, how large of prefix to assign to a home user.

It is important to remember that these policies will likely continue to evolve as they did up to this point. The current version described in Figure 1 resulted from quantitative changes related to the size of the allocations and from qualitative changes where the Provider Independent option was added to the original Provider Assigned one. Allocation policies and recommendations are likely to continue to change as deployment experience grows and IPv6 adoption increases.

Home Prefix Length Debate

While things are relatively clear down to the ISP level, debates heat up when it comes to deciding the size of allocations to customers of ISPs. Agreement seems easy to achieve when it comes to enterprises and the /48 and /56 assignment recommendations of the policies. With respect to the prefix length for residential users, the source of debate is the conflict between two visions: (1) complex IP infrastructures in homes, infrastructures that involve multiple networks and (2) the concerns related to address space waste. IPv6 addressing architecture, defined in RFC 4291, requires a 64-bit Interface ID (IID), a controversial topic revisited later in the article. Multiple networks in the home imply multiple /64 allocations per home, which is an allocation some see as extravagant. While 264 hosts per subnet seems too much, this approach simplifies provisioning through the current definition of Stateless Address Auto Configuration (SLAAC) [RFC4862], an essential provisioning tool for home environments. Moreover, the envisioned multi-link home networks are suitable for a multitude of device and service types targeted for home users. Nevertheless, changes in RFC 4291 could lead to redefined boundaries which, according to RFC 4862, should still be able to support other forms of SLAAC.

Today, in real world deployments, we see both visions implemented. There are deployments where a /56 is assigned per home. We also see, although more rarely, conservative deployments where a /64 is assigned per home.

The Link Prefix Length Wars

Another hot debate revolves around the prefix length assigned to a link. You would assume that when it comes to assigning prefixes to links, things should be pretty straightforward seeing that IPv6 addressing architecture is implicitly (even though not explicitly) defined to be classless (CIDR). We should be able to choose whatever prefix length we see appropriate for the expected number of hosts on a given link. As mentioned earlier and shown in Figure 2, RFC 4291 places a clear constraint on choices by requiring the IID to be 64 bits long, thus requiring the prefixes of all links to be exactly 64 bits long (/64).

While in certain circumstances a /64 assignment per link might be easier to accept, the address space conservationists become outraged when it comes to assigning a /64 to point-to-point links or device loopback interfaces. Typically one finds many point-to-point links throughout the infrastructure, for example, in data centers or between routers. The number of point-to-point links can add up quickly, leading to significant use of address space.

Using /64s everywhere provides the benefit of consistency and makes prefix allocation and aggregation easier and cleaner. Using shorter prefix lengths does not make sense since a /64 provides more IIDs than might be healthy for any layer two broadcast domain. Longer /64 prefixes are; however, considered a fair, if not responsible, choice by many and so, in real deployments, people purposefully ignore the requirement of RFC 4291. A good example is using /126 for point-to-point links and /128 for loopback addresses.

Addressing schemes that go for per link prefix lengths different than /64 do need to be mindful of any possible conflicts with the existing standards and challenges with stack implementations. Such conflicts are discussed in draft-ietf-v6ops-addcon.

There are other practical considerations for the resistance to the requirement to use /64 prefixes per link, such as security concerns for point-to-point links. In general; however, it comes down to a debate between simplification of addressing and conservation of resources. This debate is ongoing, so it is important to monitor its evolution in IETF.

Summary

Designing a meaningful, long-lasting IPv6 addressing scheme is a very important initial step in planning the deployment of IPv6. However, the community did not reach full consensus on all the rules that should guide such an effort. For this reason we lack best practices guides. Some documents are available to help planners avoid pitfalls and make informed decisions; however, along with the continued evolution of the protocol and of our experience with deploying it, the addressing architecture, the guidelines, and recommendations will likely continue to change. For these reasons, it is important to monitor ongoing IETF and RIR activities.

About the Authors:

Ciprian Popoviciu, PhD, is a Technical Leader at Cisco Systems with over 10 years of experience in data and voice over IP communications technologies. As part of Cisco's Network Solution Integration Test Engineering (NSITE) organization, he focuses on the architecture, design, and validation of large IPv6 network deployments in direct collaboration with Service Providers and Enterprises worldwide. Ciprian is a regular speaker or chair at conferences and industry events and contributes to various technology publications. He is an active contributor to the IETF standards, a senior member of IEEE, and member of several academic advisory boards. Ciprian is co-author of two books: "Deploying IPv6 Networks" and "Global IPv6 Strategies".

Gunter Van de Velde, Ind., CCIE No.3741 is a Technical Leader in Cisco Systems Enterprise and Commercial Market Deployment team, and has been working in the field of core network design since 1997. Since early 2001, Gunter has been active with real-live IPv6 implementations. Gunter currently holds the function as global IPv6 Technical Marketing Engineer for Cisco Systems and has been the lead design architect for the well-recognized EU sponsored 6NET project, the first international native IPv6 backbone infrastructure. Gunter is a frequent speaker at IPv6 conferences. He is an active contributor to IETF and has been a technical reviewer of the Cisco Press book "Deploying IPv6 Networks."