IPv6 Transition: Cisco LISP Vs. Tunnel Services

The dwindling IPv4 address space is nearing its end. The American Registry for Internet Numbers (ARIN) has announced that it has reached Phase 3 of its IPv4 Countdown Plan. ARIN only has two /8 address allocations left to hand out addresses before it must look at other measures. This means IPv6 should be ready to take center stage as the only protocol with significant room for address growth in the next few years.

The great migration to IPv6 is no secret, and enterprises should have transition plans in place. Desktop OSs have been running IPv6 for many years now, so the focus for the present is on things like firewalls, intrusion prevention systems and appliance-based network services like VoIP.

A bigger, more pressing question has yet to be answered: How are we going to interconnect all of these devices through a largely-IPv4 Internet?

Cisco has proposed the use of its Locator/Identifier Separation Protocol (LISP) as an IPv6 transition mechanism. LISP is an encapsulation protocol originally designed to reduce the rapidly growing number of routes in the global IPv4 routing table. LISP functions like DNS, where a request for an unknown location requires a lookup to a server that contains mapping tables that point the packets to the correct destination. Cisco suggests using LISP to interconnect "islands" of IPv6 over the IPv4 Internet.

[IPv6 isn't the only big transition for IT to manage. 802.11ac is also fast approaching ratification. Get an overview of what's going to change, and how it might affect your WLAN strategy, in "802.11ac: Time to Change Vendors?"]

Configuring IPv6 on a LAN is a fairly trivial exercise. Odds are good that more than half the devices in your network are IPv6-enabled already. The problem comes when you want to do something outside your network with IPv6. If your ISP doesn't offer native connectivity today, a tunnel broker service such as Hurricane Electric or SixXS lets you create IPv6 connectivity to the greater Internet through demarcation points.

When I look at what Cisco proposes with LISP, I can't help but wonder about the advantages over tunnel services. LISP as a routing table reduction mechanism is a noble idea. Smaller IPv4 routing tables require less router memory. They also speed convergence time in the event of a failure. Centralized mapping servers also provide for infrastructure that could eventually lead to a DNSSEC-like function for LISP to prevent unauthorized route injection attacks.

But when the talk turns to IPv6, LISP's value becomes less clear. From the outside, LISP looks no different that the IPv6-in-IPv4 tunnels that are created via a tunnel broker service. LISP encapsulates the packets between egress tunnel routers (ETRs), which sounds suspiciously similar to a tunnel. However, there's a lot of extra configuration that needs to go into configuring LISP above and beyond a basic IP-in-IP tunnel.

I also wonder whether connecting IPv6 sites together is an important goal. With LISP (or even basic tunneling) you could use RFC 1918 address space in your LAN to connect all the devices together. Why spend the extra time configuring router advertisements and dual-stack WAN routers if it's not necessary for anything more than talking to a site in another city?

The real advantage of IPv6 comes not from connecting LANs but from connecting those LANs to the global Internet. That's where the real power of IPv6 is going to be found. We can do away with NAT and instead have direct system-to-system connections to facilitate better communication. We can have nearly unlimited address space to grant IP connectivity to an almost any device.

Unfortunately, service provider are notorious slow on the uptake of new technology, and because IPv6 requires bigger, faster hardware, some ISPs are taking a wait and see approach. If they can keep their old routers and switches running just one more budget cycle, they can wring a bit more profit out of them.

They also have a few more months to work out exactly how to reconfigure their systems to support the large influx of IPv6 traffic. And just maybe they can find a way to charge a premium for IPv6 connectivity.

Once end users force service providers to offer IPv6 connectivity on the WAN side, the need for LISP (and indeed tunnels) largely disappears. Cisco will tell you that having LISP today will let you to reap the benefits even after IPv6 becomes more mainstream and WAN connectivity is ubiquitous.

I say tunnels offer faster configuration and are much easier to take down when no longer needed. IPv6 transition mechanisms should be seen as a means to an end, not a value added feature that is left on after it is no longer needed.

LISP has merits, but I don't think IPv6 transition is one of them. What do you think? Is LISP the way to go for IPv6 transition? Do you prefer a different method? Or are you waiting for something else to leave IPv4 behind?