Hacker News Reader

1. "not everybody needs a public IP address": sure, and there is no need for more than 6 computers on the entire world, ever. In my opinion, stalling the transition hurts innovation; while it's true that as the things are at present public addresses are not an imperative, new technologies like P2P, which would greatly benefit from public addresses, open a whole new realm of possibilities.

2. Again correct, assuming that there is no cheaper alternative to the "addresses market". But it exists, and is (mostly) free. Once the providers realize that it's less expensive (longterm) to switch to IPv6 than to keep buying new addresses, they'll do it, even such a solution might prolong things even more.

In general, most of "solutions" to the IPv4 crisis represent a sizable effort, which will only increase as the addresses become more scarce; and the sum of it will be much larger than the effort of simply switching to v6. We'll see how it will turn out though.

Stalling the transition hurts innovation, yes, and avoiding an address market would be good too. But this is ignoring the human problem, which was my original point.

From a technological standpoint it would be nice to switch, but you have to convince everyone to switch, which isn't easy because:

Most OSes deployed today either don't support IPv6 or the support is problematic. Remember that most of the world still uses Windows XP and are in no hurry to change.

Most applications don't support IPv6. Many of those could be easily changed but the people responsible have better things to do, especially in the enterprise space (which most people here seem to ignore, always thinking that the consumer Internet is the only thing in existence).

IPv4 is elegant in its simplicity, whereas IPv6 is complex and different for the sake of being different in some cases. This means extra cost to switch internal networks, and without switching internal networks there's no pressure to port most applications.

Network administrators know IPv4 well, what works and what doesn't, where the faults are. Switching to IPv6 means extensive training which adds to the cost. Given that right now people that actually have a working knowledge of IPv6 are few and far between and seem to be concentrated in ISPs, this will be hard to change.

Despite the benefits of everyone having public addresses, there are also security downsides, and these outweight the benefits in most people's eyes.

So, the main problem is legacy. IPv6 benefits are irrelevant when it doesn't interoperate seamlessly with IPv4.

Again, IPv6 adoption is a human problem, just like convincing people to abandon IE6 is.

> Despite the benefits of everyone having public addresses, there are also security downsides,

No there isn't. Not a single one. Just replace your old NAT by a clean firewall, and you're set.

Letting people see each individual device, even firewalled, is a security downside.

I don't believe you. I'm willing to listen though. Do you have a link to a detailed, technical explanation of this?

I need a reference that exposing more information about systems that are nearly guaranteed to have security flaws is bad? I'll give you a simple scenario and then go look for something to make you happy.

I have a computer running services A and B and several computers running service B. Service A exposes information about the computer's configuration that helps attack service B, but only if the attacker can figure out which one.

Edit: I haven't really been able to find a comparison between firewalling and firewalling+NAT, just comparisons between nothing and NAT.

By the way, I wasn't completely explicit. I supposed that in both cases all incoming ports are closed, except for the ones you explicitly open. That way, the only difference between the NAT and the firewall is the address translation.

My scenario is narrow, but I expect it to be a common one: IPv6 internet boxes will likely include such a firewall by default.

I have to agree with Dylan on this one. By default, the security of a system with ANY public addressability (vs. one that can't be seen except on outbound requests) is dramatically less secure than not exposing it at all.

If we can believe the old adage that "The only secure server is one encased in concrete", then the average non-NATTED device is more akin to one that is concreted than one with public addressability.

http://news.ycombinator.com/item?id=1744736 (I supposed that going from NAT to clean firewall would open any incoming ports.)

Errata: wouldn't open any incoming port.

Obfuscation isn't security. If exposing the existence of a device is compromising to you, then this doesn't solve the problem, it makes it less likely.

To which you might say "it makes us less likely to be compromised", which is probably your goal. So obfuscating network access probably makes sense to you. But I think it's dishonest to market this as "security". The door is still exactly as open as it would be if they were exposed. Security is fixing the problems that would be exploited

http://www.out-law.com/page-11052

It is marginally more difficult than IP addresses.

So, unless you are truly using a multiuser machine from which the users use the Internet, it's just a convenient feeling of security. Which in itself does have some value, though, even if merely to save from some stress.

It makes device specific protocol attacks possible.

Sniffing traffic on the outside of a NAT hides which internal device(s) the traffic is coming from, doesn't it? So if you wanted to attack Alice's traffic then you can't easily tell which it is.

If you can sniff traffic from Alice's IPv6 address, then you have a much smaller amount of traffic to brute force, and you can try a MITM attack without risk of anyone else behind the NAT being affected accidentally.

Nah, unfortunately NAT doesn't really do a good job of hiding what the source machine is. People have used this to analyse how many machines are behind a NAT with very clear patterns emerging based on TCP/IP timestamps as well as the sequence numbers (which are sequential in most OS's).

