Get me onto the network that's on the WAN interface of your router, disable the firewall on it, and I will.
How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
IPng is a new version of IP which is designed to be an evolutionary step
from IPv4. It is a natural increment to IPv4. It can be installed as a
normal software upgrade in internet devices and is interoperable with
the current IPv4. Its deployment strategy was designed to not have any
"flag" days.
If saying "we can't have/didn't do a flag day" in the design documents, and then not having a flag day, isn't enough to stop you from arguing that v6 should have been engineered without a flag day, I have to wonder what v6 could possibly have done to make you happy with it.
NAT is accepted for transition purposes; for example NAT64 makes it trivial to connect from v6-only clients to v4 servers, and is used by some large ISPs (e.g. T-Mobile in the US) to avoid running v4 inside their access network.
But v6 _is_ backwards compatible though? It's got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how is this not backwards compatible? You could make a reasonable argument that it has too many backwards compatibility methods, even.
> The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative
If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.
If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.
All you've done there is reinvent v6 with a combination of dual stack, NAT64 and 6to4, plus add a flag day.
You haven't fixed any of the problems involved in deploying v6, and you added a step that was known 35 years ago to be impossible on the Internet. This isn't a useful contribution, it's just a waste of time that you could have spent on doing v6.
That's basically no burden at all. If we cut the address length down to increase throughput, we would get a one-time increase of about 0.8% -- but consider how much faster Internet connections have gotten over the past 30 years. They've improved by about 0.8% per week on average. You're worrying about something that's smaller than one or two weeks of natural progress in Internet connection speeds
Rather than trying to minmax the address length, it makes more sense to sacrifice a few bits per packet to the addresses, wait a week or two on average to get the lost throughput back, and then spend those bits elsewhere to make other things easier. (For example, avoiding NAT is an obvious one, but even just "everything is a /64" removes the need to ever need to think about the size of a network.)
If you can spend a few address bits to make something easier elsewhere, that's a good trade. Maybe start worrying if the addresses were a kilobit long or something, but they aren't even close to that.
People are at work during the week, and work networks have a lower average deployment of v6 then home networks do. As evidence, you can also see the impact of holidays and COVID-19 lockdowns on the size of the dips.
If we're talking tangible, real-world threats in existing ISPs, then NAT is doing nothing to protect you. In fact it's doing the exact opposite, because without NAT you wouldn't be able to connect out from your network.
Even if you want to ignore the fact that most attacks arrive via outbound connections and restrict the discussion to just inbound ones... remove NAT and the exact same set of people that could connect to you before can still connect to you, so it's doing nothing for your inbound connections.
Google's stats claim that it's 10-20ms for many countries, for example both the US and Canada show the latency impact of v6 as being -10ms. This is per round trip too -- between the connection handshake, congestion window slow-start and serialized requests it adds up to something significantly bigger than a few hundred microseconds.
> let's not forget IPv6 is two separate island because two tier-1 carriers refuse to peer (Cogent & HE).
The Cogent island must be very small, because I'm single-homed on HE and had actually forgotten about that.
Or perhaps v6 isn't split into two separate islands after all, and this is just yet another weird claim people make about v6 that doesn't match reality.
It doesn't actually do that.
reply