With interest in IPv6 accelerating and adoption heating up more attention is being paid to address planning, but where do you start?
Organizations should already be working toward securing an adequately sized address block. You want to move quickly to avoid the possibility of demand exceeding the capacity of Regional Internet Registries and Service Provider's ability to service these requests quickly. If it turns into a land grab as some predict, you want to be ahead of the pack.
Provider Independent (PI) public ranges are attractive for internal enterprise deployments to avoid the complexities of overlapping private network ranges, something all too common in IPv4 with mergers and acquisitions. Advertising IPv6 routes externally on the Internet may require a different addressing strategy. But how do you know how much addressing you need and how do you begin creating an address plan? This article suggests some considerations for global unicast address planning internal to the enterprise.
QUIZ: How prepared are you for IPv6?
There is a great deal of custom design and sizing work in IPv4, consuming organizational resources that could best be used elsewhere. Sizing work often includes defining major blocks for geographic regions or services and applications, identifying site or service boundaries, and provisioning networks.
If you guess wrong, you might have a painful and expensive readdressing exercise in your future. As a consequence, network designers sometimes guess high to avoid these concerns but this leads to wasted space. If you guess too low it may lead to fragmentation and limit route aggregation potential. In IPv4 it is a balancing act with space conservation being a top priority. Many of these barriers are lifted in IPv6, assuming of course you are successful in acquiring an adequately sized address block for your organization. Size does matter.
Your IPv6 migration project hopefully begins with a structured engineering approach and documented requirements. A priority at this stage is to reduce or eliminate the need for time-consuming custom design work. Think in terms of standardization, from the regional blocks and services or applications, to site sizes, how sites are allocated, and even how to address hosts within each network.
Standardization may be viable at every level, something simply not possible for large organizations in IPv4. The result not only reduces engineering efforts and the burden of registrations and management, but can also open new opportunities for replication and automation while facilitating provisioning in dense virtual environments. Standardize, automate, provision.
Standardization of geographic regional blocks, services, or applications results from decisions about site size, the number of sites required, and space reserved for future requirements. Site sizes may be standardized assuming some tolerance for wasted space. Again, while space conservation is a prime concern in IPv4, the balance in IPv6 may tip toward new opportunities at the expense of some acceptable level of waste.
The 128 bit hexadecimal address format in IPv6 can be intimidating to the uninitiated. Anything that can be done to reduce this concern should pay big dividends. Standard site sizes can help. Specifically, consider standardizing on a major bit boundary such as /48, /52, /56, /60, etc., or larger if your organization requires it and you've secured a nice sized block.
Site boundary addressing now becomes much simpler for humans to understand and greatly reduces the risk of configuration and registration errors. Consider further standardization within sites. Is it possible to apply a generic configuration template to all or most sites? Can you define where loopback interfaces, WAN links, user segments, etc. are provisioned in a consistent manner, or should you?
Finally, within a standard /64 network it may be possible to consistently address network infrastructure and hosts. There is plenty of room to work with here so you should have no problems getting creative while keeping the math simple.
You'll need to determine if using Stateless Address Autoconfiguration (SLAAC) is appropriate in your instance, if not you may be able to define a standard approach to addressing network infrastructure, static host addresses, and DHCPv6 pools. Or, have a standard template defined for combined manual and DHCPv6 addressing when SLAAC is not prescribed and gain the flexibility of both options. Any attempt to standardize /64 prefix definitions should also observe major bit boundaries or major address blocks on the same bit. Simplify the math for success.
Caution is due here if you are tempted to define smaller prefixes to conserve space. This idea is a carryover from the IPv4 experience and you should give careful consideration to straying from the /64 prefix standard. Besides adopting a non-standard approach, the math becomes very unruly. I would encourage you instead to stick with the standard and use the additional space to your advantage.
Each IT organization is different and must design an addressing strategy and policies to meet their unique requirements. The concepts here are only a partial list of things to consider when designing an address plan. The key is to consider the lessons learned from your legacy address plans then look for new opportunities that could prove very liberating.
Zawacki is a senior principal network engineer at Oracle with the primary responsibility of internal global routing architectures. He has been in networking for 25 years and is a member of several industry advisory boards.
Read more about lan and wan in Network World's LAN & WAN section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.