Live Chat

Current IPv6 Network Techniques and Transition Strategies

This is the second of two posts on IPv6 written by Jag Bains, Director of Network Operations at PEER 1 Hosting. You can read his first post entitled Fear and Loathing in IPv6 Land.

Despite the race condition to procure the last of the IPv4 space from the RIR’s, there are still a large percentage of Network Operators who do not have an IPv6 game plan at this time. With IPv6 fundamentally being a separate network (an IPv4 address cannot route to an IPv6 address), the adoption of an IPv6 strategy is as much a business decision as it is a technical one, and with an uncertain landscape on how global IPv6 deployment and adoption rates are to be, these organizations are taking a ‘wait and see’ approach for the time being.

The ones who are taking a more proactive approach are primarily adopting one or all of the following approaches.


In the absence of an IPv6 capable network between two IPv6 hosts, tunnelling is used to provide connectivity between them. This is done by encapsulating IPv6 packets within IPv4, in effect using IPv4 as a link layer for IPv6.

Native/Dual Stack

With the presumption that the network between hosts is capable of routing both IPv6 and IPv4, hosts are dual stacking IP addresses in their operating systems so they can route to either network. While this allows developers to create code that can work on both networks, there is still a fundamental divide in that IPv4 hosts cannot route to IPv6 hosts, and vice versa.

Carrier Grade NAT (CGN)

This differs from the previous two, which were focused on just routing IPv6 hosts to each other. A CGN, also known as a Large Scale NAT (LSN), is intended to bridge IPv6 and IPv4 hosts, so that they communicate with each other. An example of a real world scenario would be having an IPv6 mobile phone using a CGN to access content on a IPv4 host. At it’s core, a CGN is a simply middlebox that translates multiple hosts with IPv6 addresses to a small set of IPv4 addresses, so that communication can be realized with the global IPv4 network at large.

Regardless of the approach used, all methodologies come with caveats and limitations due to the distinct boundaries between IPv4 and IPv6, and the debate rages on in the network world on what the prescribed methodology should be during the 'transitional' years as we migrate to eventual native ipv6 support.

PEER 1 Hosting and IPv6

Our network team has been looking at IPv6 for sometime, understanding that IPv4 exhaustion poses a significant business risk. Fortunately, our IPv4 allocations are in very good shape, allowing us to investigate multiple tactics and strategies to introduce IPv6 over time.

Here are some of the highlights of what has been achieved on the IPv6 front to date:

IPv6 Architecture and Design

PEER 1 Hosting procured its first IPv6 allocation, 2001:1978::/32, from ARIN in 2004. Since then, we’ve obtained 2606:be00::/32 in anticipation of our Serverbeach implementations, as well as 2a03:8a00::/32 from RIPE for our European operations. Along with acquiring these blocks, we have invested considerable time in designing a  highly redundant  network architecture that will allow us to support deployment of these addresses to clients across our network. Presently, a tentative IPv6 customer provisioning model looks like this so far:

  • Each PEER 1 Hosting city will be provisioned a /40 (309,485,009,821,345,068,724,781,056 ip’s)
  • Each Customer VLAN will be provisioned a /64 (18,446,744,073,709,551,616 ip’s)
  • Each BGP Customer will be provisioned a /64

Network Upgrades

Over the last 4 years, PEER 1 Hosting has made significant investment into our network infrastructure to prepare for IPv6. The upgrades that have been implemented to date have significantly increased our overall bandwidth capacity, as well as given us the ability to provide native, dual stack IPv6 support on our backbone and Colocation operations. This makes PEER 1 Hosting one of the first Canadian companies to provide IPv6 transit in Canada. Support for IPv6 will extend into our Serverbeach and Managed Hosting networks once we have completed upgrading those environments over the next few months.

Presently we are also in the midst of evaluating IPv6 capable DNS servers, which we will be installing throughout our anycast DNS network. In conjunction with this we are also installing tunnelling servers throughout our backbone to further assist in reachability to the PEER 1 Hosting network, for those remote networks that cannot route natively.

Compatibility and Readiness Testing

Within a complex hosting environment such as ours, there are many pieces which need to be tested for IPv6 support and compatibility. Some highlights of what is currently underway include:

  • Our Network Engineering team is presently working with our various hardware and software vendors such as Brocade and Radware to evaluate CGN strategies for Service Providers and Hosting Environments specifically, in addition to coordinating ongoing network infrastructure upgrades, which aim to be completed by the end of 2011.
  • Support  teams are working to ensure IPv6 readiness for various extended services we provide, such as load balancers and firewalls, as well as working with identified customers to test one-off IPv6 deployments and engaging them on evolving our strategy as it continues to develop in the network world at large.
  • The Network Operations Center has been busy testing and developing new tools for tasks such as IPv6 monitoring and provisioning, so as to adapt new policies and procedures to be able to meet the support needs as IPv6 gains traction.

How I Learned to Stop Worrying and Love the Hex

To date, the only thing that the network community have agreed upon is that IPv6 needs to be realized globally sooner than later; there has been no consensus achieved on how that will be done.  Heated discussions are taking place in various blog spheres and mailing lists, leading to confusion and apprehension, and sometimes fear mongering. CIO’s and CTO’s are now constantly being barraged by vendors who can offer an IPv6 solution in a box. Discussions surrounding a  ‘black market’ for IPv4 space are taking place, given credence by Microsoft’s latest $7.5 million purchase of Nortel IP space. This has led some folks to believe that future mergers and acquisitions will heavily factor in the availability of IP space within target organizations.

At a personal level, I’m still trying to get a comprehensive understanding on what the cable/dsl/access providers are doing and what rates to bring IPv6 capability to their subscribers, as I ultimately feel that the number of subscribers in IPv6 space will drive the development of IPv6 throughout the industry, but it’s hard to tell what is going on in this space. Whatever the case may be, IPv6 needs to be addressed by everyone with an online presence, and it’s a strategy that will need to be developed within the network departments of each organization. With PEER 1 Hosting’s great history in running a global network, we are well positioned to continue developing our IPv6 strategy to ensure the business continuity of our customers.


Support for IPv6 at ServerBeach?


I note in this article written two years ago that you state "Support for IPv6 will extend into our Serverbeach and Managed Hosting networks once we have completed upgrading those environments over the next few months." However, after being unable to find any information in the ServerBeach web site, I just confirmed in a live chat with a ServerBeach sales rep a few minutes ago that ServerBeach does NOT offer IPv6 yet.

I am very interested in potentially using a webhosting provider that is one of your customers. However, for a variety of reasons I need IPv6 connectivity to my websites (mainly because IPv6 is one of the topics I write about).

Can you provide any updates on your plans for IPv6 at ServerBeach?



Hi Dan,

While the infrastructure that powers PEER 1's services, including the servers and network hardware, is capable of using IPv6, so far, the demand from customers for this service has been low and therefore we have not integrated IPv6 capabilities into our backend systems. As with all technology changes, we will continue to listen to what our customers are saying and when a critical mass of demand is reached we will add IPv6 to our product portfolio.


Lyza Latham
Senior Manager, Product Marketing

No customer demand?

I know I've asked about it. I don't know about the rest of your customer base, but I know I'm already tunneling IPv6 on my hosted server and would be grateful if servers supported IPv6 -- or at least didn't filter AAAA records from the domains they serve.

Post new comment

The content of this field is kept private and will not be shown publicly.


This question is for testing whether you are a human visitor and to prevent automated spam submissions.