Hacker News Reader

> For instance, end-user ISPs are expected to give you a /64 or more instead of a single IPv6 address so that you don't need to NAT, but many of them don't

Name one? I've been on Comcast and Sonic, and both natively provide /64 networks. I've never heard of an ISP providing a /128.

> Meanwhile, IPv4 and IPv4 NAT works.

No, it doesn't. It breaks a million things more than it solves and it makes the Internet worse (and vastly more asymmetric, but that's repeating myself). NAT needs to die in a fire, and there is zero political or technical motivation to inflict its brokenness on a new protocol that absolutely does not need it. Evidence: that many ISPs are providing native, un-NATed IPv6 to their customers. Perhaps some don't, but someone will manage to screw up any given feature. They need to fix their shit, not coerce the rest of the Internet to break itself for their convenience.

OVH's cheap dedicated servers, Kimsufi, only provides a single /126 IPv6 address, instead of the recommended /64 block :(.

I have heard rumours that, although this is what they state, they actually in practice do assign the entire /64 to the machine. Not sure if this is true and I have not tested it myself.

I see it largely as an attempt to do market segmentation and limit the usefulness of Kimsufi to push people towards their other brands. Unfortunate, but...

Well, it does work (just have to allocate the IPs statically) but since you're kinda not supposed to do that, I assume it will either stop working one day, or get my machine voided as a TOS violation or whatnot.

It really is unfortunate. Not having to use a proxy for the sole purpose of sharing the 80 port would be nice...

> But they're used on IPv4

and they're not needed on IPv6, just the same as we don't require cars to have horseshoes, even though horses needed them before.

Anyway, I'm on HN right now over NAT because HN doesn't have a IPv6 endpoint, otherwise I would be here over IPv6. THAT is what is holding IPv6 back, there aren't the services on IPv6 so there is no user demand for it.

HN uses Cloudflare (a YC company) and could turn IPv6 on for free with a single click.

But that may not represent the full story for them. Internal moderation and anti-spam may need updating to be compatible with running on two different networks that each have different approaches to numbering.

Even companies that 'get' v6 sometimes have rough edges. E.g. Cloudflare - which has been a great supporter of v6 for a long time now - has been known to send 'log in from a new IP address!' notifications because my machine automatically rotated it's IPv6 privacy suffix.

> Cloudflare - which has been a great supporter of v6 for a long time now - has been known to send 'log in from a new IP address!' notifications because my machine automatically rotated it's IPv6 privacy suffix.

Either you get that message or the IPv6 privacy mechanism is not working well enough.

Well, all the IPv6 privacy mechanism does is rotate the /64 suffix. My /64 prefix hadn't changed. From a reputation/risk modelling standpoint, it's usually correct to view a /64 of v6 as a /32 of v4 (i.e. a single address).

I talk to a lot of people who think lack of NAT "exposes everything" and is a big security problem. I try to explain that firewall is not NAT and NAT is not firewall but people do not seem to be willing to hear or understand this. "NAT equals firewall equals security" is tattooed on the inner eyelids of an entire generation of developers and IT people. It borders on religion.

On a deeper level this is because almost nobody actually understands how networks work. In my experience even really top developers often have absolutely no idea what happens on the wire. As a result they basically cargo cult netsec. Since they don't understand it, anything that deviates from "standard practice" gives them security FUD willies because they don't see the implications.

Yeah, I'm not disagreeing with any of that. But the people who don't actually understand how networks work are the people who are reluctant to deploy IPv6. Do you want to teach them all how networks work before IPv6 gets deployed?

What I've seen is that the vast majority of even top developers don't understand much about how networks work. It's a big barrier.

Why? They're top developers, they've written networked apps that work.

It's a barrier to deploying IPv6, yes, but I'm arguing that that's an entirely artificial barrier. You shouldn't need to understand why IPv6 folks dislike NAT in order to write software that uses the network.

Even Apple got bit by this issue. They sold an Airport home router which by default provided full v6 connectivity. They were promptly lambasted in the press for "putting their users at risk by not having a proper firewall!". :(

There was a time when perimeter security was seen as an adequate and acceptable technique.

Yeah, that's where the discussion gets confusing. I will totally agree that a world without NAT would be better, but I will not agree that a world without home routers that drop all inbound connections would be better. If the ISP gives out /64s, the right behavior for the home router is to assign addresses in that /64, but keep doing stateful tracking of outbound connections just like a NAT would, and drop everything else on the floor.

Of course, at this point you've broken end-to-end connectivity (P2P apps don't work, active-mode FTP doesn't work, etc.) so this may not actually resolve the reason people wanted to get rid of NAT. Maybe a good portion of the the no-NAT-in-IPv6 crowd wants inbound routes to people's homes so apps work, and the "but you don't need NAT for security" crowd is misunderstanding them

"but keep doing stateful tracking of outbound connections just like a NAT would, and drop everything else on the floor"

Here are two important behaviours which come with "just like a NAT would".

1) UPNP - a protocol which allows an application to request it be exposed to the internet

