Comment by CrLf | Hacker News Reader

Comment by CrLf | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com