There were and still are are other global networks -- none of them come close to being anywhere near as open or interoperable. What's the next closest, PSTN maybe?

https://tunnelbroker.net

I was doing this back when I had BT in London, my internet speed back then was pretty abysmal and it would randomly drop routes- ironically this tunnel actually improved my internet (because of the routes not being dropped, not the speed).

  Our free tunnel broker service enables you to reach the IPv6 Internet by tunneling over existing IPv4 connections from your IPv6 enabled host or router to one of our IPv6 routers.

  https://tunnelbroker.net/

I strongly disagree. That's obsolete knowledge, thrown around by people who want to be considered security conscious but haven't actually updated their knowledge in many years. A statement with similar implications might be "security conscious operators require their users to rotate their passwords monthly", which is what a lot of people use to think a decade ago, and now what it really communicates is that you're talking to a dinosaur.

But if you've ever had to deal with endpoint security, if you're just doing static rule based blocking/throttling, /32 or /24 blocking is often your best option. Thanks to CGNAT this often means having a pretty large impact since an ISP's residential customer might end up getting randomly assigned a "bad" address and the cooldown for these rules is often months long or more.

In IPv6 land, you can just block a /128 or even a /64 and rarely hit anyone else in the crossfire.

Otherwise, what are the practical differences?

It is broken for you by upstream NAT and CGNAT.

Some carriers in my country have recently started to share the same IP between 4 customers, each having a port range (1-16363, ...), but you can always request a full IP for free.

Me as somewhat of a nerd, even doubt if I need a public IP, seeing how cyber security is looking today.

"On request" meaning you told your CPE equipment to send a DHCP-PD packet, i.e., you didn't have to call them and ask for something special with your account.

https://research.google/pubs/evaluating-ipv6-adoption-in-the...

There are domains like T-mobile US that are IPv6 only already. T-mobile runs NAT in the network so that all of IPv4 is NAT'd to IPv6.

I do think it is reasonable to expect there will become a time when IPv6 is pervasive enough, that new deployments will target users with IPv6 rather than IPv4.

Once IPv6 becomes the choice to support to get new customers, it is reasonable to expect that IPv4 support will start deteriorating and will eventually fade away.

I will be very surprised if we don't hit that tipping point in my lifetime. Say the next 30 years.

Plus dual-stack means more work, and more possibilities for misconfigurations or vulnerabilities in your network. It'd be way easier if you only had to worry about one or the other.

I live in the US and my ISP gives me one address I have to share across all the machines in my house. That's a tragedy - by all rights I should have a subnet or two. You can't directly address any of my servers from the outside on IPv4 which means I have to do hacky crap like port forwarding and can't use a lot of the older protocols that aren't NAT friendly. And I've got it good compared to most of the world!

IPv6 gives us back a large chunk of the original premise of the Internet - that all nodes are peers. IPv4 hasn't been able to do that for decades, and it's warped the way we think about networking by separating everyone into consumers and providers.

Meanwhile, CGNAT really solved most issues with IPv4. Yes, even the voice/video chat issues.

Want another fun example? Try to find a SIP telephony provider in the US that supports IPv6. Go on. I do this exercise about once a year.

Point being that patterns on small scales match patterns on larger scales.

* https://en.wikipedia.org/wiki/Metrication_in_Australia

It's going to take decades, mostly waiting for the non-metric folks to die off probably and the raised-on-metric folks to grow up, but if you don't start you'll never finish.

† Can Aussie HNer confirm?

I'm not saying that IPv6 is incompetent, or that IPv6 implementations break backward compatibility, or that the problem can be solved without breaking bc.

I'm saying that while IPv6 breaks bc itself, dual stack does not, and even full migrations can maintain bc or gracefully degraded.

In essence, not all implementations IPv6 are good, and not all migrations from IPv4 are responsible, if someone is blindly team IPv6 or blindly team IPv4 in general there's a lack of nuance.

The thing is, asking nicely doesn't always work. Sure, automated tools like docker/incus/wireguard/tailscale will respect it. But admins who don't want to be stuck typing long addresses? Not so much. I've lost count of how often I encounter a network admin that manually set their prefix to some fcXX::, when it's not outright fc00::.

Of course you can (and should) blame this on admins and not on IPv6, but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.

Hence my having a /64 (/48 in fact, should I ever enable more than the current /64) shows that 64-bits is enough for global addressing. If it wasn't then giving me a /64 would be part of a path to creating an address exhaustion problem just like the one with IPv4 (which was exacerbated somewhat by handing out /8 ranges unnecessarily in the early days).

Being an IETF draft means nothing at all, as covered in this IETF draft: https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/

Fine, let's change the question.

Without counting, how many zeroes are there in 192.168.0.0.0.0.0.1?

The protocol chosen for IPng, SIPP, did actually have "only" 64 bits, but this was deemed not enough as folks did not want to have to worry about running out again (amongst other reasons), and so tweaked it to have a fixed 128 bits:

* https://datatracker.ietf.org/doc/html/rfc1752

SIPP originally was variable-length capable, but it was decided fixed-length was better (e.g., for hardware like ASICs).

> Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.

For the record: IPv6 gives 10¹⁷ addresses per mm²; in terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.

See, no colons in sight!

