Hacker News new | past | comments | ask | show | jobs | submit login

Let's not forget about the idea that ISPs would distribute a /56 range to residential users. You could split it in /64 ranges according to your requirements and everything would work fine.

There is only one "minor" issue: all major ISPs in my country ( Brazil ) only provide a single /64. You can't get another /64 unless you upgrade to a very expensive business plan.

That makes IPv6 not only useless but also a huge security issue.

1) I can't use my Mikrotik as a firewall. Trying to split a /64 range breaks things and some devices ( specially IOT ones ) will simply not work.

2) Routers provided by the ISPs here are very limited, specially for things like firewall rules. Some of them will only provide a On/Off switch, with Off option between the default one.

Although IPV4 + NAT had some issues, it ( accidentally? ) created a safe/sane default config for non-technical users. In order to open a port and expose a device, you have to explicitly add a rule on the firewall.

IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.

In the last 3 years I've noticed criminals focusing more and more on IPv6 scans to compromise devices and create botnets since it's much easier to find exposed/unpatched devices as most users don't understand how to correctly configure a firewall.

Most of the time, the only viable solution is to disable IPv6.




Those ISPs are broken and not following the RFCs or RIR guidelines.

There's nothing stopping you from using NAT with IPv6, people just don't do it because the only benefit of NAT is conserving limited address space. NAT on IPv6 just brings all downsides and no benefit because you (should) have no shortage of address space. In any case v6 with nat is no worse than legacy ip with nat, its just stupid because they're forcing a newer and better protocol to run in a degraded mode.

Consumer oriented routers and firewalls do not allow arbitrary inbound IPv6 connections by default, you have to explicitly enable them.

I still don't get scanned over IPv6, despite having a static /56 range for more than 10 years. Everything that's reachable over legacy IP is also reachable over v6, and i have several v6-only devices because i simply don't have enough legacy addresses for everything. Scanning v6 is extremely difficult, while the legacy blocks get scanned continuously.

Modern operating systems are not sitting there with exposed services by default, you have to manually open them up if you want. Simply connecting a win11 box to an open IPv6 connection is not going to get you joined to a botnet like connecting a winxp machine directly to a legacy connection did.

Modern devices are often exposed to hostile networks/users - every time you connect a portable device to a public wifi network you are exposing your device to the operators and other users of the network. Depending how that network is configured, you might be exposed to the internet too. You don't have any separate device between you and the hostile network, you are relying on the configuration of your machine itself.

ISP supplied routers are limited and generally garbage, this is a problem for legacy ip just as much as v6.


> the only benefit of NAT is conserving limited address space.

It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.


> It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.

A combination of: (a) my Asus AC-68U not allowing non-reply, inbound connections for IPv6, and (b) my clients using rotating, randomly generated addresses, accomplishes the exact same thing.

NAT doesn't add much over a decent stateful firewall with a default-deny rule on incoming connections.


hide might be generous as fingerprinting devices based on their characteristics is pretty well understood nowadays.


Why can't you use it as a firewall? It's weird, and against RFCs for your ISP to only give you a /64, but that should still be routed address space is routed through your router/firewall box, and therefore trivial to firewall with the normal tools. This is also pretty much the necessary topology, because if the box needs to do NAT for IPv4, it needs to terminate the address on the firewall too. You'd need separate interfaces to do some scheme where IPv6 was layer-2 to the ISP, and IPv4 terminated at the firewall.

Most/all such boxes, especially those deployed by ISPs, have a stateful firewall with an allow-out deny-in policy in place by default. I've never seen otherwise, but I guess it's possible?

Back in the day, cable modems didn't include a 'router' and lots of users plugged their Windows XP PCs into them and got compromised. Most weren't really blaming the ISP for this; go buy a router they said. And some providers will still just give you a public IP with full access by default when you plug into their demarc equipment; indeed many users want this because that's what Internet access should be. Security is on the end user. I don't see this situation as any different, though your ISP should know better than shipping insecure-by-default, this isn't really a problem with the protocol.


