This page is for developing a best practice guide to IPv6 addressing plans for an ISP allocation. These are the allocations that are a /32 prefix or shorter. To some extent, a company that receives a /20 or /22 will be doing some things a bit differently due to scale, nevertheless, the same principles apply to developing the plan.

Where possible, a guideline should give its rationale and reference any supporting documentation.

Discussion can occur within the comments section below. In some cases, where there is no clear consensus on some aspect of the guidelines, we will post both positions on this page and copy the discussion material to a separate background page that focuses on the one issue.

General Guidelines

Template:Alertbox|Draft document!|Although this document contains input from several people including discussions on the NANOG list, it is not necessarily the last word in IPv6 addressing plans. If you have suggestions for improvement, please post it to the discussion page (see the tab above). There are several approaches to an "optimal" plan, but one website follows RFC 3531 and a book's perspective.

Additional points:

Separate address block for infrastructure from other uses (enterprise, loopbacks)

May mean two /48s per PoP

Document so that you can justify it in your Host Density ratio

Each individual site should receive plenty of subnets, such as between a /48 and /56. See RFC 6177.

Summary aggregates for groups of sites where it makes sense, but watch your HD ratio

Any prefixes shorter than /48 will only be assigned when there is written justification to show that this prefix will meet the RIR HD ratio guidelines within 5 years.

Each PoP is a site therefore assign a /48 for infrastructure

No subnets will use prefixes longer than /64.

Separate address block for router loop-back interfaces

Generally number all loopbacks out of one /64

/128 per loopback

Note that this recommendation violates RFC 4291 - "IP Version 6 Addressing Architecture", which states that for addresses with other than binary 000 as their first 3 bits, the Interface Identifier must be 64 bits long. It isn't really necessary to save IPv6 address space by using /128s on loopbacks. For example, out of a /48, if you allowed for 16384 /64s for loopbacks, you'd still have 49 152 subnets left for links. If your network is big enough that that sort of addressing plan is not going to be large enough, then you probably won't have any issues with getting multiple /48s e.g. a /47 or /46.

Assign a /64 per LAN / VLAN / subnet

Organizations with multiple /48 allocations should consider enterprise-wise aggregation levels of /60 or larger blocks for the administration of enterprise policies for common functions such as:

DMZ

Realtime traffic, such as voice & video

Network loopback addresses and Link space

IETF expects that you will assign a /64 for point-to-point links

Fewer typos because all subnets are the same size

You can use longer prefixes but what's the point?

/126 will break Mobile IPv6 Home Agent discovery

/112 leaves final 16 bits free for Node IDs

Use /64 unless you have read and understand RFC 3627

Note: on pure point-to-point links (e.g., SONET) anything shorter than /127 is vulnerable to ping-pong packet amplification as described in Maz's APNIC 26 presentation. (On Ethernet, this is at most a neighbor cache DoS)

The enterprise network should receive a prefix sufficient to provide a /48 allocation for each site (office/campus/PoP) at which the company has employees or systems.

All customers get one /48 unless they can show that they need more than 65k subnets.

Host count is irrelevant.

Do not assign to customers from PoP aggregates

Define aggregate areas which contain several PoPs

Carry customer networks in iBGP

Aggregate only in eBGP

If you have lots of consumer customers you may want to assign /56s to private residence sites.

Expect the registry to allocate a /32 and reserve one /32

Plan for the time when you get a second allocation giving you a /31 aggregate.

If you get more than /32 first time round, ask the RIR how much is reserved so you can plan appropriately.

If you need private addresses, generate a ULA prefix as defined in RFC 4193

RFC 5375

IPv6 provides network administrators with a significantly larger address space, enabling them to be very creative in how they can define logical and practical address plans. The subnetting of assigned prefixes can be done based on various logical schemes that involve factors such as: o Using existing systems

translate the existing subnet number into IPv6 subnet id

translate the VLAN id into IPv6 subnet id o Rethink

allocate according to your need o Aggregation

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

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.

The above draft has a lot more on designing addressing plans including some detailed case studies in an appendix.

NANOG Postings

Bill Herrin

Bill Herrin posted the following explanation of aggregation on the NANOG mailing list.

If I remember right, this came from a discussion on the ARIN PPML list. I don't clearly remember the discussion, so my apologies in advance if I get some of it wrong.

During discussion and analysis, allocation of addresses by POP was found to be incompatible with a couple goals deemed more important. The general consensus was that you should establish areas consisting of multiple POPs and aggregate by area instead. However, ARIN is not in the business of recommending routing best practices so the recommendation was narrowed to just "don't aggregate by POP" meaning "don't fine-tune your aggregation all the way down to the POP level; stop somewhere above it."