2) Hole punching. E.g. two hosts send packets with matching ip/port values to cause a direct connection to be established between them

Applications don't really do those things on v6...

And, FWIW, ISPs should be giving residential users at least a /56 - if not a /48. Sites should be able to have enough address space to route within the site and still use the features of IPv6 which require a /64. Route aggregation and routing table size is the constraint of the v6 world, not address space.

Hole punching still exists in the V6 world if you want an app to do P2P from behind stateful V6 firewalls. It requires a three party handshake just like V4 NAT traversal. But unlike NAT traversal it nearly always works since there are no symmetric NAT nightmares.

V6 should make all this cruft go away but it doesn't.

Did it have a proper firewall with sensible defaults? (I wouldn't be surprised if some vendors shipped IPv6-enabled routers without a firewall for IPv6)

There's a reasonable argument to be made that router-based firewalls shouldn't be necessary for a home user to have a secure configuration.

If it's not safe to expose a service to the internet, it's also not safe to have it exposed within your LAN without access controls.

NAT-based 'firewalls' can have holes in punched in them in a variety of ways - they are specifically designed to allow holes to be punched, because it's necessary for many applications to work.

It's also possible to take advantage of a user's browser as a relay. Combine that with the ability to use ad networks to target HTML to be served to the IP of an attacker's choosing, and the illusion that a perimeter firewall will prevent an attacker from initiating connections to your network starts to shatter.

I agree that in practice, in many cases today the stateful firewall-like functionality provided by a NAT device will provide a net security improvement. But that's not a situation we should continue to allow.

It's unrealistic to expect users to manually create firewall holes. That's why default configurations tend to include UPNP (which, naturally, introduce a new set of security and DoS concerns) - which will automatically open holes in the 'firewall'.

Google has published some of their thinking on this topic under the 'beyondcorp' moniker. The summary is there is no "safe" and "unsafe" - you need to do a risk evaluation of each attempt to access a service, and "this is coming from inside our network" in inadequate.

De-facto they are necessary, because people expect their networks to be safe, run all kinds of not-great things in there and sort-of got used to configuring port-forwarding. Attacks that can go from inside the network are in practice quite rare (AFAIK), and are a reason to add more security between network devices, not to expose them to the public net.

I'd love if we could trust most devices to be publicly exposed, but IMHO we can not. If router manufacturers could be trusted one could add all kinds of clever things there, but ...

> Attacks that can go from inside the network are in practice quite rare (AFAIK)

This is not true. Most real world attacks I've seen begin by infiltrating malware via the web, e-mail, social media, or phishing. Once inside existing connections between existing internal systems are exploited to crawl around the network.

Remote attacks against non-DMZ things are fairly rare in practice.

The only way to stop this is to implement even more firewalling inside the network, which basically breaks LAN.

I very much agree with the parent and have been talking about Google's beyondcorp and deperimeterization for years. A device that can't be safely connected to a network is broken, and we should stop degrading our networks to support broken junk. If broken junk gets hacked, it is the fault of the makers of that broken junk.

It is not hopeless. I've been into this stuff since the mid-1990s and things have improved a lot since then. I would not be too afraid to hook up a Mac or a fully patched Windows 10 machine to the public Internet. In the 90s or early 2000s I would not even consider this. You'd get owned by a bot within an hour. I remember in 2000 hooking a virgin Windows machine up to a campus network and being able to watch it get infected within 5 minutes.

The trends for the future are positive. Safer languages like Go, Rust, Swift, etc. are getting more popular everywhere. Advances in OS security like W^X, ASLR, etc. are getting ubiquitous. Local app sandboxing and containerization is a thing almost everywhere. Devices security postures are improving.

I really passionately hate clueless security FUD.

Nearly 30% of the US traffic is now IPv6: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

IPv6 NAT exists on Linux, OpenBSD, Cisco, perhaps others. However you would better not use it.

NAT66 implementations exist, and you don't need anyone's permission to use them. But I think it would be more productive to pursue smarter ways to share a /64, than to modify packet headers in flight.

For most purposes, ND proxy is the new NAT.

And there are actually some use cases where NAT66 may make sense (various multi-homing and re-numbering avoidance scenarios). I think the jury is still out. I think we'll see lots of NAT66, but for completely different reasons than we've seen v4 NAT.

I do think those uses will tend to involve 1-to-1 prefix translation rather than many-to-1 mapping.