Sigh, no. Not correct -- in the last 8 or 9 years, engineers have been cooking up various ways to bridge the gap. The transition landscape looks a lot different today than it does in 2003. Comcast (the largest MSO in the US) has detailed their transition plans here (tl;dr, it's v6-only customer addressing, with v4 reachability via DS-lite and CGN): http://www.comcast6.net/
Summary here: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms
NAT is not a solution. Internet is cool because it allows peer-to-peer communication. It's also cool because everyone can host servers and everyone else can connect to them. This allows exploration and experimentation.
Please don't force some people to become second-class citizens behind a NAT just because some artificial resource is running out. It's bad enough in the real world.
Also, "the addresses are just to long" is a nonsense argument, for many reasons. And HTTP is only one of the many protocols. But I think I've fed the troll enough.
I'm glad someone said it. This apenwarr seems to have some good karma here on HN, but IMO a lot of what he says is heavily misinformed and biased.
I had the urge to go point-by-point of his post and refute each with proper references and practical examples, but I then I realized that he is just a troll and that would be feeding him.
Some of his points, like about IPv6 addresses being too long and hard to memorize and that NAT is good/enough for users, basically points that he probably doesn't have much experience with network management and how IP works (specially IPv6 networks). This is strange coming from someone who was the original author of wvdial.
I have already argued here on HN why IPv6 addresses are easier to memorize: http://news.ycombinator.com/item?id=1804038
I think he's right more often than he's wrong. (Although not in this article, which is nearly all wrong when it's not rehashing points that have been argued both ways for many years w/o a resolution.. hang out on NANOG for even a month and you'll see what I mean.) And I appreciate that he feels he has to get his half-baked thoughts posted now, before being swallowed by the Borg. Which will certainly change his opinion of some of this stuff if he ends up working with the ipv6 people @ Google.
And what about whitehat countermeasures? Finding the source IP address is so much more useful than "it came from this giant ISP... somewhere". ISP-level NATting has nothing but disaster stamped all over it.
IP addresses are? What is Facebook's IP? Googles? I have no idea because.... why on earth would I care?
Names introduce an extra layer of complexity that makes troubleshooting more difficult at times. The world exists beyond facebook and google. You may not care about that, but I do.
Plus you potentially have the added benefit of having the MAC right there in the IP so you don't have to do any extra effort to figure out what it is.
The real damage caused by NAT is mostly invisible. Because some people don't have IP addresses, creators of applications and protocols must assume that nobody does, making many ideas complicated or impossible. We won't know what branches of innovation we've missed out on until this constraint is lifted. As James Burke teaches us, it's these little things that so often change the course of technology.
I feel this acutely every time I try and spread the word about my project (PageKite, a system for putting "servers" on mobile and personal devices). People just look at me funny and go "why would I want that when I can rent a vserver somewhere in the cloud?"
Once upon a time people would have asked "why do I have to rent some external machine instead of using this one I already own and this Internet connection I already have?".
Cool idea! I'm checking it out now.
Imho this shows, that people dissing IPv6 today have not had a look into it and are now in a hurry.
Amazon e.g. does not announce a single IPv6 prefix, imho a bad sign about their networking competence: They don't even have a testing infrastructure ready.
ipv6 has been coming forever. It seems like this year, friends actually have to come up with ipv6 deliverables. that's never happened before. hell, comcast is going to be testing ipv6 this year. that's a big indicator with flashing lights and sirens.
NAT works in an office environment because most offices aren't doing anything more than web and email. Home usage scenarios are significantly broader and harder to keep working behind carrier grade NAT.
As technology filters down to the third world, and (assuming there isn't some massive device convergence that reduces demand for IPs in the first world) the ratio of devices to people will rapidly become skewed. It's a lot easier to pump out cell-phones than babies after all :D
If there is even a single customer that only has access to ipv6, you have to support them 4 and 6. My office, and your office will of course stay on ipv4. I'm pretty confident least one university will soon be strapped for cash, and sell of the boatload of their ipv4 space, and just give the dorms ipv6 addresses. there will be much whining and complaining, and everyone will support ipv6 the next week.
They aren't the same thing, but that doesn't prevent them from having features in common. They are both big, powerful entities that don't have my interests at heart, and are both therefore threats to my liberty (especially when they work together to undermine it).
Nice try at a silver lining tho. :)
All that to do something that should be as simple as open(some_ip)
What do you think of the suggestion made by the author of the article that, even if we had IPv6 everywhere, we'd still put a lot of networks behind NAT, for reasons of security.
It's utter bullshit. Stateful firewalls will of course continue to exist; doing Network Address Translation in addition will be completely pointless.
And NAT is not a solution. Period. End-to-end, ever hear of it?
What about VNC/Remote desktop/SSH?
What about protocols that don't use port numbers like ICMP and basically everything that's not UDP or TCP?
What about sites that grab data from other sources, often needing IP whitelisting
Sharing IPs for SSL HTTP services is tricky, do dedicated hosting/VPS users actually want to give their certs to the ISP (private keys and all) so they can manage it?
I agree with the article's rant about port number being obsolete. A service space of 16 bits sucks. IPV6 provides a Solution to this: advertise a different IPV6 address (multi-home) for each service, and use the DNS to resolve, not the TCP address. I think.
Actually, strangely enough, both of these use cases work perfectly on my local network, and have worked both with my current router (running dd-wrt) and with my previous router (a standard AT&T combined DSL modem and router).
DNS actually works extremely well with a few, by now ubiquitous, autoconfiguration tools.
DD-Wrt and OpenWrt run dnsmasq DNS and DHCP server, which is capable of recording machine names when they request an IPv4 address over DHCP, then DNS-resolving that name to that IP.
And there's also ZeroConf...
What you must think about is "where are the bottlenecks". When you are connecting to a client on the other side of a large network (e.g. the internet) and you're not getting the same amount of bandwidth your last-mile connection should provide you with you have to ask yourself: what's keeping the speed down?
Turns out that router processing is still a bottleneck. And by delegating the mundane router work of handling packet fragments and doing checksum validation to the end terminals we are getting a much more efficient network than with IPv4. IPv6 headers are also much simpler making it easier (faster) to process with ASICs.
Stating that reducing work is useless because we work much faster now than way back when is not a good argument.
I don't know it IPv6 is the solution - if not, lets invent something else.
People should be able to run servers on any device. What exactly they will use it for is a mere matter of innovation. :-)
telehash.org, for the interim.
To address the shortage of available IP addresses, carriers are going to start giving out RFC1918 (private) IPv4 addresses to their customers. And the NAT could occur anywhere; you might be a customer in San Francisco but the closest public IP gateway could be in New York. (Yes, we have seen this.)
This is going to cause two serious problems for businesses:
(1) Location-based services are going to break. LBS uses the public IP address as the primary key in the database.
(2) DoS protection that is IP-based (counting request rates from particular IPs) is going to break. I suspect a lot more sites that we all know and love are going to have a difficult time staying up after CGNAT is pervasive.
> The hardware-optimized packet format of IPv6 is worth basically zero to us on modern technology
No. Basically zero is not zero.
> Every HTTP Server on Earth Could Be Sharing a Single IP Address and You Wouldn't Know The Difference
No. Though he lampshades this towards the end, he still gets it wrong - the SNI extensions to TLS allow secured virtual hosting on recent browsers - but not older ones, where it simply just doesn't work.
> if I accidentally leave a daemon running on my server, it's not automatically a security hole
No. NATs are unfairly equated with firewalls. There is nothing stopping a firewall from preventing connections to a computer that is now addressable from the outside, just as they do today. If you are running a publicly-deployed service and do not restrict inbound and outbound traffic, I would advise you to do it, now.
> Because of the way TCP and UDP work, you can safely NAT many, many private addresses onto a single public address
> I won't go into this too much, other than to say that there are already various NAT traversal protocols out there, and as NAT gets more and more annoyingly mandatory, those protocols and implementations are going to get much better.
No. UDP hole-punching isn't that simple. It requires a third party, and implementations of NAT are very heterogeneous. Arguing that it's possible to do safely (and implicitly, on a large scale) is ignoring reality.
So his solution to a newer spec that, despite a rough and in-progress transition, accounts for legacy, is to move to a newer, incomplete, solution that breaks abstraction boundaries, is incompatible with current network hardware, requires major server and router rearchitecture? No. A thousand times no.
> NAT (and DHCP) has largely eliminated another big motivation behind IPv6
No. I find it laughable that he argues that he argues, essentially, that private IP subnets make handling DNS simple, while simultaneously (later) arguing that DNS service records should be used so people don't have to remember IPs + ports, while also saying "So here's what I really hate about IPv6: 16-byte (32 hex digit) addresses are impossible to memorize". How about, instead of kludging up a hack nobody's on board with, using an existing solution with widespread support? Stateless autoconfig or DHCPv6 do the same job.
> If GUIDs were a good idea, we would use them instead of URLs
No. What the ever-living FUCK. Did he not already read his own words about DNS? So sysadmins now have to copy-paste instead of memorizing IPs, or spend a few extra lines in their host files or DNS servers aliasing it to some DNS address. This is a simple and sufficient solution.
> But furthermore, DNS on the Internet is still a steaming pile of hopeless garbage. When I bring my laptop to my friend's house and join his WLAN, why can't he ping it by name? Because DNS sucks. Why doesn't it show up by name in his router control panel so he knows which box is using his bandwidth? Because DNS sucks. Why can the Windows server browse list see it by name (sometimes, after a random delay, if you're lucky), even though DNS can't? Because they got sick of DNS and wrote something that works.
> Of course, I can't really take credit for this idea. It's already been invented and is being used in a few places. (links to wikipedia article on SRV records)
No. JESUS CHRIST. s/because DNS sucks/because Windows sucks/ - for some of the stuff he's talking about, multicast DNS fixed. Oh, and by the way, Bonjour has been using multicast DNS + SRV records for freakin' years, and works pleasantly on !Windows - and it does so for IPv6, as well. I can't speak for Windows because I have had the pleasure of not using it for anything other than games for the past several years. I have set up a Time Machine service on a FreeBSD box that advertised itself as such with no problem whatsoever.
> IPv4 addresses aren't really 32-bits. They're actually 48 bits: a 32-bit IP address plus a 16-bit port number
No! This is like saying that your keyboard and mouse are actually a mouseboard, because they're almost always together. IPv6 still uses TCP - doing what he suggests would not only be a massive kludge, it would obsolete an incredible amount of infrastructure already in place - this cannot be implemented incrementally! Throwing the bathtub out with the bathwater in order to destroy a working layer of abstraction is insane!
> This proposal has very minor chicken-and-egg problems
No! Unless by 'minor' you mean bigger than the fucking universe.
This article is founded on so many faulty premises it proposes a technologically intensive non-solution to a problem that suffers from much worse flaws the solution it complains about. Readers should disregard any and all advice proffered by this blog post, as it is grossly inaccurate and incorrect.
Last time I tried to bind a socket to just an IPv4 address I got a compilation error.
All the subpar websites I don't want to be bothered by won't switch, and I won't have to deal with them.
IPv4 is going to last quite a bit longer once we start trading in IP space. Didn't Microsoft just purchase a huge chunk of IP addresses from Nortel the other day? If that kind of thing is allowed to continue, we're in for years without any need for IPv6 - sadly.