> It's in the custoners' best interest to have unique publically routable addresses and without IPv6 we'll be stuck with CGNAT.
This is absolutely not a given. IoT has drastically changed the equation on how good it is to have devices exposed to unsolicited ingress connections from the internet by default.
This is speaking from experience of enabling ipv6 at an ISP. We were rewarded with:
- happy geeks
- anemic ipv6 usage
- a bunch of abuse reports and customer support hours wasted on people with poorly configured IoT (or just old computers with no recent patches).
We can either bury our heads in the sand, have a false sense of security behind CGNAT connections and keeping devices running without a firewall, commercialize IPv4 as much as possible to point of consuming loopback address spaces and make everything worse than it already is.
Or, we can move to IPv6. Yes, it might be painful for some people when they get their IoT devices hacked but at least it should spur change and make people realize that they can't just buy a toaster and connect it to the Internet.
Any decent router with IPv6 support sets up stateful v6 firewall rules blocking incoming connections and only allowing outgoing from your v6 subnet. Same as always like you say and most consumers won’t even notice a difference other than increased throughout.
There's a function in my ISP-provided internet router/gateway that allows me to disallow incoming connection on ipv6 address.
I guess you should implement this too?
If my understanding is correct, it's equivalent to using -m state --state ESTABLISHED,RELATED -j ACCEPT in linux/iptables where -P DROP is the default input policy.
Basically you allow ipv6 tcp traffic only for tcp connections initiated from within.
There is a key difference between having IPv6 (good) and not having a firewall as default (bad). I guess if you have many customers that don't use provided-by-you CPE that can be an issue.
NAT is not a security feature, not now, not ever. It stumbled into looking like one by accident and that is holding the industry back because people think it’s good for the internet can’t imagine life without one. Honestly it shouldn't even be part of the firewall—it’s just too easy to abuse there. NAT is really bad and we should want nothing to do with it in an IPv6 world. Stateful firewall rules work 100% fine in IPv6. There’s a lot of misunderstanding out there…
> This is absolutely not a given. IoT has drastically changed the equation on how good it is to have devices exposed to unsolicited ingress connections from the internet by default.
That's why firewalls exist. And they work with IPv6.
My ISP gives out an IPv6 address to my Asus, which also picks up some prefixes for allocation via DHCP-PD. This causes my printer pick up an IPv6 address, but it is not accessible to the outside world.
Statefull firewalls still exist with IPv6, so by default connections from the general Internal cannot connect to your 'internal' systems. Hole punching still needs to be done with UPNP/PCP:
The advantage of IPv6 is that you no longer have to have things like STUN, TURN, etc. (Remember Skype super-nodes?) Your client knows its own IP(v6) address, gets the IP address of the other end, and then tells your firewall to allow connections between just those two addresses. Once your session is done the ACL is deleted and you're completely default-blocked from the outside again.
Copy-pasting from a previous discussion a little while ago:
---
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table(s) it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 the address/port rewriting is not done.† Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.‡
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
The security comes from the state checking.
† It is possible to have private IPv6 addresses using ULA, and then the router/firewall uses NPTv6 to rewrite the prefix (leaving the /64 interface component alone).
‡ Just like with IPv4 (NAT), to allow unsolicited 'new' connections in you have to do do firewall hole punching with (e.g.) UPNP. But by default things are blocked.
This is absolutely not a given. IoT has drastically changed the equation on how good it is to have devices exposed to unsolicited ingress connections from the internet by default.
This is speaking from experience of enabling ipv6 at an ISP. We were rewarded with: - happy geeks
- anemic ipv6 usage
- a bunch of abuse reports and customer support hours wasted on people with poorly configured IoT (or just old computers with no recent patches).