So, two things about IPv6 – first, a little bit about how to do it if you’re all Mac’ed up like me, and then, a little rant.

The easiest way to get IPv6 working it is to grab a copy of Miredo for OS X. This lets your mac, pretty much automagically, get a connection to the IPv6 Internet via an IPv4 tunnel anywhere that you have IPv4 connectivity. It’s nearly painless, and at that point, you can start to at least do some basic playing around with IPv6 stuff. I enabled IPv6 on my home network, but I still have Miredo installed but deactivated if for some reason I wanted to use it when I’m at a coffee shop or some other network.

The good way to do it is to go to tunnelbroker.net and sign up (it’s free!). Then configure your Airport Extreme to do tunneling by following these directions. Voila. Now you have IPv6 connectivity to the intarwebs…or the ip6ernet. Whatever.

The best way to do it – and I haven’t done it this way – is to actually get IPv6 connectivity from your ISP – no tunneling or anything, just native connectivity. I can’t do this because Time Warner doesn’t give me that, or maybe my Airport isn’t so good at doing that. I don’t really know.

So far, the one thing I can see here is that you could begin to use this IPv6 connectivity to work around the general destruction of the internet any-to-any principle – the idea that any IP address on the internet should be able to contact any other. This is basically no longer the case, as many people use RFC1918 addresses behind NAT to conserve IP addresses (and also there are some positive security implications). So my computer at can’t necessarily talk directly to your computer at (or, even worse, your computer at but behind your NAT, and not mine). The way we work around this type of things is all kinds of magical firewall port-mapping and other such things. It’s a pain in the butt. Services like AIM’s ability to send files, or various screensharing utilities all now require some kind of centralized server that everyone can connect to because just about every network-connected computer tends to be behind a NAT. That centralization is unfortunate, and a drain on services that really should just be about connecting anyone to anyone.

But if you have IPv6 set up in the ‘good’ way listed above (or ‘better’), you actually have a new option. You can un-check “block incoming IPv6 connections” on your Airport, and now have access to anything in your network that speaks IPv6 from the outside world (again, so long as the outside world is IPv6). Of course, big security implications here, but that could actually be a way of making IPv6 somewhat (remotely) useful. Things that like this type of connectivity might be: BitTorrent-esque things…peer-to-peer video applications…some kinda of home-hosting things…I dunno. That type of stuff. But, in short, while at Starbucks, I could fire up my Miredo-for-OS X client, and connect to various things in my home. That could be useful for some people.

My experience with this new setup is rather underwhelming. I can go to ipv6.google.com. I guess on World IPv6 day I’ll be able to…somehow…enjoy some festivities or something. I don’t really have any home servers nowadays.

<Begin Rant>

Who the fuck came up with this stupid-ass migration plan? It has to be one of the dumbest things I have ever seen. IPv6 the protocol is OK (at best)…it really feels pretty close to IPv4, except with a bigger address space. OK, I guess. DJB (who is brilliant, but I think may be batshit insane) sums up the problem really well.

In short, there’s negligible benefit for going to IPv6. You can’t really get anywhere you couldn’t get to anyways. If IPv6 had been designed to interoperate with IPv4, we would be far closer to being in a happy IPv6 world – think about how many machines are dual-stacked right now? Those machines would instead be single-stacked, and some early adopters, or price conscious people (think: Web startup types who like to skip vowels in their domain names) might be able to start offering IPv6 only services, and would be able to start hitting users right now. But, no. The migration scheme seems to be:

  1. Migrate everyone and everything to IPv6 now

And you’re done! Isn’t that easy? The standard has been out for a bajillion years. The IPv4 shortage has been a problem for a bajillion years. And we’re still here. Not because the protocol for IPv6 is flawed, but because there’s no migration scheme at all. There’s no backwards compatibility. This whole infrastructure has to layer over the entire internet. Who the hell thought this was a good idea? I mean, sure, it’s “simpler”, protocol-wise, to do that…but a few more years of protocol engineering instead and a true backwards-compatible solution and we would’ve had people switching ages ago. Go look at how many transition mechanisms are in place for IPv4-to-IPv6. It’s stupid. That alone indicates the level of FAIL that is likely here.

The other problem I have with IPv6 has to do with routing tables. And protocol stacks. Right now, to do any non-trivial amount of TCP/IP networking (let’s imagine HTTP for this example), you need:

  • DNS
  • some kind of routing protocol has to be working right
  • ARP to figure out how to get to your local endpoint
  • DHCP to figure out what your IP address is going to be

Network troubleshooting ends up being an interesting and non-trivial problem of figuring out who can ping who (whom? Grammar fail. Sorry), what routing tables look like on various intermediate devices, what IP address you get from DNS, is your DNS server working, etc, etc. It’s a muddle, but it’s a muddle that’s been treating us well on this whacky internet of ours.

However, in the IPv6 world, we now have – the entire protocol stack for IPv4, PLUS a protocol stack for IPv6, and a crazy autotunneling doodad with a weird anycast IPv4 address (oh, that’ll be fun). And a routing table that is exploding out of control. I mean, my dinky little home network (theoretically) gets a /64 network. If every Time Warner customer gets a /64 – and there’s not some means of aggregating routes together – the routing table completely goes insane. Now I’d assume that TW would aggregate its customers into a /48 or something – god, I hope so! But still, we’re talking about a world where there are networks all over the place.

