IPv6 where your home network or backend infrastructure is a transparent glass house is a failure by design. I hope I never get to be a DevOps and support that. Or have IPv6 in my home network. One bad firewall rule or insecure port open, and you get ransomware in your face.
I have met a lot of infrastructure engineers who do that... then never give the people who need access access. So the system just sits and collects dust.
You have users. Acknowledge them. The network shouldn't even be the primary security boundary to begin with.
One bad firewall rule or insecure port open
Firewall !== routing. Nobody said you can't run a border firewall on your home network.
The thing about v6 is … you can just firewall permit like the entire North America block to whatever ports absolutely must be exposed … and just not get any attacking traffic?, at least if the address isn't somehow otherwise discoverable. This isn't possible on v4 (there is no such block, due to the space's fragmentation), and opening up v4 otherwise does expose you to a cesspool of incoming maliciousness. (Though … there are tools for this.)
If there was decent tooling available to me for "here are the IP addresses of the userbase" (e.g., some sort of phone-home system) that could keep the firewalls in sync with reality, I'd be more enthusiastic about it.
But the status quo is largely "security teams want IP firewalling, but don't want to figure out how to actually implement that in a manner that it will realistically work and not waste engineers time filing dozens of security requests".
I have a live feed of packets dropped by my firewall's "deny incoming on WAN by default" rule for fun, and I do occasionally see v6 packets being dropped. They're random addresses under the /48 that was delegated to me but which don't actually belong to any devices. So it doesn't seem to be because someone is actually harvesting IPs from my outgoing traffic, just guesswork. There was also one time where someone was very methodically testing every /64 by incrementing one at a time, with random bytes in the lower half, ie 2001:db8:abcd::$random, 2001:db8:abcd:1::$random, ...
The vast majority of dropped packets are v4 though.
Are IP addresses really such sensitive secrets from your POV?
* https://datatracker.ietf.org/doc/html/rfc3041
Updated in 2007:
You also don't have to use the MAC-based addresses on the server either. You can generate a random address and use that for your service.
Or you can regularly generate addresses on the server and update DNS so that the service has a new address every x hours or days. Or you could have the server not have any 'public' addresses, and whenever a new client wants to connect a new address is generated just for that client (with a TTL).
The former sound like a management problem. One call from up above and access will appear.
Well... too bad? Do you want security or not?
> neither is my mother, who also has a home network, etc.
If your hypothetical non-technical mother just buys a normal off-the-shelf router (+AP+switch+...) then it'll already have a firewall by default. It's not like end-users are expected to design/implement these things themselves.
If you're running a NAT, you're already running something much more complex than that.
It's not rocket science for CPE manufacturers to make "outbound connections only" the default. My home router does just that.
It's such a huge risk to show people what is in my network. It's such a huge risk to the business. It makes no sense to It makes no sense to reveal that. But I suppose telling you is not worth anyone's time, you're just going to say you like it better because you're a mobile developer.
> you're just going to say you like it better because you're a mobile developer.
Not sure what issues you have with mobile developers, but I'm not one, not that it should matter if the argument is sound.
NAT is provided by a stateful border firewall.
Are you using NAT on your border device? Gratz, you're running a border firewall on your home network.
In my case, that worked... Sometimes. It really doesn't scale. At all.
WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Of course. Unless you add rules to allow incoming traffic, say a rule to allow incoming traffic for $LAN_MACHINE1_IP:$PORT/tcp, to cross from WAN to LAN.
>At least with NAT there is a known set of rules regarding how masquerading works, that I can reason about.
The reason the scenario in my previous comment doesn't work has nothing to do with NAT. The reason such a packet would be dropped is because the firewall has a rule to filter bogons on the WAN interface. More generally, your home network firewall will have a default rule to block all incoming traffic on WAN unless explicitly allowed via additional rules, and that applies to both IPv4 and IPv6.
>WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Well if you trust your ISP so much then I assume you just have your firewall turned off always, right?
Yes!
> How does that work?
Stateful firewalling.
It's much simpler than NAT masquerading tables. Just imagine a NAT, but with all address and port mappings being the identity function.
With a default-deny rule in a stateful firewall?
Publicly addressable ≠ publicly reachable.
People also don't seem to have any issues getting hit by ransomware even in a world full of IPv4-only networks and NATs.
Also my network (dual stack) is quite orderly as far as I can tell, thank you very much. I promise I won't ask you for help if that ever changes, if it helps :)
No, it's like you're a fish trying to explain flying to birds.
You don't understand the fundamentals of IPv6 (among other things, in other comments you have revealed that you think IPv6 addresses are MAC-based, think Comcast is a wireless ISP, and aren't aware of stateful firewalls). You have so many misconceptions about IPv6 it's no wonder you hate it.
Please refer to RFC6092 "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service" (Jan 2011)
(Despite the 'recommended' in the title, this is made mandatory by other specifications.)
It does exactly what you ask for: "Proper security is when everything is closed off and inaccessible by default."
Not only that. PCI DSS explicitly requires hiding the network topology from outsiders - even though they cannot connect. So it is either NAT or very short-lived IPv6 addresses, and guess what - for internal audits of who did what, NAT works better.
only if you chose it be.
It doesn't differ from a public routable IPv4 block at all: or you explicitly allow anything being routed to addresses in that block - or not