I'm dealing with this now as well..=(

Do you happen to have a reference from the RFC, about it being against spec to hand out just a /64?


Originally (2002) a /48 per site was recommended in RFC3177.

More recently (2011) RFC6177 took a more pragmatic / softened approach, but it does say:

      - it should be easy for an end site to obtain address space to
        number multiple subnets (i.e., a block larger than a single /64)
        and to support reasonable growth projections over long time
        periods (e.g., a decade or more).
I don't really understand why ISPs choose to be so stingy with allocations. An extra 8 bits of address space to allocate /56 instead of /64 costs them effectively nothing and has considerable operational benefits, simplifies CPE configuration etc. Just minds still living in IPv4 land I guess.


I suspect it's to make business plans artificially more appealing. After all, why offer a better service when instead you can just make your cheaper one worse?


It's not an RFC, but RIPE690 is pretty clear on the matter:

https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefi...


RouterOS v7 supports DHCPv6 prefix delegation. You can request a delegated /64 per downstream interface and announce itself as router using these prefixes. You can still use your MikroTik device as router, stateful firewall, proxy. You don't have to mess with smaller than /64 allocations on links unless your provider forces a broken CPE on you that doesn't support DHCPv6 prefix delegation.

Have you actually seen any large scale deployments of CPEs without an active IPv6 firewall blocking incoming connections by default?


Fritz!OS also does, it's used by many consumer routers in Germany. There is of course also OpenWRT.


I am doing this on my pfSense box. My ISP delegates me a /56 and I have them assigned to several different VLANs.


If I understand correctly, variable SLAAC tries to fix this by allowing you to further split a /64

https://datatracker.ietf.org/doc/draft-mishra-6man-variable-...


> There is only one "minor" issue: all major ISPs in my country ( Brazil ) only provide a single /64. You can't get another /64 unless you upgrade to a very expensive business plan.

And my ISP gives me a /56. What's your point? What you say is not a knock against the protocol, but stupid ISPs.

In fact, you're actually better off compared to IPv4. At least you now have publicly available IPs with can easily be connected to if you wish, rather than having to go through the silliness of port forwarding with NAT.

> IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.

Not on my Asus AC-68U: it has a default-deny rule on incoming connections. Only replies to existing connections are allowed.

Again: your critique is not against the protocol itself, but stupidity.


> There is only one "minor" issue: all major ISPs in my country ( Brazil ) only provide a single /64. You can't get another /64 unless you upgrade to a very expensive business plan.

I'm curious why you need multiple subnets at home; I at one point had separate subnets because I was using a wifi client as a ip level router, but was wondering what your use-case is.

> Although IPV4 + NAT had some issues, it ( accidentally? ) created a safe/sane default config for non-technical users. In order to open a port and expose a device, you have to explicitly add a rule on the firewall.

> IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.

I would like to humbly suggest that you don't remember what the internet was around the turn of the century with devices configuring IGD via UPnP so every device you hooked up to your home router automatically setup a port-mapping to put itself on the open internet.

Eventually everyone realized this sucked and UPnP NAT traversal was disabled everywhere. The same will happen (and actually more-or-less has already happened) with default-allow home routers switching to default-block.


>I'm curious why you need multiple subnets at home; I at one point had separate subnets because I was using a wifi client as a ip level router, but was wondering what your use-case is.

Not OP, but there are many use cases. First is device isolation so untrusted devices can be put in their own network while you can selectively add ressources from your main network via VLANs and add simple firewall rules because the untrusted network is a different interface on your VM than the others.

Second, you might want to put any managment interfaces (and ssh-enabled IPs) on a seperate network both for ease of organization and security.

Third, if you want to have your network services configured differently for different clients (think VPN vs local clients, adblocking DNS for mobile only) it's a lot easier to do that for whole subnets.


Same situation, I use IPv6 NAT and VPN, huge letdown but c'est la vie.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: