Integrating IPv6 Into Your Network: Five Steps for Building Your IPv6 Address Plan

May 2, 2012 - 5 Comments

When I was younger and faced with a large problem, I tended to shy away from the problem and take other paths to avoid the issue in the hope that the issue either got smaller or ideally went away.  I’m finding that as an adult, you cannot always do that.  Some issues just will not go away no matter how hard you try to avoid them or how creative your excuses get for why they are not important right now.

Integrating IPv6 into your network is one of those issues.  It is a large problem that impacts all areas of what goes on in the IT shop – network, security, applications, content, operating systems, etc.  The key to making an integration successful is to make sure that representatives from all IT organizations participate and contribute to the project and to approach the problem by breaking it into manageable chunks.

Step 1: Don’t panic. Moving from 32 bits to 128 bits is no small undertaking and it can be viewed as somewhat overwhelming because of the sheer size of the address space.  The first step in the process is to minimize the panic.  There are resources available to help you develop your address plan.  I’ll discuss a few considerations here but you can get more information in the Cisco Smart Business Architecture IPv6 Addressing Guide

Step 2: “Just say no” to legacy plans. One of the more interesting aspects when developing an IPv6 address plan is that you are not constrained by anyone else’s “creative” address plan.  You are not inheriting a legacy address plan implementation that just kind of grew without any thought or rationale.  IPv6 address planning is a chance to apply all the knowledge and experiences that have been hard earned over the last 20+ years of IPv4 address planning.

Step 3: Get an IPv6 prefix. There are two choices when getting an IPv6 address prefix:

  • Provider Assigned (PA)
  • Provider Independent (PI)

In the PA model, your ISP will give you a prefix for your use.  In the PI model, you will go to a regional registry that will assign a prefix for your use.  Which model you choose is somewhat dependent on your requirements.  The current trend shows most organizations are choosing the PI model.

Step 4: Decide how to break it up. So now you have a prefix. The next step is to decide how to break it up. The first temptation might be to try and embed your current IPv4 plan into your IPv6 plan. But, do not let confusion and inefficiencies creep into your IPv6 plan! It is not worth your time to try and figure out how to wedge your IPv4 plan into your IPv6 plan. You should, instead, look for places in the network that can serve as points to summarize information to allow your routing protocol to scale. But do not let a strict hierarchy model drive your plan. Consider organizational and services prefixes that might break up some of the strict hierarchy but allow for greater operational efficiency.

Example: Your organization has chosen to use PI space and receives 2001:db8:1::/48 from the regional registry. Your prefix can be broken down as shown in the figure below:

IPv6 Addressing

This scheme allows for 16 regions with each region having 16 sites. Keep in mind here that you could contiguously assign blocks to a region to add more sites to a region if needed. Each site then has the ability identify 16 functional prefixes with each functional prefix supporting 16 subnets. An example of a functional prefix would be workstations, servers, wireless, and voice subnets. In this example, the address can convey the location and function of the address which can streamline some operational processes. It is highly likely that your organization will get a much larger prefix, but hopefully this illustrates some of the discussed concepts.

What about assigning addresses to end systems? That process should be much easier with the ability for end systems to automatically learn the subnet prefix and self assign an address, right? It depends on what you are trying to do. The Stateless Address Auto-Configuration (SLAAC) is certainly available and does make the end system address assignment process very easy.  The concern that pops up is how to manage that process (for example, Who is connecting to the network? Are they supposed to be connecting to the network?) With the SLAAC model, there is no centralized control process for address management. Other methods of end system address assignment would be DHCPv6 or manual assignment for critical resources such as routers, switches, and servers. Which method to use will depend on the requirements for that particular segment.

Step 5: Decide how to manage the address space. Gone are the days when the address plan can be conveniently managed and maintained with a spreadsheet. With the expansion of the address space from 32 bits to 128 bits the number of IPv6 addresses and the number of IPv6 prefixes has greatly increased. Any wide scale implementation of IPv6 must include an IP Address Management (IPAM ) tool. This tool can help manage and maintain the IPv6 address space and can also consolidate the management of DNS and DHCP services.

If you’ve made it this far, hopefully you can see that the address planning process is pretty straight forward and analogous to how you are managing your IPv4 address space. You can take all that hard earned experience from the IPv4 address planning and apply it to the greenfield environment that is your IPv6 address plan.  Good luck!

To learn more, visit


P.S. Cisco is participating in the upcoming June 6, 2012 World IPv6 Day. Are you participating, too? If not, what are your concerns?


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Hi there! I could have sworn I’ve been to this web site before but after looking at a few of the posts I realized it’s new to me. Nonetheless, I’m definitely pleased I stumbled upon it and I’ll be bookmarking it and checking back regularly!

  2. Hi,

    – Could you make a post talking about Unique local IPv6 unicast address ?
    Most enterprise currently use RFC1918 IPs internaly and have some nat or proxy to go out with PI or PA address.

    What to do with IPv6 ? As most internal device will only use Internet via a proxy, it makes more sens to me to use unique local IPv6 unicast address.
    But then if there is an exeption to do how to deal with it as it’s seems that natting a unique local IPv6 unicast address to a global unicast addresses is not a solution ?
    I did not find best practice about internal enterprise addressing (I mean big one which could even have many internet endpoints)

    – Could you also make a post talking about link local address ?
    Let say you provider install a CE equipement and you connect a firewall to it. Then your firewall has internal interfaces with many IPv6 network.
    What would be the best addressing practice between the firewall and the CE ? From might point of view link local address can do the job so there is no need to use a subnet of the of PI/PA address space for the interconnexion but I don’t find best practices about that.
    Then what would be better, autoconf or static ips ?
    (autoconf seems ok to me if routing protocol are used)

    • JB,

      These topics are also areas to consider when developing your IPv6 address plan and they do come up quite often in the initial planning process. As you mention the Unique Local Address (ULA) space defined in RFC 4193 is intended for private internal usage and shares some similarities with the RFC 1918 defined IPv4 address space. ULA space can be used exclusively to address the entire internal organization. With the recent establishment of Network Prefix Translation (aka NPTv6 – RFC 6296), a translation boundary can be defined to allow communication beyond internal organizational boundaries. Keep in mind here that NPTv6 is not the same as NAT. NPTv6 provides a stateless 1:1 translation mechanism and does not work like the NAT44 that is widely deployed today.

      A mixture of ULA space and global addresses can also be used. In this case, source address selection can be used to allow for external communications (i.e. internal to internal uses ULA and internal to external uses global address). Source address selection has not proven to be very reliable. This issue is likely to get worked out over time, but right now depending on it in a production network could be a challenge.

      The current recommended approach for IPv6 addresses is to use global address space to avoid some of the issues mentioned above.

      The second issue that you bring up related to PE-CE link addressing is also an interesting area of discussion and can be broadened out to network infrastructure addressing as a whole. Please review the following IETF draft for a proposal regarding link local only addressing – This model is also not very popular due to some of the operational issues that can come up (e.g. ping, traceroute).

      The recommendation for the PE-CE link is the same as above – use global IPv6 addresses. When configuring network infrastructure, the recommendation is to use static addresses so there is no dependencies on HW tied to the address (e.g. EUI-64).

      In addition to the IPv6 addressing guide mentioned in the initial post, we do have another doc that discusses IPv6 address planning. It can be found at the link below. We are in the process of updating/merging them and that doc should be out shortly.


  3. Readers may be interested in an IPv6 subnetting overview I authored in 2011.