Proposed IPv6 Cutover By 2011-01-01

IO ERROR writes "An internet-draft published this month calls for an IPv6 transition plan which would require all Internet-facing servers to have IPv6 connectivity on or before January 1, 2011. 'Engineer and author John Curran proposes that migration to IPv6 happen in three stages. The first stage, which would happen between now and the end of 2008, would be a preparatory stage in which organizations would start to run IPv6 servers, though these servers would not be considered by outside parties as production servers. The second stage, which would take place in 2009 and 2010, would require organizations to offer IPv6 for Internet-facing servers, which could be used as production servers by outside parties. Finally, in the third stage, starting in 2011, IPv6 must be in use by public-facing servers.' Then IPv4 can go away."

Comments

Re:not ready for prime time

[VGPowerlord]

I knew IPv6 addresses were 128 bits long, but I didn't realize that 64 of those are used for local addressing.

I mean, I can understand that this is done so MAC addresses can be mapped into it, but come on... all of IPv4 is 32-bits. Do we really need 64-bits for local addressing?

IPv6 PI needs sorting out first

[gagravarr]

One of the things holding back the deployment of IPv6 is the fact that IPv6 PI still isn't sorted. There has been some movement of late, but it's still not sorted. (PI = provider indepentent address space, PA = provider allocated)

Without PI, you can't do multihoming, unless you're a Ripe member (so you're multihoming on PA space). Lots of companies will only use IPv4 PI address blocks (so they're not tied to one provider), so won't try IPv6 until they can get a PI block. At work, we'd love to do IPv6 in production, but because we can't get an IPv6 PI block, we can't.

Until all the ripe regions roll out IPv6 PI, lots of companies that want to do production IPv6 just won't. It needs fixing

Re:IPv6 PI needs sorting out first

[Spazmania]

While multi-homing is important for highly reliable connectivity, we need to do some better aggregating of it. PI blocks should be limited to only those businesses so large that they can't operate as part of a group collective. Smaller businesses that do need multi-homing (as opposed to redundant connectivity to one provider that has multi-homing) can group together to use a common PI block divided into subnets and thus use cause one route entry for the lot of them.

Show me how to actually do that from a technical perspective that doesn't also require them to negotiate Internet transit as a group and you win the prize.

Re:IPv6 PI needs sorting out first

[macdaddy]

The size of the routing table is only pertinent IF you take a full table. There are very few reasons for any dual-homed non-SP entity to need a full table. All they need is a default route from each peer. If it's a matter of wanting to more efficiently steering traffic destined to a specific peer onto that peer's link then you can either use a route-map and a list of that peer's larger prefixes to adjust the MED or weight or you can simply ask your peers to send you only their routes (trivially easy for them to do).

For those of us SPs that require full tables then the number of routes is a concern that's easily mitigated. We can implemente RIR policy filtering. That cuts the full table down to just over 1/3rd the normal size. For larger platforms relying on TCAM allocations for entries in the RIB you can generally adjust the size resource usage to free up more TCAM space. These are very larger routers though with old supervisor engines. SPs with these routers are pushing them further into the distribution and aggregation layers where they don't need full tables (in non-MPLS cases at least). These would be 6500/7600s with Sup2s. Soon Sup32s will be on the chopping block. As far as the smaller routers go they are typically limited by RAM. I replaced a decrepit Cisco 3660 with 192MB of RAM a few months back. That old router was receiving 3 full tables. 3! Granted, it didn't have enough RAM to run CEF but that's another story. Most people who have a legitimate need for full table won't be trying to put them on a router that small and preferably not that old.

So in short the size of your RIB isn't a problem for those who have a legit need for full tables and for the few that are in a pickle with older supervisor engines there are easy ways to mitigate it. It's how big your RIB is; it's how you use it.

Sounds more lke a wishlist

[HitekHobo]

Sorry, but 4 years to get every internet connected system running IPv6?! Sure it sounds great, but for a lot of folks this is going to require entirely new hardware as well as software. The budget will keep getting cut until the last minute and then they'll try to cut it all over at once. I hate to think of all the hardware that will get scrapped because the manufacturer doesn't support IPv6 without a hardware upgrade.

