IPv6 Unicast Address Allocation

Continuing in Chapter 2 of “Deploying IPv6 Networks” (Cisco Press, 2005)

In my last post, I provided an overview of IPv6 unicast addressing, which includes link-local addresses (LLAs), unique-local addresses (ULAs), and global unique addresses (GUAs). As previously described, GUAs must be globally unique and globally routable. GUA addresses are identified with the 3 high-order bits set to ‘001’ (2000::/3) with addresses ranging from 2000::/4 to 3000::/4.

In this post, we will dive a bit deeper on GUAs address allocation policies. Strong IPv6 address allocation and prefix aggregation policies must be implemented and enforced to prevent impact to routing process through longer lookups (remember that modern 64-bit processors require 4 cycles to process IPv6 SA and DA addresses, compared to 1 cycle for IPv4 addresses), reduce global routing table size (which is already becoming a problem with IPv4), and larger routing updates between peers because many more networks are possible with the increased addressing space.

Therefore, strong IPv6 allocation and prefix aggregation policies are meant to provide efficiencies by reducing the global routing table size and keeping routing updates to a manageable size. Cost of routing hardware also likely plays a large part in this equation, since routers with enough horsepower and memory to handle IPv6 routing updates and lookups without strong aggregation policies would come at such a huge cost that it would prohibit IPv6 adoption.

The IANA is responsible for managing and allocating the global IPv6 address space. Address allocation is strictly hierarchical from the IANA to Regional Internet Registries (RIRs), and subsequently to National Internet Registries (NIRs), Internet Service Providers (ISPs) or Local Internet Registries (LIRs), and finally individual organizations. At each step in allocation the larger address space is assigned in subsequently smaller pieces to customers. This allows hierarchical routing and prefix aggregation, which significantly reduces the size of the global routing table.

IPv6 Prefix Allocation Process

In Figure 1, you can see an example of this allocation process for the 2001::/3 prefix. The IANA allocates pieces of this prefix to RIRs and NIRs anywhere in size from /3 to /32 (however, it is typically /16 to /22 in size). These blocks are then subdivided and allocated to ISP and LIR customers, ranging in size from /32 to /35. Finally, individual organizations are allocated one or more /48 prefixes. This leaves 16-bits for use within the organization for internal subnetting and network design.

Using this allocation policy provides prefix aggregation capability at each organizational boundary (Organization, ISP, LIR, NIR, RIR, IANA). ISPs and LIRs must also allocate addresses to customers in a manner that prevents segmentation and allows for optimal use of aggregation (using the Host Density ratio defined in RFC 3194).

A complete list of IPv6 allocations by the IANA is available at the following link:

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml

Such strict allocation and aggregation practices don’t come without detractions, however. Individual organizations no longer own their own address space directly from the RIRs (as they do with IPv4 prefixes today). Instead, IPv6 prefixes are acquired from specific ISPs or LIRs and represent a subset of their larger address allocation. Therefore, organizations will need to renumber their entire network when switching between ISPs. IPv6 does include features that make renumbering easier, but this results in an operational impact to organizations.

Renumbering can be made simpler by assigning multiple unique unicast addresses to each host interface during the transition period between ISPs, where both address spaces coexist within the organization. Additionally, the use of unique-local addressing (ULAs) within the organization can ensure internal communication is not disrupted during an ISP transition. However, IPv6 renumbering is still a major concern for medium-to-large size organizations.

Cheers,

Andrew

P.S. – Please follow or get involved in the discussion on IPv6 architecture, design, and implementation on Twitter with the #IPv6Mission hashtag.