IPv6 Address Planning (2015)

Part II. Design

Chapter 6. Getting IPv6 Addresses

Introduction

Creating our first IPv6 address plan presents another minor catch-22 scenario: it’s a little more complicated to construct an address plan without knowing up front how much IPv6 address space we’ll need. On the other hand, it’s also difficult to know how much IPv6 address space to request until we’ve worked through enough of our plan to be confident that we’re asking for the right amount.

So we’ll actually have to do a bit of address planning design before we request an IPv6 allocation. While we’ve established that the enormous size of the typical allocation makes sufficient host addressing concerns generally irrelevant, we still need enough groups of subnets to make sure our address plan provides operational efficiency and manageable growth.

Keep in mind that since we’re constructing an address plan geared toward operational efficiency, one where conservation of address space is in nearly all cases a negligible concern, it should be possible to use the ideas and methods in this book to develop a plan based on the assumption that we’ll be granted the address space we need from the allocating agency. While a rough estimate of the right amount of address space may be useful to help us get started with developing our plan, we should be perfectly comfortable with coming to realize as we work through the planning process that we need more (or less) address space than we initially assumed.

TIP

Your plan should drive your ultimate allocation size. Avoid constraining your plan within a smaller allocation if you could make your plan more operationally efficient with additional address space.

The IP Address Supply Chain

It’s probably a good idea to review the global allocation structure of IP addressing (Figure 6-1).

Figure 6-1. Global IP address allocation structure

The Internet Assigned Numbers Authority (IANA) is the centralized global authority that allocates all IP addresses (and AS numbers) to the Regional Internet Registries.^[89^]

There are five RIRs, correlating roughly to five of the seven continents:

§ American Registry for Internet Numbers (ARIN) for North America

§ Réseaux IP Européens Network Coordination Centre (RIPE NCC) for Europe (as well as the Middle East and parts of Central Asia)

§ Asia-Pacific Network Information Centre (APNIC) for Asia and Oceania

§ Latin American and Carribean Network Information Centre (LACNIC)

§ African Network Information Center (AFRINIC)

Each RIR in turn allocates IP address blocks to downstream ISPs — aka Local Internet Registries (or LIRs). RIRs may also allocate addresses directly to large end-user organizations. These have traditionally been large corporate and government enterprises that typically have more than one ISP providing conncetivity to the Internet. But smaller enterprises and organizations desiring better network resiliency, routing performance optimization, and always-on access to cloud services can multihome their networks as well. As a result some enterprise networks are requesting portable provider independent IPv6 address space (i.e., routable via any ISP, at least within one region) directly from their RIR.

So Where Will Your IPv6 Addresses Come From?

Well, that depends.

At its most basic, the process for getting IPv6 address space is pretty much the same as the process for getting IPv4 addresses. But you’ll need to request them from the right organization. Though it’s probably reasonable to assume you’ll be getting your IPv6 from whence came your IPv4, it’s also possible your requirements for IPv6 may differ enough from IPv4 that your best source for IPv6 address space may differ as well.

In any case, there are generally three types of organizations that will provide you with IPv6 addresses:

§ A RIR (or RIRs)

§ An ISP (or, in the lingo of the RIRs, a Local Internet Registry, i.e., LIR)

§ A department within your organization

Which of these you get your IPv6 addresses from typically depends on a few criteria, including your network and routing topology, as well as the specific addressing requirements of your organization (or department).

How Many ISPs Do You Connect To?

Asking the number of ISPs you connect to is another way of asking are you single-homed or multihomed? In other words, does your organization connect to a single ISP or more than one? The reason this is important is that organizations with multiple ISPs for redundancy must haveportable IP allocations. Portable allocations are assigned by RIRs directly to the organization. As we covered in Chapter 2, these allocations are formally referred to as provider independent (PI) and should be able to be routed, or announced, through any ISP.

An organization that is single-homed typically receives a nonportable, provider assigned (PA) assignment from an ISP. The ISP has administrative authority for the addresses they use for PA assignments. If the organization changes ISPs, they’ll have to renumber out of their old ISP’s PA assignment (and into a PA assignment from their new provider). Meanwhile, portable allocations allow an organization to keep the same addresses and internal numbering scheme, regardless of which ISP (or ISPs) they connect to.