Then there are the folks that will find out a week before the cutover date for some reason. And the folks that no one tells at all.

There is still an ungodly amount of custom software out there that won't support IPv6 at all. Business critical applications with little or no vendor support.

I don't think we're going to be able to do a clean cutover to IPv6 until most hardware/software vendors start shipping systems that require both IPv4 and IPv6 configuration to complete installation. I figure about 10 years if they start shipping today. And then we'll still have to deal with that 20 year old software that is required to provision telephone numbers but only runs on 486 hardware.

Re:Sounds more lke a wishlist

[mrsbrisby]

I don't think we're going to be able to do a clean cutover to IPv6 until most hardware/software vendors start shipping systems that require both IPv4 and IPv6 configuration to complete installation.

That's nice. We're going to need two things bigger than that:

• A way to upconvert IPV4 and ASN routing information so that I don't have to call my upstreams and ask them for permission to use IPV6 addressing and routing. A good start would be to make it mandatory to ASN holders at the end of a year. They can have an extension so long as any of their upstreams aren't ready (to protect smaller networks) but peer groups get penalized - say 500,000$USD for the first year.
• Something actually interesting that's IPV6 only so that end users will actually want.

Right now, users want to be on the Internet that Google is on. Small sites cannot add support for both networks because it's cost prohibitive. Make it cheaper for small companies to switch and more expensive for large companies not to if you need to force the issue. At this point, it'll probably be easier to come up with something interesting.

Oh and John Curran is an idiot.

Re:I for one welcome our new Vista overlords

[neonmonk]

I would LOVE something to force all those Win98 users to upgrade.

Maybe it really is going to be Linux' time to shine, as I'm pretty sure all those Win98 boxes would be able to run some lightweight Linux distro which of course would have IPv6 support.

People always run out and say that they shouldn't have to upgrade just because of some new standard or what have you. Yes, car analogies suck - but I know I have to frequently spend significant amounts of money keeping my car on the road. What's a computer upgrade in the scheme of things. Especially the low cost of budget machines, stick these people on a Celeron with XP, tuned down Vista, lightweight idiot proof Linux distro and wham. They have a computer that can't play games but at least it'll be better than the Win98 sh*tbox that they've been hassling their ISP support desk for years about.

IPv6 adoption will be lead by Asia

[Anonymous Coward]

The biggest problem with IPv4 is that the way addresses were distributed totally screwed over Asian countries. There are single Universities in the US that have more assigned IP addresses than pretty much the entire Asian continent! There are places in China that now sit behind six layers of NAT.

Asia will lead, and anyone who wants to communicate with them will be forced to follow.

What services to change?

[pr0nbot]

Hmm...

Is there some crucial service under government control (like DNS root servers or something) that could be switched to IPv6-only in such a way that other systems would have to be configured to cope with both IPv4 and IPv6, thus making a later total switch to IPv6 less painful?

Re:I for one welcome our new Vista overlords

[GreyPoopon]

Do you have some deep insight into just how this would work that has so far eluded other network professionals, or were you just talking without thinking? If you know how to do this please share the technical details.

I think an AC already mentioned a solution -- DNS spoofing. Correct me if I'm greatly oversimplifying the problem, but aside from setting the gateway and DNS addresses, it's rare for somebody's personal computer to connect to other entities on the internet directly via IP address. A lookup is generally performed on the host and domain names to get the IP address. If the PC is configured to use the magic $20 box as the DNS and the magic box is configured to the IPv6 DNS, the box is perfectly capable of allocating an IPv4 address that maps to the actual IPv6 address for the target entity, and then passing the IPv4 address back to the Win98 machine. Subsequent attempts to access the IPv4 address will result in a lookup and translation done by the magic box. This is kind of like the reverse of NAT, but with a whole lot more IP addresses to deal with. The only trick is making sure that the DNS cache on your Win98 computer expires before the mapping entries in that $20 box. For those that choose to hang on to the old computers, it's probably not much of an issue. I'm sure that the number of different entities that they connect to on the internet are limited. If there is a problem, well, that's just yet another reason to reboot. And of course the magic box can come with some tiny little program on CD that sets HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Internet Settings\DnsCacheTimeout to a low enough value to prevent such problems.

