Build the Next-Generation Data Center
6 week online course starting in spring 2017

How Do I Start My IPv6 Addressing Plan?

One of my readers was reading the Preparing an IPv6 Addressing Plan document on RIPE web site, and found that the document proposes two approaches to IPv6 addressing: encode location in high-order bits and subnet type in low-order bits (the traditional approach) or encode subnet type in high-order bits and location in low-order bits (totally counter intuitive to most networking engineers). His obvious question was: “Is anyone using type-first addressing in production network?”

Terastream project seems to be using service-first format; if you’re doing something similar, please leave a comment!

Wait, what?

The traditional approach to devising an IPv[46] addressing plan goes along these lines:

  • Get your own address space (or use RFC 1918 address space);
  • Assign a prefix to every site. In IPv6 world it’s possible to use fixed-length prefixes regardless of site size – if you get a /32 prefix for an enterprise network it’s pretty comfy giving each site a /48, and even a large site might not have more than 64K subnets (the number of /64 prefixes in a /48 prefix);
  • Assign each segment within a site a subnet (or a /64 prefix in IPv6 world) within the site prefix.

This is what the RIPE document calls “Location First” addressing. Well known, used in almost all networks, and easy to summarize.

The alternative approach (called Type First in RIPE document) assigns a few highest bits within your address space to subnet type, and then assigns a type-specific prefix to every site. Segments of that type are then numbered from the address space of the type-specific site prefix.

The Type First approach obviously messes up per-site summarization (each site needs N prefixes – one per type – in the enterprise WAN routing table). The only reason one would want to use this approach is to simplify security policy enforcement – it’s easy to match traffic belonging to a security zone by matching on high-order bits.

The Type First approach is another wonderful example of MacGyver approach to networking. Instead of yelling at vendors who cannot match IPv6 addresses with discontiguous don’t care bits (like we could do in IPv4) and voting with our wallets we’re considering revamping addressing plans to work around vendor limitations.

Does It Matter?

Frankly, it doesn’t. Unless you’re using broken data center switches that only support 1K IPv6 routes and insert all WAN routes into the data center routing domain, it doesn’t matter too much how many IPv6 prefixes you have in your enterprise WAN routing table (OSPF’s route computation time depends primarily on the number of routers, not prefixes).

In any case, as Ron Broersma (one of the few true IPv6 deployment veterans) usually says in his IPv6 presentations, “Don’t spend too much time on your IPv6 addressing plan. You’ll inevitably get it wrong the first few times” … and renumbering an IPv6 network is not such a big deal if you’re using a templating tool to generate your ACLs and object groups in your firewall rules.

More information

Before starting your IPv6 address planning exercise, you (RFC 2119) MUST read the fantastic document written by Enno Rey and you SHOULD read all they have to say on IPv6 anyway.

Also, check out the IPv6 resources page on – you might find what you’re looking for in one of the IPv6 webinars, or discover that what you really need is an on-site IPv6 workshop.


  1. My rules of thumb:

    If the routing and firewalling between the VRFs (the different subnets in the WAN sites) is happening centralized in the data centers (since most of the traffic is northbound anyway), then I'd use Type First addressing = one big subnet/supernet for each VRF, summarized in the WAN edge. This is how my customer implementations usually work (currently in IPv4-only world).

    If the routing and firewalling between the VRFs is happening locally in each site, then I would consider using Location First addressing.

    Wildcard-style masking with IPv6 addresses would be great, yes!

  2. We actually use type-first addressing, for the reason you mentioned: simplified security enforcement. Our firewall up until very recently couldn't do discontiguous wildcards for IPv4 or IPv6, so using location-first would've been way more complexity than needed. Not sure about our shiny new ASA, but it's not really relevant anymore cause we've got this now and it works just fine. We have maybe 20 different subnet types ("security zones") and 30 sites, so routing table size was never really a concern (especially since most sites are stubs).

    When I implemented IPv6 two years ago (I think, time flies...) I applied the same structure directly to IPv6 (with hex instead of base 10) and to me it's just pretty =)

    For example, zone 10 (administrative clients):
    IPv6 2001:db8:123:0a[site-in-hex]::/64

    Zone 110 (VoIP):
    IPv6 2001:db8:123:6e[site-in-hex]::/64

  3. Ivan,

    Very excited to see you cover my favorite IPv6 topic (shameless book plug: IPv6 Address Planning, O'Reilly) with your usual high level of expertise and practical guidance!

    A couple of considerations perhaps of value to your enterprise readers:

    I’ve run into many enterprise administrators who will default to considering the use of ULA space internally, i.e., the private/RFC 1918 equivalent, in IPv6 along with NAT66 at the enterprise perimeter. The reason typically given for this is a combination of “that’s how we do it in IPv4” along with some variation on the “security through obscurity” argument stemming from a general discomfort for using “public” (GUA) addresses internally. But there’s really no valid security reason for this configuration.

    Also, most enterprises should consider getting a Provider Independent (PI) allocation from their RIR (the requirements vary from region to region). Having a portable allocation can help avoid unnecessary renumbering.



    1. A few more blog posts on that topic (now that you mention it ;)


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.