The bigger concern is the fact that you apparently have access to the data being sent/to from an IP address and can thus sniff the data in the first place. Whether that be a NAT'ed or IPv6 IP address.

It's been a while since I used either IPv6 or Windows XP, but if my memory serves, IPv6 on XP worked just fine. It did require a trip through the install-a-protocol dialog box, which I agree is rather clunky; however, it did work, and once it's installed, there's no further configuration to be done on the client.

1. I've just run into a couple of cases on certain types of public wi-fi network where having a public IP on my phone would have been very useful in just the last couple of days.

> don't agree with the view that NAT is evil

NAT is a nightmare for p2p applications. For algorithms that send short messages to many different peers the overhead of using STUN for every connection is enormous. See eg http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81....

P2P is a nightmare because every application is expected to provide its own connection fabric. In a content-addressed overlay network --- and there are many huge deployed examples of these deployed --- you wouldn't need to do the STUN chicken dance every time you wanted to add a peer.

If this all sounds hand-wavy, well, it's already the mechanism used by the exchanges and ECNs to route stock information, and it's already a mechanism used to build CDNs. It's a considerably more straightforward evolutionary path for the Internet than forklifting out every IPv4-aware device or software package.

Not every P2P revolves around "content". The most well-known example would be Skype and SIP.

Content-addressed networking doesn't imply that content is being transmitted in discrete units; it implies (what Tibco would call) subject-based addressing, and the notion of publish/subscribe.

It works just fine for unicast, and even in strictly unicast situations, there are plenty of cases (conference calls, for instance) where "subscribe" turns out to be useful.

> P2P is a nightmare because every application is expected to provide its own connection fabric

Well someone has to write the connection fabric, even in a content-addressed overlay. Writing a DHT that performs NAT traversal is just as difficult as for any other P2P application. See http://www.slideshare.net/vschiavoni/dht-and-nat for some examples.

CDNs have it easy because they control the network the servers are on. Writing p2p applications for the internet at large is much harder than it should be because of NAT.

I think you're missing my point. It's hard to write P2P applications for "the Internet at large" for the same reason that it's hard to write a web browser in assembly language: you're targeting the wrong layer of abstraction.

What I'm suggesting is that if instead of a futile effort to convert the Internet to a new, Cisco-sponsored network protocol we invested in adoption of a few standard overlay networks, people could write P2P applications that targeted overlays instead of the Internet, and IP addresses would matter only as much as Ethernet addresses matter today.

You mean something like this http://libswift.org/ ? I think I understand your point now. What we need is a standard mechanism for addressing devices. I'm not sure that building another layer on top of IPv4 would be any cheaper in the long run than converting to IPv6, given the amount of overhead caused by NAT traversal. This overhead also constrains the design of the overlay - you end up having static connections which are kept open as long as possible to avoid the connection overhead. If we could send UDP packets directly between every pair of peers without paying for the overhead of NAT traversal it would open up a lot of possibilities.

I think anything built on top of IPv4 must be less expensive than IPv6, simply because the cost of converting to IPv6 is deceptively high and because we'll inevitably need to build an overlay layer anyhow.