load of crap

[sowth]

The internet will only be "slowed down" by 3.4% if everyone uses the minimum packet size. This is unlikely, and a network won't exactly be slowed down by this amount unless it is 100% saturated 100% of the time.

Everyone needs their own IP address. You must be one of those people who think the internet is just a gateway to the web and email. The truth is the internet can be used for much more. How about two way communications instead of just "surfing the WebTV(TM) innernet tubes." It only works if everyone has their own IP address, preferably static so they don't have to play with things like dyndns. The current state of floating IPs and NAT and no servers allowed by ISPs sucks goat guy balls. When will we have the true promise of the internet?

IPv4 PI has serious scaling problems

[billstewart]

IPv4 PI space is seriously non-scalable, and you can't simply duplicate it in IPv6. Tried to buy any Class-C swamp space lately? One thing that has slowed the explosive growth of demand for IPv4 PI for multihomed customers is the lack of IPv4 space (and RIR address-conservation policies), and IPv6 will "fix" that.

Another is that fortunately many of the businesses that would want multi-homing for servers are putting them in colo space rather than on their premises, so they're ok with using provider-allocated space, and it's only the colo provider that has to advertise multiple routes. Another is the policy issue that ARIN will normally not sell you PI space smaller than some size (is it /21 these days?), while NAT and firewalls mean that most businesses don't need much more than a /28 per site.

Shim6 is supposed to fix this problem, but IMHO it's an ugly ugly hack that won't succeed.

The other popular reason for getting PI space is to make it easier to renumber if you change ISPs. Unlike multihoming, this is a problem that can be made to go away by fiat. It made more sense back in the 1980s, before DHCP and DNS support became relatively universal. Renumbering servers and VPN tunnel appliances is still a bit annoying, but usually not bad, and you don't really need to renumber client machines any more, you just expire their DHCP leases if they're non-laptops, or unplug their LAN connections if they are. (Yeah, I know, it's not really quite that simple, but it's still fixable, especially because the parts that are hardest to fix are usually behind firewalls or NAT so you don't care.)

Re:comments from elsewhere

[j h woodyatt]

p0. I didn't (and still don't) think you're an idiot.

p1. How will deployment of IPv6 make your existing IPv4 network less useful? I don't get that. Nobody is talking about deprecating IPv4 any time soon. (The author of the I-D has taken my suggested edits to revise section 2.3.4, which is the only place where it implies that IPv4 will ever be deprecated.)

p2. Traditional IPv4 site multihoming is only going to get harder and more expensive as address conservation efforts get underway. At some point, it won't be any easier to qualify for multihoming on IPv4 than it will be to qualify for PI space in IPv6. It will probably be harder, in fact. The forces at work here have nothing to do with IPv6 transition and everything to do with IPv4 address conservation and BGP scalability. A lot of smaller organizations will be able to get along just fine with IPv6 by routing multiple PA prefixes to every node. This isn't as hard as many people think, and it's getting easier all the time.

p3. A lot of people think they need PI space when what they really want is ULA space. There's plenty of that, and it's absolutely free-- as in FreeBeer(TM). Generate a ULA prefix and start assigning addresses. No permission necessary.

p4. I'm not ready to agree that the RIRs are "trying too hard" not to give away the IPv6 address store. Just because there are 128 bits of address space is no reason to start handing out PI prefixes like candy at Halloween on Nob Hill.

Re:comments from elsewhere

[j h woodyatt]

"I doubt much breaks. The only thing likely to break with multiple nats is peer to peer."

p1. There is a scaling limit because there's only 16 bits of TCP/UDP port (and ICMP id), and fully-transparent NAT is extremely expensive to implement in hardware. (Has anybody succeeded yet?)

p2. There are additional costs associated with NAT, particularly with passive listeners on battery-operated devices, which have to keep waking up to transmit periodically or their middlebox state collapses. This really hoses the idle-time battery life on your phone, to name an example I'm familiar with...

p3. Another additional cost is the STUN/TURN servers required for enabling offer/answer protocols to work. Those things aren't too cheap to meter--you will be paying for access to them, and they wouldn't be necessary without NAT in the way.

Give me a few more minutes, I'll think up more way NAT break your shizzle.