How to Plan Routing for IPv6

Inevitably, all broadband providers will need to support IPv6. Most regional Internet registries (RIRs) have already run out of IPv4 addresses and resources are limited worldwide. How can you plan for a painless transition? This document aims to set out the basic steps involved in planning for IPv6 on your network, and what to consider to plan routing for IPv6.

IPv6 vs. IPv4

IPv6 is more than just IPv4 with larger IP addresses — although that is part of the change. While IPv4 addresses have 32 bits, IPv6 addresses are hexadecimal and have 128 bits. IPv6 supports some 340 trillion, trillion, trillion Internet addresses, compared to only 4 billion under IPv4 — which is no longer enough to support all the IP devices on Earth.

IPv6 also offers a range of new features designed to lift various restrictions and workarounds that were necessary when reusing and sharing addresses under IPv4. IPv6 allows you to renumber your network in a way that actually makes sense.

IPv6 Routing Considerations

Your RIR is likely to give you /32 as a basic IPv6 resource allocation. This corresponds to over 4 billion subnets that are usable for customer addresses as well as your internal infrastructure.

IPv6 routing is intended to easily aggregated, so it’s best to start at the small end and work your way up when planning your routing configuration. There are obviously many ways to do this, but below are some examples for grouping together subnets.

Single IP Distribution

For example, you could divide up the IPv6 address to encode your organization, as demonstrated below:

A network address would look like this:

2001:4359:pqrs:tuvw::

Under most CMTS configurations, a single interface needs three subnets:

  • One for the cable modems

  • One for the eMTAs

  • One for residential customer devices

Each character in an IPv6 address represents four bits — or half an eight-bit byte — called a nibble. Following the above example, use the “w” nibble to encode that information (say, 1=CM, 2=eMTA, 3=residential). This even leaves space available for another 13 subnets on a single interface. Then move up one more level. How many interfaces will you have on a single routing chassis (CMTS)? If you only have up to 16 interfaces on the CMTS, you can use the “v” nibble to encode that information.

You can then continue working up the chain of nibbles (and potentially join two nibbles together to encode up to 256 items) until you have accounted for your entire organization. Following the above example, let’s use the “p” nibble to designate how to interpret the remaining nibbles. As an example, for “p” = 0:

Nibble

Purpose

w

Subnet Type (CM/eMTA/residential/13 other)

v

Interface/Bundle on the CMTS (up to 16)

u

CMTS within a Neighbourhood (up to 256)

t

s

Neighbourhoods within a City (up to 16)

r

Cities within a Region

q

Region

p

0

This may offer a good distribution of space when you are giving single IPs to customer devices. This example only divides on four-bit boundaries, but you could divide on any bit boundary.

Because the individual subnet space is so large, you should never have to assign another “residential” subnet to an interface.

Assigning Subnets

A second class of subscribers are those which are assigned entire subnets. You may choose to do this using prefix delegation for business customers, for instance. These customers may have been assigned static subnets, and they may move around in the network. This can result in a different encoding, as seen below:

Using the example: 2001:4359:pqrs:tuvw::

Nibble

Purpose

w

Used by the customer (16 subnets)

v

Customer subnet (up to 4096)

u

t

s

Neighbourhoods within a City (up to 16)

r

Cities within a Region

q

Region

p

1

This would represent an allocation of a /60 subnet to each customer. In this example, the customer would be able to move to anywhere in their neighbourhood and still retain the same subnet allocation.

Of course, this example only shows two encodings. The “p” nibble can still designate up to 14 more of these uses. Try to make your encoding schemes as aggregatable as you can, as this makes your core routing tables smaller. This results in a lighter load on your core routers and requires less memory.

IPv6 Anycast Addresses

IPv6 has a built-in concept of an “anycast” address. This is an address that any client can use and the network will attempt to route that traffic to the closest server with that anycast address (where closest means the shortest number of router hops).

This is useful for informing clients where their recursive DNS server is, for example. By giving all of your clients the anycast address of the DNS, no matter where the client appears in your network, it will use the closest DNS. This means that you don’t have to configure your provisioning system to give out different DNS addresses depending on where the client is coming from. This applies to any service, not just DNS. Use anycast addresses to simplify your client configuration.

Share your experience and strategies for working with IPv6 in the new Incognito global survey IPv6 in the Communication Service Provider Industry and receive a copy of the free report.

  • Share: