IPv6 Addressing Plan Design for Service Providers [Archived]

By Ryan McCann

Clearcable IPv6 Case Study

Clearcable has been involved with IPv6 since the early 2000s when commercial products began to emerge. In the early days, it was nothing more than testing, experimentation and lab use; however, by 2008, we had set out on a campaign to start educating our service provider clients on IPv6 and need to start implementing IPv6.Convincing them was a difficult task, and we did not make much headway; however, there were a handful of service providers where we had the necessary approvals to proceed. We began by having each client ISP register their own /32 direct allocation from ARIN (the standard ISP allocation), and then we configured IPv6 for each client ISP in their core networks. This often meant firmware upgrades, and back then if we were able to get a BGP transit peer we did, or via IXP members that also had IPv6 and/or tunnels with Hurricane Electric.

In 2010, we launched our SOE4 private cloud platform and it was designed from day one to support IPv6. When possible, as those platforms were rolled out, we ran HE tunnels for IPv6 access and as more and more service providers obtained native IPv6, we migrated the server platforms over to native IPv6.

It was also in 2010 that I presented at our annual Clearcable Technology Summit about IPv6, covering the background, driving forces, and how to. This spurred on some additional interest, but it wasn’t nearly enough. We continued promoting IPv6 in collaboration with industry organizations and vendors since then, and we also developed implementation strategies, use-cases, and supporting infrastructure such as our IPv6 transitional appliance for DNS64 and NAT64 services.

We also knew that we had to design a standardized and sensible IPv6 addressing plan to help aid service providers in the deployment of IPv6. We built two tracks, one for service providers and another for content providers/enterprises.  Our main goal with respect to addressing was to provide a framework that helped automate address administration and minimize future renumbering.

The key concepts;

• Simple and Sensible

• Maintain nibble boundaries whenever possible

• Maintain largest possible aggregates for routing specs and security ACLs

• Provisioning of new addresses derives from existing system properties

• Minimize future renumbering

As part of our IPv6 address plan design we developed a standard access technology map for our small to mid-tier service providers, outlined below:Looking specifically at DOCSIS as an example, we have a /34 reserved. From this /34 we allocate a /36 for a region or PoP site and then assign individual /40’s to each DOCSIS CMTS (16 total for a /36). If we need more access technology selectors we increase the number of significant bits in front. If we need more devices within a single access technology, we extend the netmask to combinations such as “A (1010)” in DOCSIS. So now both “8” and “A” mean a DOCSIS CMTS, but they are still able to aggregate under a /34 (i.e. we do not have to enumerate two separate /36 blocks).

We also developed standardized end user assignments;

• /56 = Residential/SMB

• /48 = Content Provider/Enterprise

• /64 = Service Provider infrastructure

• /64 = Technology independent

• /128 = Loopback

From a residential user perspective, a /56 block is roughly equivalent to an IPv4 /20, with 8-bits of usable addressing space which equals 256 LANs. Typically only network 00 will be used, for example 2001:db8:1234:5600:020c:29ff:fe0c:47d5/64 however more advanced setups will use 01, 02, etc. with one /64 per interface such as, 1000BASE-T, WiFi, security, IPTV, etc.

Sample delegation schemes are below;

2001:0db8:8034:5600::/56

• 0x8 = DOCSIS

• 0x0=CMTS#1

• Residential Subscriber ID=0x3456

2001:0db8:4034:5600::/56

• 0x4 = GPON

• 0x03 = OLT#4

• Residential Subscriber ID=0x456

In the case of a VLAN based deployment, the VLAN Identifier (VID) is 12-bits long and we map the VID (in hexadecimal) to the low 3 nibbles reserving 0 in the high nibble to designate VLAN mapping is being used.  For example :0678: where 0x0 indicates VLAN style mapping and 0x678 represents VLAN 1656 (decimal).  An example VLAN based deployment for service provider infrastructure would be 2001:0db8:0000:0678::/64 where “0000” represents internal infrastructure and the VLAN ID is 0x678 = 1656.

Beyond the standardized technology map and end user assignments, two other important design decisions in our address planning were to use sparse based allocations and to follow RFC 3531 for Flexible Bit Assignment.  This allows us to defer fixing the position of network boundaries as long as possible to keep aggregates large. Bits are allocated from the left in the left field when making sequential assignments, for example, 0b0000, 0b1000, 0b0100, 0b1100. This allows us to grow either the number of routers or the number of networks when required. R00N: can become :RRRN: or :RRNN: or :RNNN:, as an example.

We have also built into our IPv6 addressing plan provisions for link-local, multicast, NAT64, loopback, point-point and other special addresses.

Additional best practice considerations are below,

• Follow RFC 5952 for address representation

• Prefer SLAAC for address synthesis

• Sparse allocation accommodates growth

• Use a consistent generic delegation schemas

• Use RFC 3531 to delay subnetting decisions

• Recognize the purpose of special addresses

In summary, no matter what IPv6 addressing plan is decided upon, the key is to have one and that it be well defined in advance, shared with all key stakeholders (including training), and then followed.

Industry organizations like ARIN, the Internet Society, and others have been instrumental along with many content providers such as Google and Facebook in advancing IPv6. Over the past few years we have finally seen service providers take IPv6 seriously, and now 10 years after we began our push for IPv6 adoption, nearly all our service provider clients have IPv6 deployed to some extent with active plans for continued advancement of their IPv6 implementations.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.