IPv6 and NAT... Again!

Anyway, I've been having a lot of conversations with people lately that have made me painfully aware of how badly skewed from reality are the mainstream views of a lot of technical people in IETF when it comes to thinking about Internet scalability and IPv6 transition engineering.  For a bit of background reading on why this is a hot topic in the IETF again, check out this and this.  From my perspective, they really really really do not seem to get how nesting NAT behind NAT affects scalability.

Let me simplify the discussion for my non-technical friends who may or may not be interested in this weirdness.  Here's the short, cruel truth: there aren't enough Internet addresses— IPv4, the version everyone uses, as opposed to IPv6, the version that nobody uses, okay: nobody who isn't trying too damned hard.  There aren't enough addresses for everybody who wants to connect to the Internet at the same time.  This has been the case for longer than most of you have been using the Internet.  I'd bet serious money on the proposition that most of the people reading this message right now are doing so without having a globally routed IPv4 address assigned to their network interface.  You've probably got a private, locally routed IPv4 address, of which you'd be hard pressed to deplete the number space even if you tried.  The shortage is in the globally routed ones.

The thing that translates between private addresses and global addresses for all your inbound and outbound packets is called a Network Address Translator (NAT).  They are a blessing and curse.  Mostly a curse.  They're a blessing because you only have to pay for one globally routed IPv4 address, no matter how many computers [practically] you have on your network.  They're a curse because they step all over your packets to do their work, and that means that lots of applications— i.e. cryptographic protection for route integrity, peer-to-peer application discovery and transport, etc.— either don't work very well, or don't work at all, depending.

The transition to IPv6 was supposed to make NAT unnecessary, but for various reasons, the transition to IPv6 isn't happening.  So, the IETF is busy humping up yet another bandage over the problem, i.e. to make the transition less painful by designing new and interesting ways to do IPv4 Network Address Translation.  The new idea is to do the translation across the IPv4/IPv6 realm boundary, as opposed to just the IPv4 private/global realm boundary.  (Yes, the term "realm boundary" is geeky technical term.  It means the border between one addressing system and another, where each address identifies a unique entity, but only within the "realm" defined by the scope of its addressing system.)

I do not envy Fred Baker, the chair of the V6OPS working group.  Dude has a near impossible job: keep the debate over how to proceed from spiraling into higher and higher orders of non-linearity.  I think there are at least five different competing proposals for how to split up the various functions that comprise a NAT, so that different parts can be deployed in locations in the network.  There are a lot of disagreements between factions.

A faction I find particularly confusing is the [fairly sizable] one that believes moving the IPv4/NAT function deeper into the network, and closer to the default-free zone, is a useful way to keep IPv4-only nodes functional while the rest of the world moves to IPv6.  These people confuse me because I'm not sure how it's possible to be so badly warped.  Do you have to take a pill for that?  Or, does your brain produce it naturally?

Many of these people seem to believe that the ratio of privately addressed nodes to public addresses used by NAT routers is effectively unbounded.  Or if they do think about the bounds, they don't think very hard.  I can't tell.  Let's take the simple case of TCP, simple because all communication is between a single pair of endpoint addresses, which each comprise a 32-bit IPv4 address and a 16-bit port number.  Looking up a NAT state record in a table involves searching a dictionary for 96 bits of key, two 32-bit IPv4 addresses and a pair of 16-bit port numbers.  You have to look up a state record for every packet you forward, so tree search needs to be FAST.  It yields the other 48 bits you need to do the translation, i.e. a new IPv4 address and a new port number to replace the old ones from the originating address realm.

The real scaling problem enters when you consider the passive listener case.  How many passive TCP listeners, waiting to accept inbound connections at private addresses can you stack up behind a single global public address? Around 49152— less than that if you're being polite.  And that's assuming that you have a protocol like NAT-PMP to help with the assignments.  Basically, NAT rules (the things that decide when to create a state record) have only the inbound TCP destination port with which to disambiguate inbound flows.

Look at that more closely: if you're making only outbound connections to servers and global addresses (typically in corporate data centers with high bandwidth links to peering points close to the MAE's) then your NAT gives you 65,536 times more scaling capacity than if you're only passively listening for inbound connections.

Gee, I wonder who gets the short end of that deal in the long run.

Actually, no, I don't wonder.  These schemes are all promoted by people whose business models are severely threatened by anything that works by cutting the corporate data center out of the loop between peer-to-peer endpoints on the Internet.

Naturally, these people are less than thrilled about technology that promises to get in the way of this kind of asymmetry, which is the sort that their business models have depended on for more than a century now.  IPv6 is one such technology, and there's the answer to your question about why IPv6 transition hasn't really happened.  The "business case" for it hasn't been very apparent to the severely bell-shaped heads in the room until recently.

So, now they've got an "address free pool crisis" and they're looking for ways to cram yet more private IPv4 leaf nodes behind a single global IPv4 address to facilitate their centralized network model.  That's what the proposals I saw today were about.  The differences were all about where the invisible IPv6 tunnel should be terminated.

I have an idea.  Why don't we move IPv6 to HISTORICAL status, and design an extension to IPv4 that adds a header option for carrying a 96-bit flow identifier, roughly similar in function to the verification tag in SCTP, and we'll add a few more bits to it for establishing and releasing flows between endpoints.  We'll teach the NAT boxes to forward to private addresses based on the contents of flow identifiers observed in the packets.  It won't be nearly as elegant as IPv6, and it will be fragile and brittle, and it will blow smelly goats, but it can be made backward compatible with unmodified IPv4, and it will stop the otherwise inevitable trend toward making the Internet into a 21st century version of the Bell System by preserving the symmetry scalability for inbound and outbound connectivity.

Or not. It could be that I'm still too jet-lagged to think straight.  Can't write anymore.  This is where I stop for now.  More later.  Depending on if I'm still peeved.