IPv6 Focus Month: Barriers to Implementing IPv6

Published: 2013-03-07
Last Updated: 2013-03-07 18:47:15 UTC
by Rob VandenBrink (Version: 1)
8 comment(s)

I've been trying for a few months now to get my lab running IPv6 natively, with mixed success.  What's standing in my way you ask?  A couple of things, which in turn have further implications:

Barrier #1: IPv6 isn't free

First of all, if you want IPv6 addresses that will route on the internet, they're not free.  For instance, if you're within arin.net's jurisdiction, the fee schedule is here: https://www.arin.net/fees/fee_schedule.html.  The fees are annual, none of these are one time prices.

Note that experimental addresses are still relatively cheaper (500 per allocation), but they expire in 12 months.  Since I won't be folding my lab up anytime soon, I think I'll need to cave and buy a subnet.  Note that the smallest allocation is a /48, which leaves a whopping 80 bits of address space to carve up - more than the entire IPv4 space.  So for $1250, I (or any company who needs space) can make my routeable address problem go away.

What the implications of this are is quite different though.  Currently, in the IPv4 world, most organizations assign RFC1918 addresses (private addresses) to their inside network, and then NAT those IP's out to a much smaller address space, which they've purchased from their registrar, or that has been provided by their ISP.  So migrating to a new ISP involves some firewall and router work, and, you've got a small address block to move either mvoe to a new ISP, or get a new block from your new ISP and change all your DNS entries (and VPN tunnels) to the new subnet.

In the IPv6 world, we'll see folks in two camps.  Those who have purchased a routable block and used those on their inside network will be in one camp.  They're very mobile, and will be able to change ISPs very readily.  However, they'll also need a much deeper network skillset, as they'll likely need to run an external routing protocol, peering with their ISP using the BGP routing protocol to advertise their subnet (note that this could also be done statically).  The smaller organizations who have been given IPv6 space by their ISP however will be in a different situation, and faced with two problems.  Once they implement IPv6 using ISP address space, changing ISPs will involve renumbering their entire inside address space, changing the IPv6 address of every server, workstation, printer and access point.  Not only is this a large, disruptive project in the best of situations, these small companies generally are not well-equiped to understand or deliver on such a project.  So once they have implemented IPv6, they are essentially chained to their ISP, or need to bring in outside help to migrate.

Barrier #2: Check your Network Hardware and OS

For the most part, newer network hardware such as routers, switches and firewalls - say anything sold in the last 5 years or so - is IPv6 capable.  However, the OS running on that hardware isn't neccessarily ready, or it may have known problems.  Plus it's not uncommon at all to find network gear in rack that's older and is *not* IPv6 ready (how many Cisco PIX units are still in service for instance - PIX's will do IPv6, but only from the CLI in the newest of new IOS versions, no ASDM support).  Be sure you check your gear and the OS running on it before committing to a final budget on your IPv6 project !

Barrier #3: IPv6 still isn't everywhere (yet)