Another advantage of PI space is that it allows an organization to maintain a highly available network via multiple providers without any manual routing changes or other special configurations. Consistent routing policy can be developed over time to influence and optimize inbound traffic in a scalable way that may be difficult or impossible where an organization is single-homed and relying on a PA allocation.

How Large Is Your Organization?

Other criteria for determining where your IPv6 address space request should go include the amount of IPv6 address space your organization may need and the amount of network growth or change you anticipate.

As we covered in the last chapter, if you’re a large enterprise, you may need as much as a /32 of address space (or more). Depending on the ISP, that could be all the space they’ve been allocated! And, of course, large enterprises are more likely to rely on multiple ISPs, making PI space a requirement.

Larger organizations are also more likely to have areas of the network that require renumbering (either through growth or change or from merger and acquisition activity), making PA space problematic.

So Why Doesn’t Everyone Just Get a PI Allocation?

From our network operator perspective, a provider independent address allocation appears more desirable than a provider assigned allocation in how it can add and insure some operational ease in the network (e.g., more flexible routing policy, reduced likelihood of having to renumber, etc). And while RIRs like ARIN have gone to great lengths to create policies that favor easier network growth and operation, giving PI space to everyone is problematic.

Remember the dilemma of scale from Chapter 1? While IPv6 creates a better balance between an individual organization’s addressing needs and keeping the global routing table small, it doesn’t eliminate the tension between these two conflicting goals entirely.

Every additional PI allocation for an organization creates at least one more entry in the ISP’s and global routing table — an entry that would otherwise be subsumed in an ISP allocation that the same organization’s PA space would be assigned from (Figure 6-2).

Figure 6-2. PA versus PI effect on routing tables

So with all that in mind, here’s a simple flowchart for determining what kind of IPv6 allocation your organization is likely to need and from whom to request it (Figure 6-3).

Figure 6-3. Determining best type and source for a new IPv6 allocation

ARIN PI REQUIREMENTS

Keep in mind that the requirements for PI IPv6 address space allocations directly to end-users (as opposed to ISPs) vary among RIRs.^[90^] For example, here are ARIN’s initial assignment requirements:

Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria:

§ Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or;

§ Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or;

§ By having a network that makes active use of a minimum of 2,000 IPv6 addresses within 12 months, or;

§ By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or;

§ By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable.

One other justification that ARIN will consider in allocating a PI prefix is if future renumbering would impact more than 2,000 individuals.

Everything You Didn’t Realize You Wanted to Know About RIR Policy

No phrase in English (or any other language for that matter) consistently fails to stir the imagination like “governance, regulation, and policy.”^[91^]

But when we’re dealing with any shared resource, as we are with IP addresses, at least a modicum of regulation is necessary. If we want continued access to address resources, we’ll need to familiarize ourselves with such regulation.

Fortunately, the RIR policy that we’ll need to know (or at least be aware of) is relatively brief and refreshingly sane.

For one thing, if you are in North America (excepting Mexico, whose number resources are handled by LACNIC), you’ll hopefully be pleased to know that the regional Internet registry ARIN has traditionally formulated its policies with the primary goal of facilitating network operations by making sure that organizations get the address resources that they need.

The bible for all things policy-related at ARIN is the Number Resource Policy Manual (NRPM).^[92^]

In it, ARIN outlines its overall principles and goals, as well as the ones specific to IPv6. Its general principles actually provide some insight into why address planning principles are what they are, as well as some hints as to what we’ll need to consider in maintaining our own address plan. (If you think about it, the RIRs have pretty big address plans they need to maintain). These principles include:

Registration

Registration helps ensure uniqueness of allocated resources. If every address block is properly registered and documented, the possibility of accidental overlapping assignments is greatly reduced, if not entirely eliminated. Additionally, registration provides a basic measure of accountability if illegal or unethical activities are originating from the networks registered to a particular party. Registration also provides a way to contact the adminstrators responsible for networks numbered into a particular registered range. This can help facilitate coordination of routing policy and troubleshooting between different organizations and autonomous systems.

