FINLEY NEWSLETTERS

THE GRID

COMMUNIQUE

Social Links

How IPv6 Can Help Service Providers Build the “Smart Network” Whitepaper

IPv6 is the next-version Internet Protocol that will replace IPv4. As many of you already know, the driving force behind the urgency to adopt this next-generation Internet Protocol is the depletion of our current IP address space, which is based on a size of 32 bits. The new IPv6 address space is based on a size of 128 bits. We know that the IPv4 address space is almost gone, but what does this mean to you as an Independent Operating Company (IOC)? After all, many of you have a reasonable amount of IPv4 address space issued to you directly by the American Registry for Internet Numbers (ARIN) or your upstream service provider. Many of you have also deployed IP address-saving techniques within your networks, such as sub netting and Network Address Translation (NAT). In addition, and running NAT internally within their private networks. So, do you have to worry about deploying IPv6 on your network today?

Download Whitepaper Here pdf-icon

For over a decade now, service providers have done a good job managing their IPv4 address space. They have followed the strict requirements set forth by ARIN with regard to address space utilization. They have sub netted their address space in variable lengths to ensure address-use efficiency. They utilize dynamic IP address pools that will take back an IP address from one customer once they go offline and assign it to another. And while these are all good techniques to preserve address space and prolong the use of IPv4, they do not foster network innovation and connectivity reach that only an extended address space can provide.

The enormous size of the IPv6 address space means that existing techniques such as NAT are no longer necessary to provide network connectivity. As Smart Home and Smart Grid technologies take hold, these services can be provisioned natively without complex address translation techniques.

Today, technology to provide device and content mobility is based upon complex and proprietary processes to ensure smooth network-to-network handoff. With the use of IPv6 mobility “Home Address” techniques, mobility can be achieved and deployed in a vendor-agnostic, cost-effective manner.

Not only is IPv6 going to solve the address exhaustion problem of IPv4, it will also provide foundation for network reach and innovation for years to come. So, they question for the IOC is how do you get started? Because your network may not be as large as the AT&T network, you have limited resources. How are you going to convert your entire network from an IPv4 network to an IPv6 network?

Let’s dispel the first myth – that service providers are going to convert their IP4v-based networks to IPv6 overnight – right now. IPv6 and IPv4 will coexist on their networks for many years to come. Most networking hardware, software and computer operating systems produced in the last five years or so will support IPv6 addressing alongside IPv4 addressing. This is known as dual stack. IPv6 is a completely independent protocol with no native backward compatibility to IPv4. While there are technologies such as 4to6 and 6RD to provide connectivity between IPv4 and IPv6 hosts, they are not native to the IPv6 protocol.

This slow transition from IPv4 to IPv6 ensures the latter will be around for a long time. The next question many service providers will ask is where do I go to get IPv6 address space? The answer depends on where you currently get your IPv4 address space. If you received your IPv4 address space directly from ARIN, then you will more than likely qualify for an IPv6 allocation directly from ARIN. If you received your IPv4 address space from an upstream ISP, then you should check with them about an IPv6 allocation. Most IOCs will receive a /32 prefix (more on this later) directly from ARIN.

The next step in the IPv6 deployment process will be to inventory your existing network elements for IPv6 compatibility. Since the main driver for IPv6 deployments is the depletion of globally unique IPv4 address space on the Internet, it is recommended that you start with your ISP infrastructure. This will include IP routers and switches that connect your customers to the Internet, BRAS devices, firewalls and server operating systems that are used for DNS, DHCP, Web, RADIUS and email hosting. Not only should these devices be evaluated for IPv6 compatibility, but they should have the CPU and memory capacity to support both IPv4 and IPv6 (dual stack) at the same time. For Internet routers running BGP with a full Internet routing table (IPv4), adding IPv6 will require more processing power and memory.

Once your ISP core infrastructure is verified (or upgraded) as IPv6/IPv4 dual-stack capable, the dual-stack process begins. Using your IPv6 allocation, you should develop and address design plan and start the dual-stack process. This will include dual-stacking your DNS and Web servers so that they respond to both IPv4 and IPv6 requests. You will also have to coordinate with your upstream ISP(s) in order to start exchanging IPv6 routing information, which will give you reachability to the global IPv6 network. The following diagram illustrates a sample service provider ISP network with IPv6 numbering:

save

The foundation has been built! You now have an IPv6-capable ISP core network. But what about the transport network and access networks? How do you achieve IPv6 connectivity all the way out to your subscribers? The answer to this question will not be the same for all service providers. Most service providers layer-2 transport networks will be capable of carrying IPv6 packets even if they cannot support an IPv6 address for management purposes. What this means is you may elect to keep your existing transport network in place, and manage it with private IPv4 addresses while allowing it to carry your new IPv6 traffic. Over time, you will want to consult with the vendors of your transport network on IPv6 availability.

While your access networks are traditionally layer-2 networks, many xDSL and FTTP access platforms provide some layer-3 (IPv4) visibility and access control. For example, many access platforms will provide DHCP and ARP proxy as well as IP address ACLs. These functions help keep bad things from happening on your networks, such as the problems caused by a customer who hooks up a home router incorrectly and starts advertising DHCP services into your network. You will need to check with your access vendor(s) on their IPv6 status to see when they will provide this same access control for IPv6.