I live and work mostly in Canada, so my lab is also north of the 49th.  Even now, 2 years after the IPv4 address space has been fully allocated (https://www.arin.net/announcements/2011/20110203.html) and 10 years after our ISPs and WAN providers have all known what was coming, many, if not most providers are just starting down the path.  We've gone from "not at this time" to "we'll be there in 6-8 months" list with almost every WAN provider, telecom and ISP in Canada for the last 3-4 years.  Even my current lab ISP, who has extensive blog postings on why you should migrate, will not have IPv6 for my area until May/June (of this year, I hope!).  This is frustrating to me, because any gear that supports MPLS or supports a full internet BGP table has been IPv6 capable for several years now - this is purely a problem of assigning technical folks to do the work at the ISPs and WAN providers.

So if you want native, routed IPv6, in many cases you're looking at using a tunnel broker such as Hurricane Electric to give you transport.  What this means to me is that my IPv6 traffic now (all) needs to traverse a third party that is not my ISP.  Given that I'm generally running one or more security assessments or penetration tests, or otherwise messing with my datastream, giving more folks than neccessary access to my packets does not fill me with joy, especially since I don't have any kind of contractual agreement with a free tunnel broker.  Given how easy ettercap, sslstrip and other MITM tools are to run, or even how much information you can glean from simple netflow/sflow, I'd as soon limit that sort of exposure.  If your internet traffic might carry confidential data, especially using SSL for encryption, I'd suggest that you might not be thrilled with a tunnelling solution either.

So, while I'm getting the purchase of my address space all worked out this month, I'm still firmly rooted in the IPv4 world until later this summer, no matter how much I'd like to have a foot in each version.

If you've completed your IPv6 project, or if you are still planning one out, we'd love to hear about any roadblocks or problems you've identifed or overcome - please use our comment form !

Rob VandenBrink

Keywords: ipv6
8 comment(s)


A Wikipedia article says that there is a block of private IPV6 addresses that can be used. I do not know if these addresses are used the way the three blocks of IPV4 private addresses are using NAT. Perhaps an article on this would be good since it might be a way for small businesses to not have to redo when they change ISPs.
There is a block of addresses for private use similar to the RFC-1918 addresses. The fc00::/7 block is define for unique local addressing in RFC-4193. Following the recommendations in the RFC for the creation of your address block should result in a globally unique address block. However that block will not be routable on the Internet. It just means you won't have address collisions like we do today with the private IPv4 blocks between companies.
A common misconception when just stating with IPv6 is that in a /48 you do not get 80 bits of address space to carve up. You get 16 bits of networks (65K of them). ALL subnets in IPv6 are /64's, with one exception, /127's for point-to-point links. At this point in time, varying from the /64 subnet length will lead to problems both in implementation and compatibility with many RFCs (SLAAC for instance). It's a hard lesson to learn because it's in conflict with what we've been doing with IPv4 CIDR addressing for years. Basically forget about the hosts and concentrate on how to deploy the routable subnets. Nobody is actually going to have all of the 18 quintillion possible host addresses used on a subnet, but you don't have to concentrate on subnet lengths in v6 like you do with v4. Concentrate on the network, then when you are ready for local addressing you have 64 bits to play with in some very interesting host addressing schemes. Those can be applied across all of your subnets using DHCPv6 or static addressing.

I feel your pain about ISP support. Even the major ISPs are still working out kinks. They may have IPv6 available but the actual implementation routines haven't been fully vetted. Make sure to allow ample time, in some cases months, to turn up IPv6 connectivity. If you're the first customer on that particular access router to need v6, they may still have to do a software upgrade to the access router or CPE to support it. In some cases requiring weeks of lead time for the outage. Beyond that, the customer support scripts, portals and work flow methods they are using may not be ready for you to call in with your IPv6 requests and support needs. Bottom line, expect delays and plan accordingly. It quickly becomes clear that We're not the only one's dealing with a learning curve.
ARIN's annual fees for IPv6 netblocks only apply to ISPs. End-user IPv6 asignements only have a one-time fee*.

Most small-medium orgs with PI address space (RIR directly allocated Provider Independent) needs (read:don't want to have to renumber or be tied to a single ISP, and want to multihome) are looking at a one-time $1,250 fee for up to a /41. Assuming default /64 LANs, a /41 is 23 bits of network addressing (128 total bits - 64 node bits - 41 assignment), a /48 is 16 bits of addressing space (compare to IPv4 class B /16 assuming /24 LANs) - that's huge. Of course, some of that depends on how you number, and if you give each "site" a /48, etc., but still, it's a huge amount of permanent address space for $1,250.

*There is an annual $100 maintenance fee, but if you already have an ASN for BGP, you already pay this fee and there is no additional fee.
ARIN July 2013 fee schedule change:

Re: End-User assignments, a /48 from ARIN will drop to $500 and a /47 - /36 will drop to $1,000.

Your comment about having to readdress your servers seems a tad off. The entire point of address management in v6 is to control the addresses from the router. The only hosts which really need static addresses should be your DMZ machines. Other machines should be able to use dynamic addressing of one form or another.

There are areas of the world (Scandinavia and China come to mind) where many of these v6 issues have been solved. None of these are insurmountable. The end user should not need to worry about translation mechanisms in a dual-stack environment. Leave that to your ISP/core networks.

I can completely understand the US ISPs not releasing any IPv6 until they determine the most efficient method for charging the customer as much money as possible for the new service. That's capitalism. When the tipping point to v6 is reached, v4 will become the more expensive option.


I agree about the readdress issue being a bit off. At my home location with native v6 I had the pleasure of receiving a new suffix from my isp. Because the address management is done by the router all systems picked up their new address automagically, the only thing I had to do was add a new reverse zone in dns. The only real need for static addresses in my setup are DNS and DHCP servers which are both happy to use the link-local addresses (FE80::) for that. You can even add your own (like FE80::1:53) if you don't like something like fe80::be05:43ff:feeb:6b31 and want something easily remembered.


Actually I think if you talked to the average ISP engineer they'd tell you the reason it has not gained more traction is application support. RFC1918 is not large enough for many ISPs or even Mobile carriers, they are hurting for address space and IPv6 as the obvious cure is impeded by particularly bad support in many multimedia protocols and applications (which for better or worse are some of the biggest driving factors for customer use increases).

Diary Archives