Conservation

According to the ARIN NRPM, the principle of conservation “guarantees sustainability of the Internet through efficient utilization of unique number resources” and that “conservation…requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.”

NOTE

Remember our discussion of efficiency? If we were casually reading the above paragraph without the context of that discussion we might, in our habit of IPv4 thinking, conclude that ARIN is defining efficiency in a way that merely encourages the conservation of host addresses. But support of operational networks is a big part of ARIN’s DNA and their policies relating to IPv6 allocation express this. Recall also that the sustainability of the Internet is at least partly about conservation of router resources and the efficiency of the global routing table (the same is true, of course, for smaller networks). Incidentally, that’s the next principle.

Routability

ARIN also fundamentally concerns itself with whether or not the IP address prefixes it allocates will be routed in a scalable fashion. Continued access to IP address (and AS number) resources for a given assignee (allocatee?) is premised on their good faith adherence to community standards in how address prefixes are routed on the Internet.

Stewardship

This just means that ARIN will apply the above principles in administering Internet number resources. Their stated goal is “distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all.” Sometimes this goal involves trade-offs between these principles (and resulting modification of policy), but ARIN works hard to involve the community of Internet operators in these decisions with a maximum of transparency.^[93^]

It’s beyond the scope of this book to explore the differences between policies at the RIRs. I encourage you to visit the website of the registry for your region to learn more about how their specific guidelines may affect your IPv6 address request.

OUT-OF-REGION ANNOUNCEMENTS

The simplest definition of an out-of-region announcement is PI space from one of the RIRs being announced through a network egress point within the geographical region of a different RIR.

For reasons of policy, RIRs have either explicitly or implicitly discouraged this practice. It was traditionally seen as a violation of the remit that RIRs have to manage the number resources of their particular geographic region.

The policy seemed to make more sense when those number resources were limited (or exhausted) as they were in IPv4. But prohibiting out-of-region announcements results in organizations with global networks having to announce at least one prefix for each geographic region.

In another example of the shift to efficiency through aggregation not address conservation that IPv6 enables, the current policy (as least where ARIN is concerned) is to favor allowing out-of-region announcements. A global organization free to announce an ARIN allocation within other regions (as opposed to at least one prefix per region) should result in fewer global routing table entries.

You may recall that in the preface, I mentioned my own first experience with obtaining IPv6 addresses. Working for a service provider with a presence in North America, Europe, and Asia-Pacific suggested to us at the time that we would need IPv6 address space from each associated RIR.

After receiving conflicting information as to how RIR policy was likely to evolve, we decided to make sure that we had an IPv6 allocation from each RIR. It may be prudent for any organization doing business in multiple regions to secure an IPv6 allocation from each associated RIR to number into, in case the policy should change (or for maximum routing policy flexibility in case of contingencies).

Measuring IPv6 Address Consumption

At the beginning of the book, we looked at a specific example of how immaterial host address consumption is when there are 18 quintillion addresses available in the smallest subnet typically assigned. Thus, we’ve attempted to grow the definition of efficiency beyond mere address conservation to durably include broader operational concerns (e.g., minimizing routing convergence time and routing table size, increasing manageability of ACLs and security policy, increasing human-readability of IPv6 subnets, avoiding renumbering, etc.).

That said, an effective (and sanctioned) way to measure the utilization of IPv6 is something we’ll need in our tool belt. At first, it can help us determine the initial size of the allocation we’ll need. Later, we can use it to monitor utilization and plan additional assignments.

The metric often used by allocating agencies is called the Host-Density (HD) Ratio:^[94^]

This equation produces a value between 0 and 1 that is then represented as a percentage.

So that’s the formal method. But it’s simpler and easier to just remember the figure 75%. That’s the percentage of utilization threshold set by ARIN when considering if anything larger than a /56 is fully utilized. Anything smaller than a /56 is considered fully utilized immediately upon assignment. And although ARIN sets the boundary for the requirement to determine utilization at a /56, they typically allocate at least a /48 to any requesting organization.