You have 2002:47b1:11ab::/48. If your ISP supports it, packets sent to that /48 will be delivered to you as native v6 packets, otherwise they'll be stuffed into a v4 packet which will be sent to 71.177.17.171. Or there's ::ffff:71.177.17.171 which will reach you using unmodified v4 packets.

That's two different ways your v4 address is present in v6.

We are close to not having enough just for the servers people really want much less random things that should be contactable peer to peer.

NAT should not replace a firewall

Also some car entertainment systems with integrated 4G/5G use Dutch IPs. Which leads to the weird situation that I sometimes get dutch radio ads on TuneIn or some websites redirect to the Dutch version.

My experience is more the opposite. I keep seeing people say things like "I don't do v6 at home because I don't need it". These people are outright telling us that they're not going to start using v6 unless we make them need it.

Note that I didn't say "migrate to" v6. They're not even willing to do the first step of that ("start using v6"), even with no pressure to do the last step ("stop using v4").

I read an anecdote from Facebook that they had huge trouble getting their developers to stop writing v4-only code. Eventually they ended up removing v4 from their developer machines, who all of a sudden were able to write v6-capable code -- and it didn't take long for them to start asking when they could drop support for v4.

People will moan and moan and moan about v6 until you make them use it, at which point they discover that it was never as bad as they imagined it being.

Otherwise, your arguments about what "internet" is are flawed. IPv6 has been a thing for about 30 years, with a well-publicized problem with IPv4 address space and migration plan. I suspect that it's (IPv6) older than your hospital's contract. Even in the IPv4 world, your IP can change at any time and you can be put behind a NAT. That's why ISPs will sell you a static IP if you need one.

>> why do you need to stick with IPv4?

> To support devices and routes that do not have ipv6 support?

> Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?

After reading your response, I suspect the real problem is attitude and experience. The hospital should have IT staff that know to purchase a static IPv4 IP. This should be part of the contract with the ISP. If it wasn't, ultimately it's up to the IT staff to approach the ISP and arrange to purchase one.

I can tell you that in cicd for production Linux systems today, we have

  CONFIG_LEGACY_IP=""

_

What might work well for your organization is ZeroTier which will make you immune to what any ISPs do. The downside is your organization would be dependent on ZeroTier, but ZeroTier is much less likely to screw you over than any ISP.

  https://www.zerotier.com/

I appreciate your speculation on the principles of contract law. Like you, I believe those principles should be upheld and I believe in morality. If you lived under a monarchy and I were of the monarch, I would cross-examine your ISP in public and solve your problem in minutes. I would also on occasion take someone to the side of the road and chop off their head in front of the entire village, and everyone would know on a visceral level they are all much better off with someone taking out the trash now and then.

But, as many technical workers know, the contract stuff takes months or years to resolve, and technical issues involving IP addresses are best worked around with technical approaches.

_

What I would suggest your network team (you and whoever) do in your shoes is:

- set up NAT64 and DNS64 at the edges of subnets that contain devices that don't do IPv6 properly, because if these devices do not have updates to do IPv6 properly then they are broken in a fundamental way, and a workaround is necessary;

- dictate that starting on December 1st, all new devices and VMs have IPv6 addresses with all userspace services listening on IPv6 addresses or some nftables rule to kludge IPv6:$port -> 127.0.0.1:$port if necessary, with firewall configured to block that IPv6 traffic, then at a later date firewalls not blocking those IPv6 addresses, then at a later date prohibit any new IPv4 addresses being assigned anywhere with special exception to devices tagged "legacy" or "end of life" requiring documentation of such;

- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team -- in IPv6, multiple local gateways and multiple addresses on a network interface issued by those local gateways via RA is relatively a norm rather than an exception (requires userspace tooling in IPv4, DHCP doesn't have this functionality), so leverage this advantage;

- use IPv6 AH (authenticated headers) wherever possible;

- because in an ideal world, ISPs would behave consistently and IPv6 GUA addresses would always be stable, but we aren't living in an ideal world, so be ready to update your internal DNS to drop AAAA records containing IPv6 GUA that an upstream ISP fumbled;

- or, if you have the internal resources, register your own AS and command your own official block of IPv6 addresses;

- use a combination of OpenTOFU (Terraform) and Salt or Ansible, all versioned with Git, be very strict with your team about versioning with Git, to manage everything, and use

  terraform plan -detailed-exitcode

- move userspace services to Podman where possible.

Personally I like Salt. I know Ansible is more popular out there with more inertia.

_

>> why are we normalizing the removal of IPv4 addresses?

This was normalized a long time ago actually. "The future is already here, it's just not evenly distributed".

You and I are total strangers on different corners of the globe. You may not like what you're about to read, but it's better that you get a hint where the wind is blowing sooner than not.

If my team were consulting with your organization's execs and we caught a hint that the existing internal resources were not already proactively staying current with internet protocol (which is IPv6), we would point out there is urgency to start right away with emphasis that the existing internal team is over two decades behind staying current.

Or, if a detected hint the internal team were at all resistant to IPv6, we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.

Many network engineers at many ISPs would gladly drop all IPv4 traffic if they thought they could get away with it.

IPv6 only seems more complicated if you still need to unlearn IPv4. IPv6 does have a steeper learning curve, but once that learning curve is overcome, IPv6 is actually much simpler than IPv4. More people than not don't like reading RFCs, but professionals do slowly read RFCs on their own time.