Threat Level: green Handler on Duty: Manuel Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

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
Metafore

Keywords: ipv6
8 comment(s)
Diary Archives