The 75% threshold is somewhat arbitrary because it assumes that if you’re below it, you have sufficient headroom for additional growth, but if you’re above it, you’ll immediately need additional address space to accomodate growth (and avoid renumbering). Organizations that are growing quickly (such as service providers) might consider using a lower threshold value, say 60%, to provide additional space for expansion.

Determining Initial Allocation Size

Determining the size of allocation we’ll need based on the number of sites we have is the easiest way to demonstrate our 75% threshold in action.

Let’s say my enterprise is smallish and has only five sites: a headquarters office, three branch offices, and a data center.

Five sites would need at least 5 /48s. Three additional bits would provide 8 /48 subnets. So a /45 would suffice for our immediate addressing needs.

Five subnets out of an available eight puts us at 62.5% utilization, below our 75% threshold. But recall from the previous chapter that as a best practice we should dedicate an entire additional /48 for infrastructure. This takes us right up to our 75% threshold, which should trigger the next largest allocation, or a /44.^[95^]

Since a /44 has 16 /48s, any request for up to eleven sites will yield a /44 from ARIN.^[96^] Twelve sites up to the 75% threshold for the next nibble boundary, or 191 sites, would result in a /40 being allocated. Table 6-1 displays the next two increments.

Table 6-1. Allocation size per site count

It’s unlikely that any enterprise will have more than 49,151 physical (or even logical) sites so a /32 would prove sufficient in most scenarios.

So the 75% threshold is suitable as a generic guideline for measuring utilization during both the address planning and management phases.

During the planning phase, it can be used to determine if a particular prefix allocation will be sufficient for the number of subnets needed for a particular function or location. It can also be used to anticipate the allocation one is likely to receive from a RIR, based on the address plan and subsequent allocation request.

During the operational phase, it can be used as a threshold to trigger assignment of additional subnets (preferred) or renumbering (worst case). As we mentioned, the rate of subnet assignment may vary between and within organizations. If the rate of growth is slow, a higher threshold may be acceptable (e.g., 80%), whereas if it’s fast, you may want to lower it (e.g., 65%).

Many contemporary IP address management (IPAM) tools offer capacity planning features and reporting functionality that can help you track IP utilization more closely. We’ll cover IPAM technologies and best practices in Chapter 8.

Navigating the IPv6 Address Request Process

Since you’ll either be getting an IPv6 allocation from your ISP or a RIR, it’s probably a good idea to explore the process in either case a bit. Chances are you (or someone in your organization) has at least some familiarity with it already (based on the IP addresses you’ve already requested and received). As a result, you may not have to complete all the steps associated with requesting address resources.

RIR Allocation Request

We’ll need some guidelines for procedure and policy when it comes to getting IPv6 addresses from a RIR. As we’ve done for the bulk of this chapter, we’ll continue to pick on ARIN to provide these. The steps are as follows:

§ Meet the requirements for an End-User Initial Assignment

§ Register an Organizational Identifier (Org ID)

§ Register Points of Contact (POC)

§ Complete and submit an allocation request

§ Verify your request

§ Provide additional information (optional)

§ Certification of request by a company officer

§ Acknowledge request approval

§ Pay the fees

§ Sign the Registration Services Agreement

§ Receive your assignment

Please excuse a minor curmudgeonly outburst: ARIN makes this whole process as painless as possible these days by offering a handy web interface to complete the registration and request process. In my day, we had to submit everything through email. In the snow. Uphill. Both ways.

Let’s take a look at a few screen shots of the webpages from ARIN’s site associated with the most critical step, i.e., Complete and submit an allocation request. This walkthrough will be for an End-user IPv6 Request, something an enterprise that wanted PI space would make.^[97^]

First, after logging into ARIN Online, you’ll be directed to the main screen. From there, select Manage & Request Resources from the left column (Figure 6-4).

Figure 6-4. ARIN online portal start page

Next, the Number Resources page lists your POC(s) and Org-ID(s). In the Org-ID box, under Actions, click on the Request Resources link (Figure 6-5).

Figure 6-5. ARIN Number Resources page

The next page is the Resource Requests page. Under Resource Type, select End-user IPv6 Request (Figure 6-6).

Figure 6-6. ARIN Resource Requests page

