Proposed IPv6 Cutover By 2011-01-01 398
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."
IPv4 works for me (Score:1, Informative)
comments from elsewhere (Score:5, Informative)
1. Neither John Curran nor the IETF has the the authority to bring this about, thus the use of the word "must" is misleading. Even if the regional internet registries supported this with policy that placed additional IPv4 addresses out of reach of those who did not deploy IPv6, far less than half of the content providers would be impacted within the proposed timeframe. Indeed, relatively few content providers come back for more addresses. Its mostly the transit providers which connect the end users who have a growing need for IP addresses.
2. The natural course of IPv4 depletion is more likely to drive conservation of IPv4 addresses than it is to drive IPv6 adoption. Business will tend towards this path because the incremental cost of conservation is small and the benefits are immediate while the cost of IPv6 deployment is large and the benefits are remote. Conservation might sound like a good thing but its actually very dangerous. It implies injecting many additional routes into the "default-free zone," which for complex technical reasons would decrease the overall stability of the Internet.
3. Existing policy at the regional registries serves to obstruct the deployment of IPv6. For example, in the Americas at ARIN, there is an additional $500 fee to receive IPv6 addresses in addition to whatever fees you pay for IPv4 addresses. That's a nuissance. More critical is the wide swath of legacy multihomed content providers who because they are too small don't qualify for IPv6 addresses from ARIN. Those folks can't get the so-called "provider-independent" addresses they need to connect via IPv6 in a technically comperable way to how they connect with IPv4.
Re:not ready for prime time (Score:5, Informative)
The idea is that IPv6 addresses are a 2-part address. The first 64-bit part is the classification and routing. The second 64-bit part is the unique space, although literally that does not need to be. The idea is to eliminate error and complexity prone steps to map unique link layer addresses into globally routable addresses. Sure, this could have been done with a lot fewer addresses and still have enough for even the very largest networks. But then you'd have to ensure that no 2 hosts could end up with conflicting addresses. The gateway router could certainly do that, but if it gets rebooted, all the addresses might have to be changed because the map gets reset. By using link layer addresses, once the globally routable prefix is known, the host/interface addresses can remain constant even if the router is rebooted. One of the goals of IPv6 is more automatic configuration.
Re:not ready for prime time (Score:5, Informative)
Again? Did you just wait for a possibility to post the same junk again [slashdot.org], three years later?
No "Network Anonymiser Translation" this time, but an ethnic slur, great.
Re:not ready for prime time (Score:2, Informative)
Re:I am not trying to troll right now but... (Score:3, Informative)
PROPOSED IPv6 Cutover.
Proposed.
Re:not ready for prime time (Score:5, Informative)
- Home computer
- Work computer
- Laptop (private or work)
- Cellphone(s)
- Net connected appliances (TiVo, net music players, IP phones, home surveillance, alarms)
Each ideally needs its own address, and it's not hard to see how 4 bln addresses will be used up.
Solve it with NAT, you say. Sure - but actual interactivity is in higher and higher demand. Both my MythTV box and my laptop in most locations are NAT'ed. Save for my tinkering with NAT routing which is only for geeks, I can't get to my Myth box from the outside.
Another problem is the solution to the above problem - VPN. At my former job (a web consulting agancy) we were routinely given VPN access to clientsites. They were all setup with IPs in the range 192.168.X.nnn. We had no collisions of X, but we were a small firm, and it will happen.I remember hearing the same argument against using FAT32. Although your point is quite valid, I think the world will recover, and quickly.I'm no expert, but didn't the world stop using minimum MTU for anything larger that that a while ago? If an MTU is size 1500 instead, the overhead is a whopping 1.3%, or downloading an extra 51 mb on your full, uncompressed 50gb bluray movie.
Yeah, it's not free of drawbacks, but progress seldom is.
Re:not ready for prime time (Score:5, Informative)
Re:I am not trying to troll right now but... (Score:5, Informative)
He suggests charging people more for IPV4 allocations will speed IPV6 adoption and has no idea what an idiotic statement that is. He admits he doesn't care if raising the price of IPV4 allocations will simply drive smaller networks "out of business" as "they should be on IPV6 anyway". Meanwhile Google can afford it and nobody gives a shit about IPV6- they just want to use the same internet that Google is on.
He lies and says we're running out of addresses at a rate of 10-15
He has no migration plan besides "just replace all your hardware and software". It's about as stupid as the HDTV plan, which since I cannot record HDTV without buying illegal hardware, I'm not buying either.
Seriously, does anyone think an actual migration plan for something as big as - replace the entire Internet- would be authored by a single person that nobody outside of ARIN and IANA working bodies have heard of?
He's an idiot and an asshole.
Re:I am not trying to troll right now but... (Score:5, Informative)
It is.
http://en.wikipedia.org/wiki/IPv4_mapped_address [wikipedia.org]
There are even ways for reaching IPv4 hosts from IPv6.
http://en.wikipedia.org/wiki/Stateless_IP/ICMP_Tr
Re:not ready for prime time (Score:5, Informative)
1. Cisco routers suck at IPv6.
Anything reasonably current doesn't route IPv6 in software. Yes, there's legacy stuff out there that will have to be dealt with, but there are solutions to those legacy hardware deployments that aren't terribly arduous. But it does mean people need to get started dealing with this *NOW* rather than later.
2. There are too many addresses.
Uhm...so don't use them all. I'm not sure what sort of objection this is. "Oh, we can't do that because that solution will give us more resources than we need." Oh the horrors of not having to worry about running out of addresses, I'm not sure I can deal with that problem
3. IPv6 addresses are too large.
The ISP that I used to work for advertises 7 or 8 routes into the IPv4 default-free zone. With a move to IPv6, they could easily, without breaking a sweat, move to only advertising a single route. So, an IPv6 route would have to consume more than 8 *times* the memory that an IPv4 address does for it to be a loss for the routes that said ISP would advertise. Many enterprises advertise many many more routes than that in IPv4 and could drop down to a single (or very few) IPv6 routes. Yes, the memory footprint of each individual route in routers would be bigger, but the number of them will be significantly smaller, meaning overall router memory consumption will drop.
4. The IPv6 header is too large.
Ooh, 3.4% (and that's worst case)...I'm not sure the world can handle those sorts of inefficiencies. Yes, IPv6's larger header will drop data throughput efficiencies ever so slightly. That's better than the 100% drop in efficiency you'll have when you can't get an IPv4 address at all.
Re:I am not trying to troll right now but... (Score:3, Informative)
Anytime you move from a v4 to a v6 network, your gateway automatically prepends the 2002:: prefix to make your IP a v6 address. The problem here is that you have to have a public IPv4 address for this to work. If you're inside a NAT'ted network, your private address wouldn't be translatable to a corresponding v6 equivalent.
p.s. a link [twibble.org].
Re:comments from elsewhere (Score:3, Informative)
IPv6 works beautifully in an Intranet and LAN environment with autoconfiguration. IPv6 registries and routing are a problem however because nobody's* doing it.
*almost
Re:I am not trying to troll right now but... (Score:3, Informative)
Re:This is so funny, I don't even know where to be (Score:3, Informative)
Consider also that this is not just routers, but anything with a public IP, such as firewalls and a lot of enterprise-level firewalls just do not have IPv6 capabilities yet. Not like, hey, the handling is Teh Suxx0rs, but it's Just Not There. Juniper's security products don't do it; hell until a recent-ish version of the FW+VPN OS was released, an IPv6 packet could reboot a VPN connection. Nor do Fortigate or CheckPoint handle IPv6. Cisco's SSL VPN does shit to the packets and to make a long story short, is just not ready to deal with IPv6. AFAIK, ISC's DHCPv6 is still kind of rough (although admittedly I don't follow it very closely on the list, it gets mentioned now and again and the impression I get is that they're working very hard on it. Which means it isn't ready yet.) This matters a great deal to ISPs who would be the ones handing out IPv6 to your average user; an unbelieveable amount of them use ISC's DHCP software.
Re:And what of my current NAT routing (Score:3, Informative)
You can do NAT but it is strongly discouraged (it's basically reserved for situations where you need to move machines between networks, rather than sharing of a single address between multiple devices). Your ISP _should_ give you at least a
Of course, if they try and give you a single IPv6 address instead of a sanely sized prefix then you should go find an ISP who has clue and doesn't jsut try to rip you off.
Oh, and NAT firewalling? what about NAT firewalling?
There's no such thing as NAT firewalling. There is firewalling (which may or may not be stateful) and there is NAT (which requires stateful connection tracking). The existance of one does not imply the existance or requirement of the other. And yes, you can still do stateful packet inspection for IPv6.
Re:comments from elsewhere (Score:5, Informative)
The MUST/SHOULD/MAY terminology in RFCs is to indicate levels of compliance with a specification. If this were a specification, or even a BCP (Best Current Practice) RFC [rfc-editor.org] document, then this might make sense. But it is intended to be an Informational RFC, which has no weight as a standard whatsover. So MUST/SHOULD/MAY terminology is completely inappropriate (in case you're wondering, yes I have written quite a few RFCs).
This document is an individual submission at the moment. Anyone can submit such a document; this does not indicate any level of support by the wider IETF, let alone anyone else. If the IETF were to take this on, and make it a BCP, then the terminology would indicate levels of support, and you could legitimately claim that an organization that did not comply was not providing standards-compliant service. It's possible this could embarrass an organization, but somehow I doubt it. However, if there were such a document, it might be possible for national governments to legislate compliance. Only then would it have any significant impact, but I think legislation here is unlikely and probably inappropriate.
Likely what will happen is that the regional registries will run out of address space to allocate in approximately three years from now (this is the current best estimate [potaroo.net] from Geoff Huston, who probably knows more about this than anyone else). ISPs will find it hard to get addresses after that, and a market will naturally emerge. Basically address space will become expensive. Also, there will be incentive to disaggregate currently aggregated address space, so more organizations can multihome. This will cause increasing routing table explosion in routers, and cause ISPs to need to either filter route advertisements (breaking multihoming) or upgrade routers (requiring them to spend money). And increasingly larger organizations will start to use NATs, making all sorts of applications harder to set up than they need to be. When your home NAT is behind your ISP's NAT, I suspect lots of things will break really badly. Maybe eventually the pain will get great enough that the switchover starts to reach critical mass, and only then will organizations actually allocate budget to make it happen.
There is a lot to be said in favour of moving forward in a less chaotic way that this, but I'm skeptical about the likelihood of that actually happening.
Re:I am not trying to troll right now but... (Score:3, Informative)
6to4 is a good idea that could be great but isn't because it depends on a small network of volunteers to run encapsulators and decapsulators. The volunteers would be overrun if any meaningful business use was attempted.
Re:I am not trying to troll right now but... (Score:3, Informative)
There is no *short-term* financial benefit. There's a *huge* financial benefits for people and enterprises that are able to see beyond their own nose.
>(maybe we'd PI some old
What do you think ARIN and the RIR's have been doing for the past 5+ years?
At current run rates, we're going to run out of IPv4 address, completely, in 2010 or 2011. There won't be any old
Wake up and smell the coffee, you need to start thinking about deploying IPv6 now, or experience extreme pain in 3-4 years when you find yourself up against a wall because you can't get IPv4 addresses, and/or can't get to services that are starting to deploy *only* on IPv6 because that's all they can get.
Re:Are you serious or just burning karma? (Score:4, Informative)
NAT (ie, the mangling of IP addresses) doesn't give you any security whatsoever. Putting your box in the DMZ isn't bypassing the NAT, its just setting up a different type of NAT.
The security that you get behind your NAT device is because the device necessarily has stateful packet inspection and filtering engine...because dynamic NAT doesn't work without it...its the stateful inspection and filtering that gives you the security, not the NAT/mangling of the IP addresses.
You could stick a stateful inspection and filtering device that denies inbound connections by default in your laptop travel bag and have exactly the same level of security, without breaking useful applications like NetMeeting (admittedly dated), and other useful applications that connect directly client to client.
Re:I am not trying to troll right now but... (Score:5, Informative)
That's pretty much been done: http://www.potaroo.net/tools/ipv4/index.html [potaroo.net]
Re:IPv6 adoption will be lead by Asia (Score:5, Informative)
We like our
Re:IPv6 PI needs sorting out first (Score:5, Informative)
Otherwise, in North America, the criteria for getting IPv6 PI space is exactly the same as IPv4 PI space, and is based on your usage of IPv4 space...and since you can count the RFC1918 space in your justification, it actually ends up easier to get IPv6 space.
Re:Are you serious or just burning karma? (Score:3, Informative)
The problem with your argument is that you qualify it with "not in the DMZ". Putting it "in the DMZ" (which isn't a real DMZ anyway) is still NAT, and your protection just went *poof*. NAT (ie, just mangling IP addresses) doesn't provide any protection. Having stateful inspection of every packet and deciding which ones to forward on is what provides protection. This means that a stateful inspection firewall is capable of providing exactly, completely, 100% the same level of security; oh, and do so without breaking any protocol that tries to use the Internet as a real communications network rather than some simplistic I-make-a-request-and-get-a-response-back pseudo-communications network.
Re:IP256 better anonymously than flawed IPv6. (Score:3, Informative)