Finally, the customer CPE, whether it is an xDSL modem or FTTP ONT, must be evaluated for IPv6 compatibility.

For legacy systems that are “End of Life,” you may elect not to do anything right away with these networks, and instead develop a five-year plan to slowly migrate these subscribers to newer access equipment with IPv6 support.

Most IOC IPTV networks and VOIP deployments are closed based upon IPv4 private addressing. Since the addressing used for connectivity within these networks does not need to be globally unique, they are not as critical as your ISP infrastructure. Moving these systems to IPv6 is going to be largely dependent on vendors of VOIP phones, ATAs, set-top-boxes and middleware providers. It is important that you keep your “ear to the ground” on IPv6 movement, but not as critical as your ISP IPv6 deployment.

Now that your ISP network is dual-stacked with IPv4/IPv6, how do you start allocating address space to individual customers within your network? For those of you who have administered IPv4 networks for any length of time, getting used to the simplicity of IPv6 prefixing takes some time. IPv6 is far easier to “subnet” than IPv4! Let’s start by looking at a typical prefix allocation that an IOC might receive from ARIN:

2000:23ab::/32

This is a /32 allocation in “shorthand.” The full prefix would look like this:

2000:23ab:0000:0000:0000:0000:0000:0000/32

In the above example, the first 32 bits become the service provider’s prefix (2000:23ab), and every address within the service provider network will begin with this prefix. The next 16 bits will represent customer prefixes and can be in the range of (0000 to FFFF):

2000:23ab:0000::/48 -to- 2000:23ab:ffff::/48

You will notice the /prefix changed from a /32 to a /48. This is because we are using the next 16 bits after the first 32 bits to identify customer prefixes (32 + 16 = 48). For those of you who have not already done the math, 16 bits provides for 65,535 unique customer prefixes! Following this rule for prefix allocation means that you as a service provider can serve 65,535 unique customers with your /32 allocation!

Moving on to the next 16 bits after the customer prefix is the subnet portion of the address space. In addition, just like the customer portion, this portion is 16 bits and can be in the range of 0000 to FFFF. Yes, that is 65,535 subnets for each customer:

2000:23ab:0001:0000::/64 -to- 2000:23ab:0001:ffff::/64

In the above example, we have a customer with the prefix of 0001 (third set of numbers) who can further define 65,535 subnets within their own network!

So now we have used 64 of the 128 bits. The last 64 bits are used for the host portion of the IP address. This could be as simple as a statically defined number such as 1 or 200 for a router port or Web server host, but it can also be an automatically assigned number by IPv6 itself. In this case, the host portion of the address is in EUI-64 format. Extended Unique Identifier, or EUI, is a host number generated using the host’s MAC address extended to encompass 64 bits.

So, routers with a /64 address can auto-configure directly attached hosts by combining the router’s /64 prefix with the host’s EUI-64 address as follows:

Untitled

As mentioned above, the general recommendation will be to issue a /48 prefix to each customer on your network. That means you will be issuing a prefix large enough for a residential home user to have over 65,000 subnets! A /56 prefix could be assigned instead of a /48 which would provide 256 subnets to the end user. This is usually the difficult part for IPv4 administrators to swallow. Why would you do this? Why would you not subnet your IPv6 address space down even further? For example, down to a /96 for each of your residential users? The reason you do not want to do this is because you would break the auto-configuration feature of IPv6 that CPE routers will support. For the seasoned IPv4 administrator, this seems like a waste of address space. However, if you get away from the address space efficiency aspect and look at prefix efficiency, you will notice that all your customer prefixes are /48s. Complicated variable-length subnets are a thing of the past!

DHCP servers will be configured to do IPv6 Prefix Delegation. Therefore, when the service provider’s DHCP server delegates a /48 prefix, the CPE router will further sub-delegate prefixes within the internal network. The following diagram illustrates the prefix delegation process:

sssssss

IPv6 will be an integral part of your “Smart Network” deployment strategy. The extended address space size means devices will no longer have to navigate complex NAT schemes for global connectivity. IP connectivity will reach deeper into your subscriber homes and businesses for the following:

  • IP-enabled appliances
  • Physical security monitoring
  • Video surveillance
  • Remote control of in-home devices
  • Automotive preventive-maintenance monitoring

Furthermore, as we look for more efficient ways to live on a “green planet,” energy utilization will also become dependent on IP connectivity. Your IPv6-enabled Smart Network can be a key player in future Smart Fid technologies.

Your IPv6-enabled Smart Network will also be a catalyst for IP connectivity in the public sectors you serve:

  • Law enforcement roaming connectivity
  • Efficiencies in medical records processing (e.g., imaging, accuracy)
  • Connectivity for schools and libraries

The mobility aspects of IPv6 will allow portable devices to cross network boundaries seamlessly without service interruption. The explosion of new devices and services will mean higher bandwidth consumption by your subscribers.

FINLEY ENGINEERING BLOG

Subscribe to blog

Subscribe via RSS

FINLEY NEWSLETTERS

THE GRID

COMMUNIQUE