From there, the End-user IPv6 Assignment Request Form page comes up (Figure 6-7).

Figure 6-7. ARIN End-user IPv6 Assignment Request Form page

The field for step 1 asks for the prefix length requested. This field allows any value from 40 to 48 (as well as Unknown/Other). Depending on your organization’s size and estimated or actual address plan requirements, it’s possible that you may want to request a prefix larger than a /40 (e.g., a /36 or /32). You’ll have an opportunity to make such a request and justify it on later screens.

The field for step 2 requires a network name. This name will be used as a text label (of up to 50 letters) for the assigned address prefix. You could choose a name that is administratively or operationally relevant if you like. Organizations often use their name along with a number corresponding to the assignment order, e.g., GLOBOCORP-IPv6-1.

The field for step 3 is optional, but requests entry of the ASN that the requested prefix will originate from. For most PI assignments, this will be the ASN of the requesting organization. More rarely, a PI request that will originate through one or more upstream ISPs could be used here.

The next page requests corporation officer info (Figure 6-8). All resource requests through ARIN require that an officer of the requesting organization attest to the accuracy of the info submitted for the request. The steps for fields 4, 5, and 6 ask for the officer’s name, title, and email address respectively.

Figure 6-8. ARIN Corporation Officer Info page

Incidentally, if you don’t already have executive or management buy-in for your IPv6 adoption initiative (as dicussed in Chapter 3), this requirement may provide an excellent excuse to line up some facetime with high-level management to make the case for the organization to adopt IPv6.

Next we proceed to the first of three justification sections (Figure 6-9) for our request.

The checkbox for step 7 asks if you’ve been issued any IPv4 addresses on or after December 22, 1997. If you’ve already received an ARIN end-user allocation of IPv4, this helps justify one for IPv6.

Step 8 asks for an optional list of upstream providers and peers. Here you may list the upstream networks that you purchase IP transit from or that you peer with at exchange points (or directly), e.g., “Level 3,” “ASN3356,” “6939,” etc.

The next page continues the justification portion of the request (Figure 6-10).

Figure 6-9. ARIN Justification page

Figure 6-10. ARIN Justification page 2

The field for step 9 asks for an IPv4 Address Utilization Numbering Topology. Yes, you read that correctly: IPv4. ARIN uses this information to help validate the IPv6 allocation request.

CAUTION

That ARIN wants to see your IPv4 address utilization and topology should not be interpreted to mean that you should be correlating your existing IPv4 address plan to your shiny new IPv6 one. The IPv6 address planning principles and best practices we’re covering in this book are better suited to creating the right plan.

Field 9 (along with field 11, covered next) is limited to 4,000 words. If you need more than that, you’ll need to upload a file using the button identified by 10 in the above graphic.

Field 11 (Figure 6-11) is arguably the most critical part of the end-user allocation request. This is where you’ll outline your proposed IPv6 numbering scheme. As mentioned, this is the part of the request process that creates a bit of a catch-22: it’s difficult to accurately gauge how much address space we’ll need without a finished plan, yet it’s equally difficult to decisively design a complete plan without knowing how much address space we’ll be starting with.

Figure 6-11. ARIN Justification, page 2 (lower half)

To best complete this field, we’ll need to make some very general assumptions based on the concepts and principles we learned in the last chapter. From these, we can build a plan outline that contains enough information to complete our RIR (or ISP request) and get our IPv6 addresses.

TIP

A plan outline is a high-level outline of a (typically) forthcoming complete and operational IPv6 address plan that is produced to qualify for, and obtain, an IPv6 allocation.

The simplest estimate on which to base our request comes from:

1. The number of sites in our organization

2. The number of subnets we’ll need per site

Recall from Table 6-1 that up to 75% of our total number of sites will dictate the allocation we receive. Keep in mind also that the 75% threshold triggers an allocation with an additional 4 bits of end-user /48 networks. As a result, for the purposes of estimating whether a particular allocation will be sufficient, our confidence in the estimate might be understood as inversely proportional to how close we get, without going over, to 75%.

