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:

  1. Separate address block for infrastructure from other uses (enterprise, loopbacks)
  2. Each individual site should receive plenty of subnets, such as between a /48 and /56. See RFC 6177.
  3. Summary aggregates for groups of sites where it makes sense, but watch your HD ratio
  4. 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.
  5. Each PoP is a site therefore assign a /48 for infrastructure
  6. No subnets will use prefixes longer than /64.
  7. Separate address block for router loop-back interfaces
  8. Assign a /64 per LAN / VLAN / subnet
  9. 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:
  10. IETF expects that you will assign a /64 for point-to-point links
  11. 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.
  12. All customers get one /48 unless they can show that they need more than 65k subnets.
  13. Expect the registry to allocate a /32 and reserve one /32
  14. If you need private addresses, generate a ULA prefix as defined in RFC 4193

Specific Situations

  1. Point-to-point links may be assigned a /126 prefix if there is written assurance that the drawbacks documented in RFC 3627 will not occur.

RFC 5375

Five people have written RFC 5375 for the IETF's v6ops working group. It has a lot of detail.

The following is an excerpt from RFC 5375, section 2.4:

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:

  1. Autoconfigured hosts possible? /64
  2. Autoconfigured hosts not-possible, we control both sides? /126
  3. Autoconfigured hosts not-possible, we DON'T control both sides? /64
  4. Loopback? /128

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

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.