How are we not out of IPv4 addresses already? Aren't there a billion phones out there? And probably the same number of PCs and god knows how many servers?
As I see it, IPv6 can't come fast enough. NAT really needs to die a death so people can actually use the internet fully, not only as a client or using hack-y work-arounds.
-IPv6 is fundamentally much more secure than IPv4 (no scanning, etc.)
-opt-out is bad for innovation, especially since the cheap default ISP router firewall software is likely to not even allow opt-out for any other protocols than TCP and UDP. (Heck, these days on IPv4 even anything different than HTTPS can be problematic...)
-reliance on router firewalls is bad because they incentivize sloppy device security - the manufacturers should be instead liable when they are at fault for screwing it up (also, how many of these "insecure IoT devices running ancient software" are even able to run IPv6 ?)
source : https://lafibre.info/ipv6/ipv6-le-firewall/msg704095/#msg704... (fr)
Incidentally, one of the "big 4" French ISPs "Free" didn't even have an IPv6 firewall on its customers routers between 2008 and 2019, and it's probably still opt-in : 4 months ago : https://fr.answers.yahoo.com/question/index?qid=202008121107... (fr)
So I guess that we're going to see in practice the problems that having no IPv6 firewall causes (most customers not having any idea about what even is a firewall) as it gets more popular... and since Free this summer boasted about reaching 99% IPv6 coverage, and is enabled by default, and can NOT be disabled...
The same was true for ipv4 until about a decade ago.
> opt-out is bad for innovation, especially since the cheap default ISP router firewall software is likely to not even allow opt-out for any other protocols than TCP and UDP. (Heck, these days on IPv4 even anything different than HTTPS can be problematic...)
I can't wait for conficker6 to innovate it's way around the ipv6 net.
> reliance on router firewalls is bad because they incentivize sloppy device security - the manufacturers should be instead liable when they are at fault for screwing it up (also, how many of these "insecure IoT devices running ancient software" are even able to run IPv6 ?)
Sounds like an excellent reason for an opt-out by standard. 99% of the world's internet users wouldn't have a clue how to manage a firewall. Directly connecting all their devices to the internet is an awful idea for 99% of the world.
Your 50/50 example is hugely biased, first it's on a Telco discussion forum so that clearly selects for technical users, then it's on ipv6 which is going to further select for technical people.
Go canvas 100 random people outside a supermarket if they want to have to manually manage a firewall for every device they connect to their network. If they don't give you a blank stare at that question remind them that includes everything from lightbulbs, washing machines, "smart" speakers, to their computers/phones (likely the only thing they think of as being connected to the internet). If you find more than 1 I'll eat my hat.
I don't own a hat.
As you can see I'm aware of that, they are also aware of that, and the discussion is not so much about themselves (since they know how to configure a firewall or even to install their own router), but about what your "average grandma" should get.
Especially interesting is this RFC : https://www.rfc-editor.org/rfc/rfc6092.html "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service"
It shows that there are lots of different filterings involved, so it looks like that these millions of residential users connected to the IPv6 Internet without router firewalls might still have some router filtering going on ?
Also, it confirms that "The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks.
As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here.
In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier."
So now I'm kind of confused as for the different meanings of 'filtering' and 'firewall' that might be used... The RFC seems to use 'firewall' in the sense of 'customizable firewall', while ISPs still often don't provide other options on their IPv6 'firewall' than 'ON/OFF'...
Yes, everyone should have a hardware firewall, but we both know most people just buy the cheapest thing, and by bad large, real firewall features are mostly targeted toward higher end devices.
More seriously; for 99% of people their ISP router handles NAT and firewall duties. Adding DENY ALL inbound and ALLOW ALL outbound isn't a great stretch for them on ipv6.
Speed is so much better with new ISP though so he just set up Wireguard to the VPS server he rents to get "his own" IP.
Despite this, it's able to connect to IPv4 web servers just fine.
All connections from the IPv6-only phone to IPv4-only web are automatically NAT'd to IPv4 by the cell service provider. I've tested this recently and it uses a different ephemeral source IPv4 after a few minutes when doing this. Tested with HTTP, HTTPS and ICMP ECHO. It is definitely NAT.
At the same time, my connections from the phone to IPv6-only web are not using NAT. The server sees the same source IPv6 as the phone reports as its own.
When I enable tethering on my phone, it creates a local IPv4 wireless LAN. Devices on that LAN such as my laptop access the web using IPv4, which is NAT'd twice: Once on the phone when crossing from the WLAN to the cell network, then by the cell service provider to get an ephemeral source IPv4. This is double NAT.
When the Linux VM on my laptop connects to an internet service and I'm using the Wifi hotspot on my phone, there's yet another NAT in the way, on the laptop itself. This is triple NAT.
All this NAT means it doesn't matter so much that we are out of IPv4 addresses for phones. They can connect to both IPv4-only and IPv6-only services while assigned only a public IPv6.
In fact phones don't need a public IPv6 either. They don't need any public address.
Those NAT'd IPv4 connections don't go over the IPv6 link. They are not being translated to IPv6 and back. Rather, they go over what is effectively a private IPv4 tunnel to the cell provider. Just as IPv4 connections can work like that, so could IPv6 so there's no real need for the phone to report that it has any public IPv6 or IPv4 address at all.
However, mine is currently reporting a public IPv6 and no IPv4, while able to make connections to both.
Only servers that need to be publicly accessed directly like a web server actually need a public IP.