The first problem with aggregating by POP was customer mobility. When a customer moves from the suburbs 10 miles east of the city to the suburbs 10 miles west of the city, he should keep his addresses and that shouldn't cause you any hardship. If your aggregation area includes the city and its suburbs, that's no problem for you. If you've aggregated by the CO where their DSL connects to, then over time as customers migrate around the city you'll end up with an awful mess.

Another problem was that there is a temptation to implement security features at the aggregation points. For example, you might put your egress source address filtering and spoofing protection there to catch anything where you couldn't for whatever reason filter directly on the customer link. If the aggregation point covers a large area, there are a very small number of customer movements for which that will be a problem. If its a single POP you end up screwing a lot of customers. A canonical example of this sort of error is Verizon Business's Ashburn data center. Customers of the data center can't leave the building and keep their IP addresses. Verizon Business (UUnet/MCI) can't attach them anywhere else on the network.

Another problem was DOS attacks. If someone DOSes a network that has moved since its inception then it'll first take out the specific route, then take out the covering route. If you've aggregated by area, there's a good chance the covering route is far enough upstream to handle the DOS. If the covering route is an alternate POP, it probably doesn't so you've allowed the attacker to crush two POPs with one DOS.

Another problem was sparse allocation. Sparse allocation for IPv6 addresses is strongly recommended. If allocated address blocks are not adjacent to each other then when a customer says, "I need more addresses," there is a strong probability that you can grant the request by simply changing the prefix length. This keeps your routing table small and tidy. You get lots and lots of IPv6 addresses, so if you only break them up into a dozen pools you still have plenty with which to do sparse allocation. If you break them up into pools for each of the hundreds or even thousands of POPs that you have and/or create two levels of aggregation (first by POP, second by area), you won't have enough to do effective sparse allocation.

There were other points disfavoring aggregation by POP but I can't remember what they were. I think there was also an assumption that traditional dynamic-IP customers would not each get a static block of IPv6 addresses. If that fails to hold true then it changes the character of the aggregation problem.

Ryan Harden

Ryan Harden posted this to the NANOG mailing list:

Our numbering plan is this:

Autoconfigured hosts possible? /64

Autoconfigured hosts not-possible, we control both sides? /126

Autoconfigured hosts not-possible, we DON'T control both sides? /64

Loopback? /128

Within our /48 we've carved it into (4) /50s.

First, Infrastructure. This makes ACLs cake.

Within this /50 are smaller allocations for /126s and /128s and /64s.

Second, User Subnets (16k /64s available)

All non-infrastructure subnets are assigned from this pool.

Third, Reserved.

Fourth, Reserved.

We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc.

Matthew Petach

Matthew Petach said on the NANOG list:

As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link.

It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat.

1 Comment

Archived "Talk" page content migrated from previous wiki:

"Any prefixes shorter than /48 will only be assigned when there is written justification to show that this prefix will meet the RIR HD ratio guidelines within 5 years."

There is nothing in the NRPM (that I could find) that requires an organization to meet the RIR HD ratio within 5 years. The policy only says that justification must be documented and evaluated by the RIR.

From the NRPM on assigning larger than /48:

"6.5.4.2. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.

Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future."

The only reference to "5 years" I could find in the NRPM is when assigning a /56.

The following guidelines may be useful (but they are only guidelines):

* /64 when it is known that one and only one subnet is needed
* /56 for small sites, those expected to need only a few subnets over the next 5 years.
* /48 for larger sites

Contents

This was intended to be a strawman proposal

I was really hoping that more people would register for the wiki and explain how and why they are designing their addressing plans. This has little to do with the NRPM and the 5 years was something that might (or might not) be a good idea. I think that every ISP should have some expectation on when they will need to go back for an additional IPv6 allocation. In the text that was quoted, I was assuming that the ISP had a plan to go back to ARIN in about 5 years, and therefore had an internal target to be in compliance with ARIN's HD ratio rules by that point in time.

8. Assign a /64 per LAN

For clarity, this should be reworded to include VLANs and / or subnets

Section 12

In section 12, there is the point:

Do not assign from PoP aggregates

I suspect that this is less specific than what was originally intended, especially since earlier points specifically recommend the creation of PoP aggregates. One point even suggests that a PoP have two aggregates: one for infrastructure addressing (i.e., loopbacks) and another for customer space. Regardless, the use of PoP aggregates should be strongly encouraged. Very shortly, we will be coming up to a point where networks will reach a scale that requires the deployment of multiple levels of link state IGPs. To not be able to aggregate the infrastructure routes (or the customer routes associated with the PoP) would seriously impact IGP scalability.