There’s a big question as to whether or not people ought to get provider-independent network addresses or not. I think I know the answer to this: No, they should not. It’s suicide. I think the real solution for this is at the DNS level – you should get addresses that correspond to your rough physical place on the internet to keep the routing tables somewhat simple, and if you want to move endpoints around, you change DNS entries. Get away from thinking of IP’s as static. If DNS were baked deeper into the protocol stack, this could work extremely well. Want to have a webserver at www.whatever.com? If you have some kind of authorization, your webserver would come up and use some kind of key exchange to somehow tell DNS that it is www.whatever.com. If you move, you just move your webserver. Your keys still work. If you set up a webserver in your house – same thing. Anyways, that’s just hand-waving. There still would have to be some way of bootstrapping that (like, what IP address do I contact the webserver at? Maybe you find that out by talking to your local gateway? Dunno)

<End Rant>

I guess that 1) wasn’t a little rant and 2) was a little rambly. So sue me.

6 thoughts on “IPv6”

  1. Proposing a backwards-compatible replacement for IPv6 is like proposing a water-powered car. Sure, it'd be nice to have, but unless you have an explanation for how it would actually work, you haven't really proposed anything.

    How is a host that only understands 32-bit addresses supposed to send packets back to a 128-bit address? And if you achieve that, then how is your solution better than NAT64?

  2. Fair enough, I guess I have to explain what my proposal would be. Please forgive the RFC-esque usage of SHALL and MUST and so on – don't take this as authoritative on anything. I will refer to my IPv6 tweak as "IPv7" for arguments sake.

    IPv7 space is an extension of IPv4 space. All IPv7 connected nodes must also be connected to the IPv4 internet directly. All IPv7 nodes must have an IPv4 address, though that address MAY be an RFC1918 address that is NAT'ed. If an IPv7 node attempts to transmit to an IPv7 address that maps into the IPv4 space, it MUST send IPv4 packets *only* to that node, using its IPv4 address.

    -or- we could say something like this – continue to use the IPv4 packet (datagram? whatever) format, and store additional addressing ("subaddressing" is how to think about it) information as a couple of new sets of 'options'. Hosts/networking devices/routers that don't understand them hopefully (?) pass them through unmolested, routers/firewalls that understand the options can pass packets directly back to "IPv7" hosts using regular routing. Routers/firewalls that *don't* understand the options would employ their conventional NAT connectivity and still be able to NAT TCP/UDP streams (perhaps?).

    So it's not fleshed out and not perfect, but I think these are better than what exists now. If we had a spec like this, all of our Dual-stacked machines that exist now (every computer with an operating system from the last few years) would be able to access stuff on the 'expanded' internet.

  3. Your first point is essentially saying that we need a way to make applications see the IPv4 and IPv6 Internet within the same address space, even though the wire format is different. This is basically solved by dual-stack sockets, with IPv4 mapped to the ::ffff:0:0/96 block.

    Instead of using "options", it would be much more compatible to embed the extended addressing information into the payload of the IPv4 packet. But that's how 6to4 and Teredo work: any computer with a Teredo client is already able to access stuff on the "expanded" internet, so it's not clear to me how your way is any better.

    Maybe you could imagine a world where *everything* uses Teredo, and there's no such thing as a "native" IPv6 packet, but the resulting network architecture would be so hideous that nobody would want to touch it.

    IPv6 deployment is happening slowly because people are lazy, not because there's something wrong with the protocol.

  4. #1) I think, if I am reading it right, that what you are talking about is only appropriate server-side. What about client-side? If I have a machine and attempt to transmit a packet to ::ffff:, where will it go? How will it be transmitted? I just did a traceroute6 to an IP I knew existed, and it didn't work. So, yes, using that space could be a helpful solution, but it's not mandated nor specified. Nor implemented, on my Mac (10.6.6).

    #2) No, I disagree. By just jamming stuff in the payload, only people who can interpret that payload can read the packet. If you put the subaddressing information into options, there might be a way to allow graceful degradation, so that compatible clients get end-to-end connectivity, and incompatible clients get NAT-like connectivity.

    #3) Yeah, that Everything Uses Teredo world is pretty gross, but that could be where we end up. Bleah.

    But finally – "people are lazy" – I think this is an interesting point. I disagree, but it's interesting. The only reasons entities do anything is because it will benefit them. Right now there is no benefit to adding IPv6 connectivity to services one provides. As a server, as an internetworking company provider, or as a network access provider. One might argue that adding IPv6 connectivity is a benefit – future-proofing. Or I could imagine an access provider – like Time Warner Cable for me – giving out IPv6 to people, and providing some kind of NAT'ing service to let them access the legacy internet. But the next logical step always is the same: well, if I'm Time Warner and I'm giving out IPv6 addresses and providing a big NAT infrastructure, why don't I just give out RFC1918 IPv4 addresses instead? And thus, we're back to Carrier NAT or Large Scale NAT or whatever.

    Maybe as the cost of acquiring new IPv4 space grows larger, IPv6 connectivity might become a 'cheaper' option? Then I could see carriers providing it (cheaper, doesn't use up IPv4 space?) and some price-sensitive companies using it – (doesn't cost us as much as IPv4 connectivity, let's use it!).

    But I think I prefer my Options idea better.

  5. You can't just extend address space everything(most things) are built to to RFC standard making the change you propose would mean going back and changing the IP stack of everything…

    And now you're talking about looking at additional options or the payload to make routing decisions..

    IPV6 is an improvement on IPV4

    And guess what

    and ping all work in IPV6

Leave a Reply

Your email address will not be published. Required fields are marked *