Under the Hood with IPv6

We’re going to spend some time teaching you a number of incredibly wonderful things about IPv6, such as:

  • Why network admins need to get their duffs up and implement it
  • Nice bullet points for persuading PHBs (define)
  • How to actually use it

Persuasive Bullet Points
IPv6 means a whole lot more than just having a large enough pool of addresses to give every grain of sand and star in the sky a pool of unique addresses to play with. It also incorporates a lot of long-needed improvements in the IP protocol:

  • No more NAT (Network Address Translation)
  • Autoconfiguration
  • No more private address collisions
  • Better multicast routing
  • The newfangled anycastrouting
  • Simpler header format
  • Simplified, more efficient routing
  • True quality of service (QoS), also called “flow labeling”
  • Built-in authentication and privacy support
  • Flexible options and extensions
  • Easier administration – say good-bye to DHCP

No More Lollygagging
You’ve doubtless read articles that claim the cost of migrating to IPv6 is going to be huge and painful, on the scale of Hurrican Katrina or Y2K. (Don’t even get me started on the Y2K profiteering.) I don’t think so. Naturally, anyone who is clinging to ancient routers and switches that don’t support IPv6 is going to suffer the pain of buying new hardware. Cry me a river – you’ll get great new stuff that will outperform those old antiques you’ve limping along with for so long. By design, IPv6 and IPv4 are going to co-exist for some time, so admins can take their time and migrate in nice sane small steps. No doubt some will suffer headaches from having to stuff new knowledge into their heads, but trust me, it’s worth it.

Probably the biggest selling point for IPv6 is the shortage of IPv4 addresses. Here in the good old US of A, in typical overlord fashion, we possess the majority of them. While NAT and CIDR notation have extended the number of usable IPv4 addresses, NAT needs to go away forever, and the rest of the world can’t live on our scraps.

Death to NAT
I long for the day when the final stake is driven through the heart of NAT. NAT extended the useful life of IPv4, which is a good thing, but in itself is a horrid kludge that has driven far too many network admins to drink and hair loss. Why does NAT suck? For a number of reasons. First of all it’s a big fat chokepoint on your network border, forcing every single packet that enters or leaves your network to be examined and altered.

Secondly, NAT complicates every service, requiring all sorts of corollary hacks and kludges to make things work, especially services that use multiple ports. Everyone who survived the days of trying to make things like IRC, FTP and NFS work through NAT firewalls deserve medals. (You younguns just don’t appreciate our suffering enough.) Most services have been around long enough to accumulate enough kludgework to deal with NAT, but new services still have to go through the pain cycle. Like the SIP (Session Initiation) protocol for voice-over-IP, Bittorrent and other peer protocols, plus anything that you want to run on multiple machines behind the same NAT address.

Colliding Private Addies
All those lovely, unique IPv6 addresses instantly cure a large IPv4 problem: private address collision. This happens when you have to integrate subnets that use the same IPv4 private address space- boy howdy, that’s more fun than a barrel of monkeys.

Simplified Routing
The IPv6 header is completely re-designed. Required components are moved to the front of the header. Optional components are moved to an extension header; if there aren’t any optional components, the extension headers are omitted and the packet size is reduced.

But that’s not all. The IPv6 protocol is ingeniously designed so that our hardworking spam-burdened Internet backbone routers will have much smaller routing tables than they do now. No longer will they need to know every possible route, which is why those big backbone routers are the size of Ford Exorbitants. Instead of having to know every possible route, the routing tables will include routes to only those routers connected directly to them. The IPv6 protocol itself contains the remaining information a packet needs to reach its destination.

Real, Genuine QoS
QoS in IPv4 is a bit of a joke. Sure, packets can be assigned different priorities, but a lot of routers simply ignore the QoS flag, and certain networking stacks are rumored to mark all packets as highest priority, so it’s pointless to even try.

In this modern era of gigabyte and multiple-gigabyte networking speeds, voice over IP, streaming video, and other high-demand real-time services, that sort of clunkiness simply will not do. IPv6 is designed to handle these new super-high speeds, and it standardizes QoS so that all routers will handle packets correctly, even allocating bandwidth according to priority.

Easier Administration
Don’t be scared by those long hexadecimal IPv6 addresses. We’ll learn how to break them down into manageable chunks, some shortcuts to save typing, and understand what each piece means.

There are two separate address spaces for private addressing called “link-local” and “site-local.” A link-local address is like a single subnet and should not be routed. Link-local addresses let you do fun easy things like:

  • Host autoconfiguration without DHCP, simply by querying the router
  • Neighbor discovery
  • Setting up ad-hoc LANs without a router

In other words, you can fling a gaggle of strangers together in a conference room, connect all their PCs (wireless, wired, whatever), and share files without having to rassle with file-sharing protocols.

Site-local addresses are like a typical office containing several subnets. The subnet information is in the address so they can be routed within a site. They should not be forwarded outside the site.

Understanding IPv6 addressing is the key to understanding how to use it, so next week we’ll roll up our sleeves and make a nice IPv6 network.


Latest Articles

Follow Us On Social Media

Explore More