The overhead of NAT is irrelevant on overlay networks; it scales linearly with the number of direct connections established (OSPF would call them "adjacencies"), but probably scales logarithmically with the number of relationships on the network.

> it scales linearly with the number of direct connections established

Yes, assuming that the overlay algorithm actually establishes direct connections with a small number of peers. That's the way most overlays are designed because they need to reduce the cost of establishing a connection. By way of contrast, I recently worked on a gossip algorithm for producing uniformly distributed peer samples with no warmup time. This algorithm doesnt maintain an adjacency graph at all. Instead it sends a single udp datagram to a different peer at every tick (100 ms for the test system). Its a really simple algorithm that provides stronger guarantees than any existing peer sampling service but replace each datagram with a NAT traversal and the overhead kills it.

Nice analysis. And locator-ID split idea in (3) is fun. However, (3) is tricky in itself - you still need the routing info to come from somewhere. And, would not matter too much whether it is IPv6 or another layer of IPv4 that are used as locators - or did I miss something in the argument ? Peering for the IPv6 should be roughly the same as now for IPv4.

The scarsity dynamics and the cost of v4 vs. v6 is something I totally agree with. And with the fact that NATs are not evil per se. They're a tool just like IPv* is.

> NATs are not evil per se. They're a tool just like IPv is*

"Nukes are not evil per se. They're a tool just like knives are."

Please avoid this kind of sentence. They're void of content, and therefore can't be contradicted, but at the same time they convey wrong ideas. Here for instance, I can't think of any direct usage of nukes that isn't evil. Because nuke explosions automatically kill people and ruin the environment.

Likewise, I can't think of any usage of NATs on behalf of other people which isn't evil (though much less so). Because, you automatically end up closing all receiving ports, and they can't re-open them.

"They're void of content" - no, they are just a restatement that any technology is only as evil as its use. Think P2P. One can argue it is evil because its predominant use is to distribute pirated content. But it is not. Similarly, nukes were seriously considered for plugging the oil leak - to name one recent example.

If you can't think of any usage of NAT that is not harmful - it does not mean there isn't one. To start, what you mention - the stateful nature of the NATs (one of the reasons why people fight so hard to have them) - is a useful security property and is very frequently sought after by the people who want to put the NATs in IPv6. Check my vid on xtranormal that I mentioned in another message.

What is harmful in NATs is that they destroy the end-to-end referrals (and when they remap the numeric ports to different ones, too).

Another example of NATs that is useful and is widely used is the load balancer. It is exactly NAT, but put inside-out. Sometimes even doing SSL decapsulation. And you can use round-robin destination NAT as a poor man's loadbalancer technique (how useful it is today, is another story).

To summarize: NATs are like recreational drugs. Pleasant in small dozes, lethal when uncontrolled. And people can not control themselves in using them.

> "They're void of content" - no, they are just a restatement that any technology is only as evil as its use

Which is exactly what I meant by "void of content". This sentence is self evident, almost a tautology.

About NAT themselves, I wasn't talking about using them for yourself, but using it for your customers. But that's probably what you mean by "uncontrolled use of NAT".

About the load balancer, wouldn't the problem be solved with SRV records?

Anyway, it appears from your other comments that we basically agree on everything. So let's not fight.

"This sentence is self evident, almost a tautology." - Ok, probably I misinterpreted your comment about the NATs being evil, apologies.

"About the load balancer, wouldn't the problem be solved with SRV records?" - the SRVs would certainly help a lot - however, the predominant user of the load-balancers, the web browsers, are not using SRV and not planning to. The http://tools.ietf.org/html/draft-jennings-http-srv-00 which proposed it (and which possibly could have been used by the clients too) - now got pushed into something that would never be possible to use by the browsers.

Re. agreement - yes, I think we do agree.

> The http://tools.ietf.org/html/draft-jennings-http-srv-00 which proposed it […] - now got pushed into something that would never be possible to use by the browsers.

That would really suck. Could you elaborate, or send me a link, please ?

You can remove the -00 and look through the history of the doc - it's now at a later revision.