10 posts tagged “ietf”
Apparently, the ghost of Jon Postel is leading a pack of superheroes determined to defend the Internet from Fear Uncertainty and Doubt. Promote The Internet Way with Team ARIN!
Welcome to the world of Team ARIN! We hope you find these publications educational and entertaining. Team ARIN is a fictionalized view of the American Registry for Internet Numbers (ARIN), its processes, and the whole concept of Internet governance. Though our heroes are fictional, the issues they face are very real.
Team ARIN is a group of superheroes that represent four of the principles by which the Internet is operated and governed...
An interesting Internet Draft came over the transom today: Behavior of BitTorrent in an IP Shared Address Environment. Here's the abstract:
This memo describes the behaviour of BitTorrent service in the context of IP shared addresses. It provides an overview of the used testbed and main results of the tests that have been conducted in order to assess the limitations of an architecture based on shared IP addresses.
You may be familiar with BitTorrent. It's the protocol used by various software applications that allow you to find and download LargeMediaFiles, e.g. music, videos, etc., often under questionable interpretations of international copyright and digital anticircumvention laws.
The phrase "shared IP addresses" might not be familiar to you. Here's the section of the draft that tries to explain the concept.
Recently, several proposals have been disseminated within IETF to
contribute to solve the IP exhaustion problem. These solutions may
be grouped into two categories:
(1) Solutions which propose the introduction of a second level of
NAT (Network Address Translator), denoted also as Carrier Grade
NAT (CG-NAT). This node is located in the Service Provider
domain. Private addresses are assigned to end-user CPEs, which
still perform their own NAT. The CG-NAT is responsible for
translating IP packets issued with private addresses to ones with
publicly routable IPv4 addresses (especially when exiting the
domain of the Service Provider).
[ID.durand-softwire-dual-stack-lite] is a variant of these
solutions where there is only one NAT hosted in the Service
Provider's network.
(2) Solutions which avoid the introduction of a NAT in the Service
Provider's network. Examples of these solutions are
[ID.ymbk-aplusp], [ID.boucadair-port-range], [ID.despres-sam] and
[ID.bajko-v6ops-port-restricted-ipaddr-assign]. These solutions
allocate the same IP public address to several customers at the
same time. They also allocate a restricted port range to each
customer so that two customers with the same IP address have two
different port ranges that do not overlap.
Both the above listed categories are based on sharing an IP address
between several machines. In this context, the delivery of some
services may be impacted, especially those enforcing a restriction
based on the source IP address.Now is a good time to note that the IP exhaustion problem is very real and it's a pressing concern for Internet service providers. These shared IP address proposals are aimed at finding a way to cope with the fact that uptake of IPv6 has not really happened, and something needs to be done to meet the projected growth in demand for Internet service when IPv4 is the only thing anybody wants.
So, what are the "main results of the tests" the draft reports? I'll summarize the conclusion for you: as long as A) the BitTorrent clients flip their allow_same_ip bits from FALSE to TRUE, and B) you don't exhaust the restricted range of ports, then everything seems to work fine. Otherwise, things are intolerably slow, so you can bet that BitTorrent clients are going to switch their default configurations one by one until they all do it.
It's the rocks of the restricted port range exhaustion problem upon which BitTorrent will be wrecked.
Today, if you're a BitTorrent user (and you're not a freeloader), then you've probably got a handful of TCP connections open to various peers at all times. These don't eat a very large portion of the full 16-bit port range, so you don't notice them when you're surfing the web or doing other things with your Internet service. But they'll certainly eat a very large portion of the restricted port range your ISP will allocate to your NAT gateway from the IP address you're sharing with everybody in your neighborhood.
So what will happen? Your web applications, like Facebook, will start to suck — mostly the ones that involve a lot of Web 2.0 features where the browser has to open a lot of TCP connections to a whole bunch of different addresses if it's going to render your page properly. Word will get around: you can do BitTorrent, or you can do Facebook, but not both at the same time. Guess which one will get turned off. That's right, the one that isn't delivering immediate gratification. How long will it stay turned off? Will it get turned back on?
BitTorrent works because people leave their clients turned on when they're not downloading anymore so they can pass the bits along to the next client that wants to download the same file. It's predicated on the idea that it doesn't cost the downloader anything extra to do this. With these new shared IP address regimes, all that changes. Load on the seeders will go up. The number of freeloaders will increase dramatically. Overlay operators will have to respond by making BitTorrent suck for all clients behind shared IP address NAT gateways in order to prevent them from ruining the party for everybody else.
"But, wait! BitTorrent over Teredo will save the day," I hear you thinking.
Sadly, no. It. Won't. Teredo depends on service providers deploying functioning relay routers. It's also easy for service providers to block access to independent relay operators, especially in a shared IP address regime where the relay needs to know about the port restriction. As you may have noticed, service providers haven't been deploying relays. What you may not have noticed is that service providers are also blocking access to independent relays. There really isn't anything the BitTorrent trackers can do to help here without damaging the utility of Teredo as an IPv6 transition mechanism.
"It's okay. BitTorrent users will just migrate to service providers that don't run shared IP address networks," I see you grasping.
Oh, really? And how much extra per month do you think BitTorrent users are willing to pay for Internet service that assigns their NAT gateway a full public IPv4 address? And did you think about what it means that service providers have a sorting function now that moves all the BitTorrent users into a class of service that nobody else needs or wants. Think about it: if you're the lowest common denominator user, and you don't use BitTorrent, you'll save the ten euros per month and go with the share IP address service; if you're somebody who really needs static IP addresses because you have servers at your house with addresses named in the DNS, then you're going to spend the extra euros for the pro-level SOHO service where you get a block of static addresses assigned to your home network.
The only people who really need the kind of service that seems ubiquitous now, i.e. the dynamically assigned single public IPv4 address at the NAT router, are the BitTorrent users. If you're a service provider, then you'll probably just eliminate that kind of service entirely as soon as you can. As an Internet user, you will have only two choices available soon: A) low-cost shared IP address service unsuitable for regular use with BitTorrent (and lots of other weird applications), and B) expensive full statically allocated IP address service almost like what John Gilmore would want.
Do not think any of this is an accident. It is not. Service providers hate BitTorrent users because they blow out their pretty traffic engineering models, so anything that makes them unhappy and forces them into the pro-tier of service is worthwhile on general principle. One of the main reasons the service providers hated IPv6 so much is that, rather than make P2P networks harder for their customers to create and operate, it actually makes them easier. Blech! Must kill IPv6 with extreme prejudice.
So, this is why I think I can predict that BitTorrent is likely to go the way of Usenet. It was fun while it lasted, me hearties, wasn't it?
Via Slashdot, I find a piece in Wired about how the U.S. government is trying to force DNSSEC on the root zone file. The idea here is that DNSSEC is the only "sure" way to close the DNS cache poisoning problem that Dan Kaminsky publicized earlier this year.
There's one problem. It doesn't completely close the hole.
The DNSSEC extension is a way for DNS resolvers to use the Public Key Infrastructure (PKI) to validate the signatures on the records they obtain through recursive queries. As long as you trust the PKI, and the chain of trust leading to the root certificates used to sign the root zone file, then you can have a cryptographically secure guarantee that the DNS answers you're getting really from the people who own the zones from which they originate.
The trouble is that most normal people don't have recursive resolvers running on their computers, and the DNS would melt down if they all did. All the major operating systems and even embedded devices that use DNS send non-recursive queries to a caching resolver proxy, typically operated by your ISP. If you've ever used OpenDNS, then you understand why trusting your ISP to cache the DNS for you can be risky. (And, if you've ever installed your own recursive resolver proxy, then I'm probably preaching to the choir in this post.)
So, how does DNSSEC work in the presence for caching resolver proxies? It's complicated by the fact that DNSSEC typically uses messages of sizes too large for the original DNS protocol specification, so both the resolver and the server need to do one (and preferably both) of the following: A) support DNS over TCP; and B) support the DNS extensions that allow DNSSEC to work without blowing the UDP size limit.
Another complication is the proliferation of NAT in residential gateways. Read all about the technical details regard DNSSEC and such devices here. The basic issue is that these boxes all have forwarding proxies in them, and almost none of them fully support DNSSEC properly because they A) don't implement TCP service, and B) don't handle the extensions properly to support DNSSEC over UDP.
The executive summary here is that signing the root zone will allow your ISP to defend its DNS caches against poisoning attacks, but it's not likely to do you any good until your home router supports DNSSEC as well. Does yours? Mine does, as long as the DNS client properly falls back to TCP for messages that are too large for UDP, which is the case for all the major operating systems I know about. (It doesn't like the UDP extensions.)
I'm here in Dublin, Ireland attending IETF 72. The weather is hot— or it is, if you're acclimated to the peculiar microclimate of San Francisco, where summertime means fog, drizzle, wet fog, fog, rain, drizzle, fog, haze and more fog. There is apparently a world-class golf course a few meters away from me. I couldn't bring myself to care enough to look.
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.
I'm vastly amused by this.
When businesses want to communicate with their customers via e-mail, many send messages with a bogus return address, e.g. "somethinghere@donotreply.com." The practice is meant to communicate to recipients that any replies will go unread.
But when those messages are sent to an inactive e-mail address or the recipient ignores the instruction and replies anyway, the missives don't just disappear into the digital ether.
Instead, they land in Chet Faliszek's e-mail box.
There's a lesson here for protocol architects.
Some people will rely on the system your protocol enables without really understanding how it all works. Their ignorance can make it surprisingly easy for them to do things by mistake that have very serious security consequences for themselves and, potentially, for everyone.
Other people, who understand how the system works, and the protocols that enable it, will discovery these interesting vulnerabilities. They will then exploit them with varying degrees of malice aforethought.
Now, imagine for a moment that Chet Faliszek were one of these people, i.e. someone who does business with phishers and spam gangs, or who is a spammer or a phisher, instead of someone who seems to have taken an interest in trying to educate people who are otherwise dangerously ignorant. In a way, that would make it easier to rip the domain away from him by force and hand it over to some kind of regulated public entity. But, Chet Faliszek isn't doing anything wrong— yet— and, as a result, there is a continuing risk to the system posed by the dumbass convention of using donotreply.com as if it were a reserved domain name.
I don't know how to design protocols that don't have this kind of weakness in them. It seems like a real problem. Maybe, an intractable one. I wish there were a good system for minimizing the system risks inherent in a protocol architecture prior to its widespread adoption. I don't think there is one.
I think it's just a matter of making sure your architects aren't treated like dog-crap.
Google has pulled the IPv6 trigger. If you have good IPv6 connectivity, then you can see the dancing Google logo. If you're still in the camp who likes beating yourself in the head with the IPv6 hammer, then this will be welcome news to you.
I certainly don't want to disparage Google's efforts here. As near as I can tell from a cursory examination sitting here at IETF 71, they've done everything right— if only a little bit later than I would have advised.
Now, if only it will make any good goddamn difference.
It's time to start talking about what the Internet will be like in a future where we abandon all our efforts toward the IPv6 transition. Because the transition isn't happening. It's not going to happen. We're going to be living on IPv4/NAT for the rest of our lives.
Many people who get to be called "experts" in their personal biographies think IPv6 is a solution in search of a problem. They can make a strong argument for their case:
- There is no shortage of IPv4 addresses, because NAT allows more than one user to share the same address.
- When the IPv4 address free pool runs out, the Regional Internet Registries can become title companies and address allocations will become commodities traded in the market.
- The costs and benefits of just limping along forever with an IPv4/NAT-only architecture are predictable and well-understood, but the costs and benefits of investing in an expansion to IPv6 is full of uncertainty about both costs and benefits.
So let's talk about what the future they're planning for us looks like. Because we're going to be living in it. Trust me. We are.
NAT is the principle reason that depletion of the free IPv4 address pool hasn't already happened. It was adopted mainly to permit small organizations to multihome efficiently. Nevertheless, the free pool continues to be depleted. Routes in the default-free zone are not aggregating at the rate backbone operators had hoped. Further growth is increasingly coming to depend on the deployment of multiply nested private routing realms, i.e. NAT behind NAT.
There's a limit to how deeply you can stack endpoint nodes behind a single globally routed IPv4 address. It's not a brightly defined limit. It's vague and fuzzy, but it it's a limit. Applications on those nodes are multiplexed into a global address with a single 16-bit port number. The limit shows up sooner with transport protocols other than TCP, so the deeper you stack these NAT devices, the more you limit the ability of Internet applications to use any transport protocol other than TCP. Ubiquitous multilevel NAT means the Internet becomes a system for making TCP connections.
Oh, we'll try multiplexing multiple transports over a single TCP connection. And we'll discover how badly those tunneled transports perform because of how the outer TCP rate control and congestion avoidance mechanisms interfere with the inner transport mechanisms. We'll soon find out what my employers discovered years ago, when they tried to make this stuff work, that multiplexing over TCP is a sucker's game. Just open more than one TCP connection. But the more TCP connections your endpoint node needs, the fewer endpoints you can stack up behind a global IPv4 address— which means you can only expect to get so much out of stacking NAT behind NAT behind NAT. How much? It depends on how many TCP connections per second you expect to serve from the average endpoint node on the Internet. How many do you think YOU need? Do you have any idea? Do you think this guy does?
Let's also talk about how IPv4 addresses are going to be allocated to new organizations after the free pool is exhausted in the next few years. Conservative estimates have the free pool lasting only a couple more years. Some of the more liberal ones see it lasting into the middle of the next decade. Does anyone here think we won't see it within the space of our working lifetimes?
At the moment, IPv4 address blocks are not private property. All the Internet registries have policies for reclaiming unused allocations for reassignment. Because there are still addresses in the free pool, the application of these policies hasn't inconvenienced anyone. To keep your allocation, you basically just have to be able to fog a mirror. When no more IPv4 addresses can be assigned without reclaiming them from prior assignments, those policies will start getting teeth that leave real bite marks on people.
To get the Internet registries out of the business of adjudicating disputes over allocation policy enforcement matters, they'll have to become title companies just like the IPv6-is-stupid camp claims. Yes. Yes, it's true. So, let's imagine for just a moment what kind of political clusterfnork will break out they day the registries start issuing official deeds to the legacy allocations that were made years and years ago when only Senator Gore and a few hippies thought it would ever amount to anything of lasting commercial value. Take a gander at the names on that list:
Prefix Designation ----- ------ 003/8 General Electric Company 004/8 Level 3 Communications, Inc. 006/8 Army Information Systems Center 008/8 Level 3 Communications, Inc. 009/8 IBM 011/8 DoD Intel Information Systems 012/8 AT&T Bell Laboratories 013/8 Xerox Corporation 015/8 Hewlett-Packard Company 016/8 Digital Equipment Corporation 017/8 Apple Computer Inc. 018/8 MIT 019/8 Ford Motor Company 020/8 Computer Sciences Corporation 021/8 DDN-RVN 022/8 Defense Information Systems Agency 025/8 UK Ministry of Defence 026/8 Defense Information Systems Agency 028/8 DSI-North 029/8 Defense Information Systems Agency 030/8 Defense Information Systems Agency 032/8 AT&T Global Network Services 033/8 DLA Systems Automation Center 034/8 Halliburton Company 035/8 MERIT Computer Network 038/8 Performance Systems International 040/8 Eli Lily & Company 043/8 Japan Inet 044/8 Amateur Radio Digital Communications 045/8 Interop Show Network 047/8 Bell-Northern Research 048/8 Prudential Securities Inc. 051/8 Deparment of Social Security of UK 052/8 E.I. duPont de Nemours and Co., Inc. 053/8 Cap Debis CCS 054/8 Merck and Co., Inc. 055/8 DoD Network Information Center 056/8 US Postal Service 057/8 SITA
How much do we ask those organizations to pay today for the deeds to the allocations they got all those years ago. Nothing? Yeah, that's gonna fly in United Nations organizations. So, let's imagine a non-zero number instead. Just for grins, let's propose that the dollar value of a global IPv4 /8 allocation is US$100M per year. That's about US$5.96 per address per year.
Are you going to be the one who goes to Halliburton and tells them that they owe the Internet US$100M/year (retroactive?) for the continued use of the 34/8 network? How about the U.S. Postal Service? The U.S. Defense Information Systems Agency? What are you going to do when they tell you to Go Cheney Yourselves? Take their addresses away? How do you propose to do that? The truth is, nobody will do that.
What we'll get is not a transparent and free market in IPv4 address allocations. Instead, what we'll get is a patchwork system where the legacy allocations remain mostly in place, and the allocations controlled by the Internet registries are subject to a variety of policies, most of which will be the subject of heated disputes in organizations like the World Trade Organization.
Sure, some address allocations will be obtainable through market processes, but not most, and certainly not all. And the allocations won't really be the same as real estate, so organizations will still have to take out insurance policies to cover the risks of having their addresses called out from under them and having to pay for renumbering.
Better still: imagine you're in the business of squatting on domain names today. It's pretty easy to see that a market is going to be opening up soon allowing you to speculate on the future value of IPv4 address allocations. What would you do? You'd be trying to eat up as much of that free pool as you can before it's all gone.
Now imagine you're the organization trying to figure out how to make a market in address allocations. You've got to figure out how to do it without giving the speculators an opportunity to profit by inducing market failure in the first few iterations before the system stabilizes. You got any ideas? If you do, then I'd like to hear them. I have a lot of smart friends who are keenly interested in figuring this stuff out, and it's giving them big headaches right now.
The costs of maintaining a globally routed IPv4 address are about to go up. Maybe by several multiples. Probably very quickly. Market prices for commodities with a severe supply disruption and a dysfunctional system for clearing transactions tend to swing violently. Ultimately, all these cash flows have to add up. So, what does that mean?
The monthly bill from your ISP is about to have an uncertain new fraction of it devoted to the cost of maintaining that globally routed IPv4 address you're using (and possibly sharing with your neighbors). How much? Nobody knows. You might as well ask how much your bank is going to lose this year on the global implosion of credit markets.
Nobody knows. It could be pennies a year. It could be the better part of a hundred dollars a month. Nobody knows. Nobody freaking knows.
Now, IPv6 proponents think that the cost of maintaining IPv4 address allocations will drive the transition to IPv6. I'm not so sure. In fact, I'm thinking that's Yet More Kool-Aid. There is no cost for IPv4/NAT high enough to drive adoption of IPv6, because IPv6 will never be an alternative to IPv4. The Internet will turn out to be, always and forever, the IPv4/NAT-only Internet we have today. If current IPv6 usage doesn't fall off when its early adopters finally capitulate, then it will always be nothing more than an experimental platform for specialized research applications. And IPv6 wasn't designed to be that. It makes a lousy research platform.
Contrary to what the IPv6 detractors say, i.e. that the failing of IPv6 is that it isn't sufficiently compatible with the IPv4/NAT we have today, I have now come to believe that the principle failure of IPv6 is that it wasn't enough of a departure.
This week, I'll be in Philadelphia, PA for IETF 71. I'll be grateful for any suggestions for what to do in the evenings after my sessions are over. I understand there is a beer festival of some kind. I'll be trying to organize my fellow IETF cats to go do something with that. I may lose. We'll see.
The context for today's rant is the rapidly approaching Internet Address Space Crisis. This topic has been on my mind a lot lately, for a variety of professional reasons, many of them related to the constellation of issues that got me invited to be the Technical Editor for an Internet-Draft in the V6OPS working group of IETF on the subject of Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service. Lately, the urgency of public calls for accelerating the transition of the Internet to IPv6 have grown louder, and so have the heat surrounding the arguments revolving around...
- Why IPv6 Sucks Balls
- How IPv6 Is So Amazingly Bad At Sucking Balls
and most importantly...
- Who's To Blame For The Fact That The Internet Needs To Transition To A Next Generation Protocol That Sucks Balls So Badly Right Now.
I've had just about as much as I can take of this. A lot of people who should know better have said a lot of stupid things about this problem, but there's one particular stupid thing that a lot of them have said that really drives me up the goddamn wall, and here is where I'm composing my answer to them. Who are some of these people?
First, it was Daniel J. Bernstein complaining about how...
Unfortunately, the straightforward transition plan described above does not work with the current IPv6 specifications. The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
IPv6 is Incompatible with IPv4 on the Wire!
The Stupidity and Short-
Sighted Arrogance of this
is Utterly Mind-Blowing
Could have been avoided, e.g. if IPv6
had variable length addressing, IPv4
could have become the 32 bit variant.
These people are extremely senior computer scientists. Widely regarded as brilliant super-geniuses. Deny the truth and correctness of their dissertations at grave peril to your reputation. Or, so it's supposed. There are a lot of others who keep trotting out this nonsense. Big name Internet greybeards. I don't understand what is their major malfunction.
Okay. So, what's wrong with this argument?
On the surface, it seems sensible. When the North American Numbering Plan started running out of area codes, they had to transition to a system that allowed the middle digit in the area code to be a number other than one or zero. It was a mess, but nobody had to upgrade their telephones to be able to dial the new telephone numbers. A slightly more applicable analogy arose with overlay plans, which are the reason many Americans are now required to dial ten digits instead of seven.
Alas, if you drill a little deeper, the distinction between IPv6 being an alternative to IPv4 and it being an extension to IPv4 is completely illusory. Yes, I'm saying that Dan Bernstein is missing the point, and the Randy Bush is actively avoiding it.
To begin with, let's just observe that every IPv4 address is also an IPv6 address. The IPv4 address for my home server is currently 69.12.155.90. Can you guess what IPv6 address that is? Hint: it's really easy. It's 0000:0000:0000:0000:0000:0000:450c:9b5a. All those preceding zeroes are usually collapsed into a '::' prefix, so that address might be more easily written as ::450c:9b5a. And since this address is in the reserve IPv6 prefix for IPv4 addresses, i.e. ::/96, it's actually more commonly written as ::69.12.155.90.
This is cheating, I hear you bleat. My home server isn't reachable at that IPv6 address. Look up the AAAA record for conjury.org and this is what it says:
~ 501$ dig aaaa conjury.org
; <<>> DiG 9.4.1-P1 <<>> aaaa conjury.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28106
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4;; QUESTION SECTION:
;conjury.org. IN AAAA;; ANSWER SECTION:
conjury.org. 86400 IN AAAA 2001:5a8:4:2290::2;; AUTHORITY SECTION:
conjury.org. 119 IN NS c.auth-ns.sonic.net.
conjury.org. 119 IN NS grymling.conjury.org.
conjury.org. 119 IN NS a.auth-ns.sonic.net.
conjury.org. 119 IN NS b.auth-ns.sonic.net.;; ADDITIONAL SECTION:
c.auth-ns.sonic.net. 32092 IN A 69.9.186.104
grymling.conjury.org. 58152 IN A 69.12.155.90
a.auth-ns.sonic.net. 9576 IN A 209.204.159.20
b.auth-ns.sonic.net. 61677 IN A 64.142.88.72;; Query time: 24 msec
;; SERVER: 17.206.12.12#53(17.206.12.12)
;; WHEN: Fri Feb 22 17:21:58 2008
;; MSG SIZE rcvd: 220
This is not ::69.12.155.90. There's no point in making any of the addresses in ::/96 reachable over IPv6. Any nodes that are reachable over IPv4 do not need to be reachable over IPv6 at their IPv4-compatible addresses. They're reachable over IPv4. Use IPv4 when communicating with them. In any case, IPv6 addresses are completely backward compatible with IPv4 addresses, i.e. it's trivial to use IPv6 addresses to identify all the same things identified today by IPv4 addresses. Just pad the upper 96 bits with zeroes. You're done.
"But wait," you say. "Look at the IPv6 header and packet format. It's completely different from the IPv4 header and packet format! Surely, they're not compatible on the wire!" Ah, look closely my young initiate.
Here's the IPv4 header:
+ Bits 0–3 4–7 8–15 16–18 19–31 0 Version Header length Type of Service
(now DiffServ and ECN)Total Length 32 Identification Flags Fragment Offset 64 Time to Live Protocol Header Checksum 96 Source Address 128 Destination Address 160 Options 160
or
192+
Data
Here's the IPv6 header:
Look very closely at the first four bits of the each header. That version field is there for a goddamn reason. See, in IPv4, the value in that field is a 4. In IPv6, the value in that field is a 6. It's how you tell the difference between an IPv4 header and an IPv6 header when all you have are the raw bits.
The Internet Protocol has ALWAYS had extensible addressing and packet formats. Every version of the protocol ever designed had the first four bits reserved for identifying the Version of the Internet Protocol in use. IPv4 is the 32 bit variant of the Internet Protocol. That's what that 4 is doing there taking up all that valuable space on the wire in the goddamn IPv4 header.
Bernstein goes on a long rant in his piece. Here's an illustrative excerpt...
[...]
Keith [Moore], there is one network that has aol.com and cnn.com and cs.utk.edu and an incredible number of other sites.
Normal people call this network ``the Internet.'' They insist on being connected to the Internet, so that they can exchange email and web pages and so on with other Internet sites.
The universe you're imagining, in which sites are split across two global networks that have trouble talking to each other, is an ancient historical mistake that will never be repeated. What kind of idiot would be the first to disconnect his site from the original Internet in favor of the new Internet? Why haven't you cut yourself off from IPv4, Keith?
[...]
Except, the universe where IPv6 and IPv4 coexist properly is a single global network. All those useful sites Bernstein is talking about are all on that network. It's called the Internet, and all those sites are reachable today on it by IPv4. Soon, when those sites want to communicate with other nodes that can get affordable IPv6 service but not IPv4 service— which is what the IPv4 Address Crisis is all about— all those legacy sites, e.g. google.com, cnn.com and playboy.com, will be reachable by IPv6 as well. Or they will be replaced by competitors who are.
So please— spare me the crap about how the designers of IPv6 failed to consider the engineering issues surrounding transition properly. They did make a couple major mistakes, e.g. site-local address scoping, excessively loose source routing, et cetera— but those are all ancient history now. The remaining minor issues are lot less intractable than you think. IPv6 would be ready for industrial use today, except for the sad fact that network operators— yes, if you've read all the way this far, and you think I'm talking about you personally, then I probably am— are deliberating trying to impede the progress of transition to IPv6 by making it harder to deploy than it needs to be.
More on all that later. I gotta run to catch a commuter shuttle.
I continue rewriting Arts Of The Wize. The manuscript is now 192 pages, and it's about half completed. The BookHate is almost overpowering now. I can't remember when I started this project, and the only thing that keeps me from quitting at this point is the shame I would feel for having spent so much of my disposable free time only to abandon it before even receiving a single rejection notice. That would be undescribably lame.
I like my characters, and I like the world I've imagined for them (especially the world of my rewrite, which is a bit different than the first one). I like the story. There is just no way in hell it will sell.
How do I know this? I know it, because I'm dismayed at the prospects of trying to write a 100-word hook for Arts Of The Wize that will make it seem both fresh and interesting to a literary agent or publisher. Meanwhile, I've still got about another 200 pages to go with about 300 pages of first draft to use for raw material. Today, I actually gave serious consideration to the idea of adding a talking squid to Chapter Fourteen, just because I figured that would round out the collection. I'm imagining the conversation with the hypothetical agent who gets suckered into asking for my full manuscript.
"So, J.H.— why'd you put a talking squid here?"
"Because it's fantasy, not science fiction, but it's already got spaceships and robots, so I figured— hey, why not complete the set with talking squids?"
"Lose the squid."
"Could you sell it if I took it out?"
"Um… well…"
"You were just playing me there, weren't you?"
"Can you blame me? It was a moment of weakness. Freakin' talking squid. WTF is wrong wit you?"
In other [completely unrelated] news, I'm very close to releasing an Internet Draft that I expect will go over like a lead balloon in the V6OPS and IPV6 working groups. I'll post a link to it here when it goes up on the IETF.Org servers. So far, readers to whom I've privately circulated it have reacted with a collective Why-The-Fnork-Are-You-Doing-This? I wish I had a good answer to that. The truth is abjectly, painfully embarrassing, i.e. no one else is dumb enough to bring this idea up in front of the IETF, and it's my job to be this goddamn dumb.
Secretly, there is a part of me that hopes my idea will be so obviously dumb that everyone will come to their senses and realize that network layer policy-enforcing packet filters in organizational-boundary IPv6 routers are just a phenomenally bad idea, and we should have never listened to anybody who wrongly insisted they were essential for proper functioning of the Internet. My worst fear, actually, is that IETF might actually take the idea I've been tasked with championing seriously enough to make it a standards-track effort. At that point, firewalls in your ISP will be able to collect vast amounts of information about what software you are running and for what purpose, even if your computer doesn't actively communicate with anyone else. When I think about what a Big Brother authoritarian could do with the protocol I'm proposing, it makes my blood run cold, and my boss is insisting I fight for this thing in the IETF.
Now, do you see how talking squids could seem like a good idea to me? (Okay, okay— losing the squid. Jeebus.)
My Groups
-
Writers Hub Updated: 1 hour ago
-
Amnesty International Updated: 1 hour ago
Neighborhood
Explore friends, family, friends & family, or entire neighborhood.