For example, where our number of sites puts us greatly under the 75% mark for any of the rows in Table 6-1, we should have more confidence that our allocation will be sufficient to base our operational address plan on. But as we approach the 75% threshold, recognize that going over 75% generally means that getting the next largest allocation on the nibble boundary will give us stubstantial headroom for potential operational efficiency and growth.

The pages that follow (not shown) include the last page of the justification portion of the request (with two fields to be filled out if you’re requesting additional IPv6 space) followed by a page to enter any additional information (the same 4,000-character limit applies, but as before, there is the option to attach a file).

After submitting the request, a ticket number is generated along with a link to the support page (Figure 6-12).

You can log back in to check the status of your request at any time. ARIN typically responds to requests within a day or two.

Figure 6-12. ARIN request submitted page

ISP Allocation Request

The process for requesting an IPv6 assignment from an ISP is similar to the one for requesting an allocation from a RIR.

Since a request from an organization to an ISP for an assignment would typically be for a PA assignment, an ISP might make certain assumptions about the organization’s topology and size. In any case, the ISP will typically require you to fill out a service request form that includes information about your actual topology and IPv6 requirements, info such as:

1. Will you need an IPv6 prefix?

2. Is your network multihomed?

a. If so, what is your AS number?

b. Prefixes you plan to announce

You’ll probably be using an existing IPv4 connection and adding IPv6 to it in a dual-stack configuration. Otherwise, additional information, such as the circuit type for the IPv6 connection and any settings associated with it, will need to be clarified.

It should go without saying that you need to verify that your ISP or IP transit provider supports IPv6. If you haven’t done this yet, you should do it right away. Some organizations adopting IPv6 report difficulty ordering IPv6 connectivity because not all ISPs or IP transit providers have adopted IPv6 yet themselves. If your existing provider doesn’t support IPv6 within a timeframe acceptable to your IPv6 adoption plans, you’ll need to begin to research the requirements and costs of other providers that can provide IPv6 connectivity.

Summary

I’ve attempted in this chapter to demonstrate that getting IPv6 addresses is a perfectly straightforward process, as long as you know what type of allocation you’ll need and where to get it.

Though policies for obtaining IPv6 addresses may vary from slightly from region to region, one thing remains consistent: the bare fact of IPv4 exhaustion means that the RIRs have a vested interest in facilitating IPv6 adoption. This means that any request for IPv6 address space backed up by an address plan that has demonstrated need based on operational best practice as the requestor defines it stands a good chance of seeing that request fulfilled.

Of course, not every organization requires (or should receive) a PI allocation. Organizations with a single ISP or limited to one site may conclude that a PA allocation is perfectly suitable for their current and future operational needs and rate of growth.^[98^]

^[89^] They’re also responsible for coordinating a number of other foundational Internet technologies, including the DNS Root, .int and .arpa domains, and protocol number assignments.

^[90^] RIPE recently eliminated the multihoming requirement for assignment of PI space to organizations. In order to obtain address space directly, a larger enterprise may also choose to become a LIR itself (by becoming a member of RIPE and paying the associated fees).

^[91^] If your imagination is stirred by the phrase, I humbly beg your pardon and offer my regrets that I won’t be able to attend your next get-together.

^[92^] Each RIR has its own equivalent of the NRPM available through its website.

^[93^] Participation in ARIN policy discussions through their Public Policy Mailing List (PPML) is open to anyone. It’s a great way to get involved in the Internet community (and an equally great way to obliquely learn about the operational concerns around address resources that impact network administrators).

^[94^] See RFC 3194, The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio.

^[95^] Since ARIN only allocates along nibble boundaries as a matter of policy, this is the allocation we would have received anyway!

^[96^] Chances are if you’re only requesting IPv6 address space for a single site, you’ll be getting an allocation from your ISP.

^[97^] If you’re making a request from ARIN for an ISP allocation, the process is similar. Where possible, modify the screen selections accordingly.

^[98^] Some single-homed organizations may be concerned about a greater likelihood of having to renumber. This could be a consequence of changing ISPs or the frequent internal reconfiguration of the network. With such a concern, the deployment of ULA with NPTv6 (a configuration that is less desirable for most networks due to greater operational overhead than GUA) may be an option.