Slashdot Mirror
Accelerating IPv6 Adoption With Proxy Servers
jgarzik writes "IPv6 presents a catch-22: the most popular web sites on the Internet
don't have any incentive to switch to IPv6 until a large portion
of their userbase is on IPv6, and their user base does not have a
large incentive to switch to IPv6 until many of the popular Internet
destinations support IPv6. My proposed solution is simple: Configure a proxy server that
serves IPv6 requests, passing those requests through
to underlying IPv4-only servers that not have yet been transitioned
to IPv6.
This article describes how to configure Apache's proxy server to fill this role, and suggests a few ideas for use."
IPv6 was primarily designed to solve a *problem*.
That problem was IPv4 address space exhaustion.
If the problem isn't hurting people on either side (client or server), then there is no reason for them to migrate to IPv6.
For people in certain heavy net using countries (such as Japan and S. Korea) which have received a smaller slice of the IPv4 pie, then there is more incentive to move; for the vast bulk of the world there is very little incentive to move to IPv6.
Nice try, but that's not a Catch-22.
A Catch-22 is when the solution creates the problem. From the book (yes, there was a book) if the doctor diagnosed you as crazy, you didn't have to fly any more bombing missions. The catch was that you would have to be diagnosed crazy by a doctor to want to fly more bombing missions. Thus, by achieving the status of "unfit to fly", you were actually certifying yourself to fly.
What we have here with IPv6 is two parties with no immediate reward for an investment. If one of them stepped forward, the other would step forward, and the world would enjoy IPv6. There is nothing about this that is remotely close to a Catch-22.
That killer app may be VoIP. If everyone wants their own IPv6 phone number.
Or that killer app may be someone coming up with an awesome spam/virus/security solution that requires features found in IPv6.
But just wanting people to switch for no good reason will never work. Market forces...
Ironically, the word ironically is often used incorrectly.
The intention with IPv6 is that you won't have "unroutable" networks, like we do with private nets such as 10.x.x.x and 192.168.x.x. Everything will have a globally unique IPv6 address. There was in the original spec what were called a "site-local" addresses, which were private addresses not routed to the outside much like their IPv4 analogues, but those have been deprecated.
However, you'll have plenty of addresses because, in the current incarnation, you're not allocated a single address, but rather you are allocated a subnetwork, which is currently 2^64 addresses. So the first 64 bits are assigned to you by your ISP, and then the second 64 bits are yours to do with as you like.
So that addresses the question of NAT: there won't be any lack of IP addresses necessitating its use. I am only addressing the use of NAT as a way around limited address space, and not any of the other uses for which NAT has.
But what about DHCP? IPv6 comes with something more elementary, called "stateless autoconfiguration." Basically, the router constantly broadcasts your "prefix" to the subnetwork, which is the first 64 bit half of your 128 bit address your ISP assigns you. The machine then takes its subnetwork ID (the MAC address), and sets the second 64 bits to a function of that. In the case of Ethernet, it isn't the 48-bit Ethernet MAC address verbatim, but a published function of it. It's called stateless because it's always a function of whatever the network's prefix is plus some kind of subnet ID, and there's no concept of leases, or any of the state a DHCP server maintains.
There is not yet an equivalent mechanism for "stateful autoconfiguration," which is more what DHCP is, where you can automatically assign an arbitrary address to a client. You can of course statically configure an interface to have a specific address, but there is no automated mechanism to always assign a particular autoconfigured client a particular address you designate. There are proposed standards for an IPv6 version of DHCP, however, and I expect eventually such a beast will eventually come around.
Oh, yeah, I forgot one more point:
Whether or not your "prefix" changes each time will be much the same as whether or not your single IPv4 address changes each time you connect. Either your ISP statically assigns you one (perhaps for an extra fee), or it doesn't. But that 64-bit prefix will be your global identifier that gives you an address space, much as the single IPv4 address is your global identifier now, except your address space is only 1 address.
Okay, I won't argue with you there.
It's deliberate overkill. It allows things like 64-bit subnets, which in turn allow for stateful autoconfiguration. It also allows for large chunks of address space that won't be allocated at all; if it turns out in the future that our current allocation method is inadequate for our needs, we can simply devise a new allocation method in this empty space, rather than having to migrate to a whole new version of IP.
Yes, if an IPv6 router had to hold nearly 150,000 routes in memory like it does in the current IPv4 world, it would be massive. Fortunately, IPv6 is designed to have properly aggregated addresses, so that things are much more hierarchical, and routing tables can be stored much more efficiently.
Aside from the fact that more and more connections are using much larger MTUs these days, IPv6 also supports more aggressive header compression than IPv4 did, often resulting in similarly compact headers.
\\'
Bah, that's nothing. My proxy converts first posts on slashdot into insightful comments!
The Tao of math: The numbers you can count are not the real numbers.