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:
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 www.cisco.com/go/ipv6
P.S. Cisco is participating in the upcoming June 6, 2012 World IPv6 Day. Are you participating, too? If not, what are your concerns?