Czech republic sets IPv4 end date | Hacker News Reader

Czech republic sets IPv4 end date

konecipv4.cz

367 pointsdeadbunny359 comments

OK so — I just migrated my personal website to use IPv6 only. It runs on AWS EC2, and my motivation was purely to save on paying the IPv4 fee that AWS is introducing next week. I put it behind Cloudflare which can provide an IPv4 proxy address for site visitors.

But the thing is, even though IPv6 is such well established tech, it was not a great migration experience.

I'm not a network engineer, and you have to figure out how to update a bunch of networking configuration to make this switch on an existing instance, with lots of potential footguns. Even after I got the IPv6 address provisioned and the virtual networking correctly configured, the connectivity was still broken until I found an obscure security group setting that was still set to allow only IPv4 traffic. A lot of basic debugging tools like curl are designed to use IPv4 by default. You have to figure out how to get your webserver (nginx in my case) to listen on the IPv6 interface, which is fiddly. And it's easy to inadvertently break ssh connectivity, which turns out to also be set up to expect IPv4 traffic only...

In the end, it took about 90 minutes of fiddling, including migrating to Cloudflare, fixing DNS, etc. I mean, it's fine. I learned some things.

But if we're all going to switch to an IPv6 world, it would really be nice if the systems and tooling made it slightly easier, somehow.

The thing is, with my mediocre $5 VPS, all I needed to do was copy four lines of config files (as documented by the VPS provider) and open a port in the firewall on the server itself, just like on IPv4.

Amazon is horribly behind on a lot of things (just look how long it took them to get DNSSEC working, and it took them a couple of tries to not break entire domains for people using it!). They're ahead of Azure, but that's about the best you can say about that.

I suppose it makes sense, IPv4 addressing is now an additional method to make money for Amazon, so why make it easy for customers to migrate?

Yep, it crossed my mind that AWS has no incentive to optimize this particular process since they have planned to monetize it :/

Yeah. That's a problem. A big problem.

If AT&T and AWS went IPv6 by default, most of the US would convert over quickly.

> If AT&T and AWS went IPv6 by default, most of the US would convert over quickly.

Comcast and the mobile carriers went ipv6 years ago, that's already something like over half the US endpoints? It hasn't sped adoption (Github STILL isn't ipv6 for git).

Another example, I've been trying to get Georgia Tech to fix their ipv6 linux mirrors for over half a year, they advertise they support ipv6 and publish AAAA records that don't work. http://rsync.gtlib.gatech.edu/ < check it out.

So yeah, even when it's deployed nobody checks to see if it's still working when ipv4 is fine.

That GTlib issue is frustrating. I've made a ticket -- maybe they'll prioritize a member of the GT community over a random person.

They already had one of the main Gentoo devs email them. Here's my bug report to Gentoo that prompted it: https://bugs.gentoo.org/911751

It's not the only issue it has continued to have.... https://bugs.gentoo.org/585524

> Thank you for contacting PACE. We appreciate your patience, as we are experiencing a larger volume of incidents and work-related activity. Please be mindful that we will begin our Maintenance Period starting at 6:00 AM on Tuesday, 01/23/2024, and tentatively plan to conclude by 11:59 PM on Friday, 01/26/2024.

I'll continue to follow up here, but it seems like an actual human has read the message this time.

> I'll continue to follow up here, but it seems like an actual human has read the message this time.

Any word? Why not look up email for one of the staff here https://www.pace.gatech.edu/staff seems like they unfortunately don't check any of the primary emails for the mirror as we've not heard from them in a year or two.

Again, we get it if they have upstream issues not being able to support ipv6, but drop the AAAA records and stop advertising it if that's the case, that's not a big request.

ATT and Comcast both have had perfectly working ipv6 with prefix delegation for years.

We need google to downrank v4-only sites

c'mon don't be silly

AT&T looks to be at ~ 68% already

https://radar.cloudflare.com/as7018

Or probably that's their way of forcing people to IPv6.

If they wanted people to migrate, they could first put a bit of effort into making their tools suck just a bit less on IPv6. It's not even "second class citizen" status, it's more "bastard stepchild of my least-favorite in-law" right now.

Also their sizeable ipv4 stockpile is kind of a moat and competitive advantage; it's pretty much guaranteed that no other cloud provider can reach their scale while ipv4 remains dominant. So they have some interest in delaying ipv6. It is quite perverse considering that ipv6 really should be quite ideal for hyperscale cloud.

Where is that VPS hosted?

Contabo. They've supported IPv6 for a decade now based on the date on their instructions (https://contabo.com/blog/adding-ipv6-connectivity-to-your-se...). Enabling IPv6 comes down to copying "gateway6: fe80::1" to your netplan file, adding the /64 listed in the control panel, and optionally adding an IPv6 DNS server. After a reboot (or sudo netplan apply) you'll have full IPv6 connectivity.

Well, their default images come with a script that'll allow you to `sudo -H enable_ipv6`, but I removed their customisations so I had to do it manually.

They have raised their prices since I last ordered a server there, it looks like €5,45 is the cheapest server you can get these days (includes VAT of course).

Terrific, thank you.

"even though IPv6 is such well established tech"

It's actually not, and I think you learned that, and why it's not, in this process. Sorry.

Introduction December 1995; 28 years ago

IPv4 is 43 years old

in december 01995 zero nsps and zero isps supported ipv6. you had to be on the 6bone, which didn't even exist until march 01996. also you probably had to write your own protocol stack because there wasn't an off-the-shelf one for your platform. in december 01995 what you had was a paper spec

June 6, 2012 is a better date; that was the "World IPv6 Launch Day".

But even that was negligible since nobody actually had IPv6 connectivity. Even now I still don't have a home wifi router that supports it, though at least my ISP does since last year.

The real driver of IPv6 was the rise of smartphones.

What router do you use that doesn't support IPv6?

It's a tp-link Archer, and since it supports Wi-Fi 6 it must have been from 2019 or later.

Hmm, I just went deep into the settings and there's an IPv6 toggle (disabled by default, and requires playing with menus to make it actually work) now. I don't remember seeing that (and I explicitly checked) when we switched the ISP-side last April. But the firmware is dated after that, so I choose to trust my memory.

Actually trying to connect to ipv6 stuff besides the router itself (in fd00::/8, that's good) just gives "Destination unreachable: Beyond scope of source address" though (probably because I only have an fe80 link-local address though?). If I play with the settings some more I get a ::/64 address, but that just gives me a black hole ... wait, is that even a legitimate address? Do I need to fill in the prefix manually or something?

I'll play with this some more in the morning I guess. But I certainly wouldn't expect a normal user to get IPv6 working under these circumstances if I haven't figured it out yet ...

You're trying too hard

Turn IPv6 with stateless RDNSS on (should be the default on all modern routers)

ping6 google.com

That's it as long as your ISP supports IPv6. No need to figure out a fd00::/8 that you maybe may not have.

That doesn't work any more than anything else.

I'm testing with `ping ipv6.google.com` as well as the router IPs. Between each change, I disconnect from wifi.

The router itself has a ping tool and can ping ipv6.google.com just fine. So I assume the upstream options are correct.

For the LAN, I have 4 options:

* ND Proxy gives me an fd/8 address. I can ping the router via its fd/8 or fe80 address, google blackholes.

* DHCPv6 gives me an ::/64 address. I can ping the router via its fd/8 or ::/64 addresses, google blackholes

* SLAAC + Stateless DHCP does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address

* SLAAC + RDNSS does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address

In all cases, the IPv6 addresses the router says are its DNS servers blackhole. I do have working DNS returning IPv6 address for google though; presumably because the ipv4 DNS server it advertises (which is the router itself) still works.

If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80. The ISP router is really bad, all it has is an "it's connected" indicator and a bunch of phone numbers and URLs for support.

Still bypassing, pinging `ip6-allnodes` gives me 3 responses, all with fe80::/64 addresses: my computer, an unknown, and the wifi router; I can ping those addresses, as well as the wifi router's fd/8 address.

Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address.

Hm, I just noticed that the last bit of the router's address varies between some of its addresses ...

fd::/8 addresses (really fc00::/7) are ULA addresses [0], defined as non-routable local addresses, so it’s expected that you can’t get out to the internet through just that address.

Do you have any smart home devices? Protocols like Thread and HomeKit establish their own randomly-generated ULA prefixes and advertise them through RA’s (router advertisements) and correctly-configured devices in your LAN will observe the RA for that network and generate a local address for it (including your router.) So just seeing a fd/8 address doesn’t mean your actual router gave you it, it just means that something on your network is using a ULA prefix.

Basically, it’s possible the real problem is that you’re not actually seeing an RA from a “real” (routable) IPv6 subnet when behind your router.

> If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80

When you do this, can you ping out? (`ping6 2607:f8b0:4004:c17::65` or something to rule out DNS issues.)

> Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address

What you want here is dhcpv6 and prefix delegation. This will make your router ask the ISP for a real IPv6 network to use, and upon receiving this from your ISP, will send RA’s out to your local network for a “real” (2607/16 or whatever) network. A prefix length of 64 should do it, unless you need multiple subnets inside your router. (People say dhcpv6 is obsolete by SLAAC, but prefix delegation is a different thing… if you want to have your own router obtain a network prefix from an ISP, DHCPv6+PD is the only way to do this.)

- [0] https://en.wikipedia.org/wiki/Unique_local_address

I still don't get why we need "6" versions of all the utilities. The fact that you need to use ping6 etc is a failure in itself.

Windows ping.exe supports both.

ping6 and ping4 are symlinks to ping on my system, and are equivalent to passing -4 or -6 to force a specific version. The default behavior negotiates either fine.

Well on my current GNU/Linux this is no longer required:

> sudo ping google.com PING google.com(par21s03-in-x0e.1e100.net (2a00:1450:4007:810::200e)) 56 data bytes

That's a leftover from back when IPv6 was very new (yes these utilities are that old), and the networking utilities (ping, traceroute, etc) understood only IPv4. It's no longer necessary, all relevant networking utilities have since been upgraded to work with both IPv4 and IPv6; you can use just "ping" with a IPv6 address and it should work.

> You can use just "ping" with a IPv6 address and it should work

Not on BSD-derived operating systems (macOS included). You must use ping6 to ping an IPv6 address (including a hostname that only publishes AAAA records.)

From `man ping6` on macOS Sonoma:

> There have been many discussions on why we separate ping6 and ping(8). Some people argued that it would be more convenient to uniform the ping command for both IPv4 and IPv6.

> The following are an answer to the request:

> From a developer's point of view: since the underling raw sockets API is totally different between IPv4 and IPv6, we would end up having two types of code base. There would actually be less benefit to uniform the two commands into a single command from the developer's standpoint.

> From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands.

> Not on BSD-derived operating systems (macOS included)

Not true. FreeBSD:

> ping -- send ICMP or ICMPv6 ECHO_REQUEST packets to network hosts

https://man.freebsd.org/cgi/man.cgi?ping(8)

Interesting. I’ve tried macOS and OpenBSD and they both require using ping6 to ping IPv6 addresses. I wonder if FreeBSD changed this recently or if it was always that way. Regardless, macOS is the elephant in the room here as it’s a lot more popular than any of the (other) BSD’s.

I often use ping to check if a machine is alive or is reachable at large. Then it might be more informative if ping tried all addresses the name resolves to. You wouldn't need to specify the protocol version.

My router supports it, but for my ISP asking for ipv6 risks getting put into a CGNAT for v4, so I choose to live without v6.

> June 6, 2012 is a better date; that was the "World IPv6 Launch Day".

2012? Wow, that's pretty bad. We were talking about how ridiculously slow IPv6 rollout was while I was at university, and that was 2002-06.

And? IPv6 is still under rather heavy development with significant changes still being made. As a user, I wouldn't call it well established because it's shifting too much still.

I have had IPv6 on every ISP I have been on since at least 2012 (http://web.archive.org/web/20120217204742/https://www.intern...)

It's fine. The only breakages I've had are when the ISP's v4 DHCP goes down (v6 websites keep working) or when IPv6 delegation fails somehow and my machines lose v6 (v6 only stuff breaks).

Your mobile phone probably already uses IPv6 (especially if you use VoLTE) and it's fine, too.

> "IPv4 is 43 years old"

As a fun aside, global smartphone sales in 2021 were 1.4Bn units. That alone is enough internet devices to exhaust the entire IPv4 address space every three years. I wonder if anyone was imagining that 43 years ago.

https://www.gartner.com/en/newsroom/press-releases/2022-03-0...

I disable ipv6 on my network, way too many security exploits!

Such as?

I don't have vulnerability ids.

What made me disable it was some issue in Linux network stack, with ipv6 broadcast, on by default, exploitable to root execution.

For me it is yet another complex service that I do not need, and that should not be exposed to network. Ipv4 network stack code is far smaller, simpler and way more tested over decades!

Firewall misconfigurations, mostly. It's way harder to keep firewall up to date when you have to worry about two independent stacks.

In my book, 90 minutes of fiddling in a case like this is pretty fast.'

Ideally it'd be 5 minutes (1 minute to locate and click a checkbox, 4 minutes to test all services from a few locations), but this is still fast. It includes zero tech support tickets, for instance.

Also my thought - only 90m for a single non-SME to migrate a full stack across two hosting providers? Sounds pretty good for something so fundamental!

And if I'm not wrong, AWS VPCs only support IPv4.

You can do dual stack with IPV6-only subnets: https://aws.amazon.com/blogs/networking-and-content-delivery...

curl, and likely many other tools, do not use IPv4 by default, but rather quickly and seamlessly fallback (“happy eyeballs”).

IPv4 is to AWS what iMessage is to Apple.

Actually, why doesn’t Apple mandate the IPv6 transition for iOS?

They have required that iOS apps must work in an IPv6-only environment for years.

That was an interesting decision.

At roughly the same time, Android added 'clatd' so existing apps would just work in an IPv6-only environment via NAT64.

Apple refused to implement clatd, instead forcing app developers to fix their own code. More work upfront, but now iOS apps should have an easier time transitioning their server-side components to IPv6, compared to Android apps.

This is an AWS/cloud issue rather than an IPv6 issue. With any decent VPS provider ipv6 just works. AWS needs better defaults

FWIW, I'd love to see a blog post or similar that would lead me through the steps to do precisely this – including the nginx config.

> an obscure security group setting that was still set to allow only IPv4 traffic

Which setting was that? I've had 0 issues with IPv6 on EC2 for a while now. Not all services support v6, though, but that's a separate issue.

> I found an obscure security group setting that was still set to allow only IPv4 traffic

This has more to do with AWS, less with IPv6.

I have to appreciate the Brazilian effort for promoting IPv6. I attended a talk on a university about 5 years ago where members of the Brazilian Internet Steering Committee (CGI.br) talked about IPv6 and why it's the future.

It was very informative, and I also found out they offer free courses about IPv6 networking, with certificates included.

I think CZ.NIC offers something similar, but they should be promoted more often so sysadmins can prepare themselves for the eventual shutdown of public IPv4 addresses.

I think Tailscale does IPv6 out of the box so installing a Tailscale client might be an option for ssh etc.

For some AWS services, such as Elastic Beanstalk, there appears to be no way to avoid consuming a public IPv4 address on the EC2 instances, except by introducing a NAT gateway.

(And "NAT gateways are an extremely cost prohibitive device in AWS, costing at least as much per day as medium sized EC2 instances!")

https://github.com/aws/elastic-beanstalk-roadmap/issues/208

I've got to make the same migration this coming weekend. Any information or links would be appreciated!

I'm sure that many HNers would appreciate the information here, but if you prefer my Gmail username is the same as my HN username. Thank you!

One of the comments in the thread links to a useful writeup for the AWS side:

https://www.knowmatic.app/how-to-migrate-aws-ec2-instance-fr...

I didn't find such great docs on the Cloudflare part, but some of these were useful:

https://www.reddit.com/r/selfhosted/comments/14d16lt/if_i_on...

https://community.cloudflare.com/t/the-page-isn-t-redirectin...

https://stackoverflow.com/questions/4616521/nginx-configurat...

https://developers.cloudflare.com/support/troubleshooting/cl...

people will do anything except for renting a 5€/mo vps

I mean, I used to rent the $5/month VPS, and it worked well. In fact, it had much nicer developer experience than EC2 for many reasons. But my provider (digitalocean) raised the price, and I don't really need a lot of CPU resources to serve mostly static files plus a couple of tiny server processes that get very very low traffic. So I downsized to a tiny EC2 instance.

I would go back to the 5/mo VPS if it became clearly better than the alternative. I don't really need an IPv4 for what I use it for, though, as long as someone else wants to provide an inexpensive (or free tier) proxy service.

Reading this reminded me of my recent pains of migrating my EC2 to IPv6. I ended up writing a guide on it. Take a look if it helps!

https://news.ycombinator.com/item?id=39111148

Conversion to IPv6 is an item in the 14th Five Year Plan (2021-2025) of the People's Republic of China.[1]

"We will accelerate the large-scale deployment of 5G networks, increase the user penetration rate to 56%, and promote the upgrade of gigabit optical fiber networks. We will build up technology reserves for the future deployment of 6G network technology. We will expand backbone network interconnection nodes, set up a number of new international communication gateways, and comprehensively promote the commercial deployment of Internet Protocol Version 6 (IPv6)."

There is a migration schedule.[2][3] As of this month, there are supposed to be no new IPv4 services. The goal is IPv6 only by 2030. Actual adoption in China is reportedly only 25-30%, though.

[1] https://cset.georgetown.edu/wp-content/uploads/t0284_14th_Fi...

[2] https://blog.apnic.net/2019/06/06/100-by-2025-china-getting-...

[3] https://www.theregister.com/2023/04/28/china_ipv6_control_ad...

I grow up in China seeing news about the policy of IPv6 adoption every year, but the real adoption rate is still abysmal here.

Is everything NATted? With such a high population it seems hard to manage with limited IPv4 addresses.

yep

I thought they were very accessible in the education (i.e. university) network.

It is visible in the APNIC Labs measurement at 30% and within different AS of China Mobile at 65% or better, it depends province by provice, and provider by provider.

https://stats.labs.apnic.net/ipv6/CN

I don't call this abysmal at all. It very possibly is higher, there are reasons why APNIC may undercount, but noting that APNIC and Akamai tend to agree on their numbers.

Google's own numbers for China are far lower for reasons which do not affect the APNIC or Akamai data.

Majority of them are mobile phones IIRC.

Not nothing, but the adoption rate of IPV6 on computer side is still very low.

Virtually all of India is phones and tablets. It's the highest ipv6 economy. If your criterion is "not handheld devices" then I ask, what makes desktop computers so special?

I believe 80% or more of the planets internet is handhelds.

You think the US home users on comcast are all PC's?

> what makes desktop computers so special

More on the technical side. Most of mobile devices and their modems need (or even allow) zero to no manual configuration, so adopting ipv6 with these hardwares are easy -- the ISP just need to deal with their side.

This is in contrast to "fixed-line" internet devices like computers and their routers.

> what makes desktop computers so special?

Non-casual computing and multiple screens. ex: Work, research, editing, complex creation, engineering...

Mobile can sometimes touch those things but the core is mostly done on desktops.

A lot of people, including young people, throughout Asia don't have computers. A large number of working adults our age (however old you may be) don't touch desktop or laptop computers at all on their day to day. A huge number of people only have phones in their home and only use phones for their work. Plenty of companies also use tablets with specialized apps in places where a western company would use a PC. Finding 20-30 somethings in Asia who are educated and employed who don't know how to use a mouse isn't uncommon. I've encountered it loads of times with new employees in various offices.

From my own experience,

1. Most Chinese websites or apps don't work properly or at all in a pure IPv6 setting. They claim to be IPv6 compatible, but have a lot of problems (e.g. images not loading).

2. Most Wi-Fi networks (be it home WiFi, restaurant WiFi, hotel WiFi, school WiFi, etc.) have no IPv6 addresses. Half of the IPv6 enabled WiFi networks I've ever seen are set up by myself.

Seems to me that it's the same everywhere. It's not that there are no new IPv6 deployments, it's just that the rate of change is slow.

that's surprising to me considering the vast majority of Chinese netizens have come online way after IPv6 was determined to be the future.

Also, in a country of more than a billion people, most of whom use the internet with at least 1 device, IPv4 quickly leads to address shortages.

ipv4 already supports billions of devices with millions of addresses. china surely knows about cgnat and rfc1918

CGNAT

Something that isn't talked much about IPv6 and I believe has subtle and indirect influence on it's adoption is that it is far far far less human-readable than IPv4.

You can't find me a single sysadmin or casual user who would look at an IPv6 and say, nice, I prefer that one over an IPv4 or find it easier to type or communicate.

You can argue about merits of IPv6 and very reasonably so all day long, but this fact remains.

I don't think governments or other institutions can strong-arm IPv4 out of existence. I don't know what the long term solution would look like, but I strongly doubt it will be IPv6-only. Ever.

"IPv6 addresses are ugly" is only an argument for as long as ipv4 addresses don't cost anything. as soon as they put a price on it, nobody's going to care.

Arguing that "we can price IPv4 out" only reinforces my point; of course, ignoring the fact that it is a pipe-dream. But the fact remains, no one really prefers IPv6 over IPv4.

I do.

Just like users prefer domain names over ip's. But they are necessary.

I started to prefer it after I foundout that with IPv6 every Docker container can have its own IP address and this can be used to solve the hairpin NAT problem.

That happened a long time ago.

And yet still, nobody cares.

AWS starting to charge per-address next week is making a whole lot of people start caring.

There is over 1 billion users with less than 5% on IPv6 in China alone. Some 200 million users in Indonesia with less than 15% on IPv6.

Hundreds of million of users in Africa that are growing at a very fast pace, still on IPv4.

In Europe outside Germany and Belgium, the IPv6 usage is between 5-20% max. Millions of people.

There is also millions of industrial systems, ATMs (heck, some of them still run XP!), and whatnot that will not get IPv6 short of complete replacement.

You can't price IPv4 out with that kind of numbers combined with the fact that it is an extremely open market.

IPv6 adoption is low now, but the answer isn't to just give up and stick with IPv4 forever.

As the extra cost of IPv4 keeps rising it will sooner or later outprice the cost of moving to IPv6.

Similar as with fossil fuel cars -- super convenient, there are petrol stations everywhere. But as the price started rising (assisted by very harsh taxation) suddenly the idea of switching to electric didn't seem so bad.

Where are you getting the numbers from? According to APNIC, >30% of China is on IPv6 right now.

There is a very sizable IPv6 population in Asia.

https://stats.labs.apnic.net/ipv6

CISCO and Google, I am not sure what kind of sampling APNIC uses but that does seem pretty off.

https://6lab.cisco.com/stats/cible.php?country=CN&option=pre...

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Note that Google is restricted in China. Their data is not necessarily accurate.

> Something that isn't talked much about IPv6 and I believe has subtle and indirect influence on it's adoption is that it is far far far less human-readable than IPv4

What? This comes up in like 95% of ipv6 threads on HN (see also: ‘they should have just added an extra quad to v4 addresses’)

    My grand father used the dots in the address!
    My father used the dots in the address!
    I used the dots in the address!
    Henceforth every human being should use the dots in the address till heat death of the universe!

I'm certain the issue here isn't the dots.

123.123.238.217.110.100.1.1 would still have been perfectly readable.

fdd2:1228:3372:1sdf meanwhile is pretty unreadable even at IPv4 length.

ipv6 is 16 bytes, so more like

123.123.238.217.110.100.12.255.123.123.238.217.110.100.242.176

True, but we probably don’t actually need enough bytes to address all the atoms on the surface of the earth a hundred times over.

Good! If we did then we should've made it bigger.

We don't know exactly how many address bits we're ultimately going to end up needing. Our only options are to go for "too big" or "too small". Giving how much effort it takes to deploy a new IP protocol, we should err on the side of having too many addresses rather than too few.

I don’t understand… why do you consider the way longer one to be more readable than the shorter one? I find the colon string a lot easier to read, a lot easier to compare at a glance, and a lot easier to memorize.

The original idea was that configuration would be so automatic that humans would never see the addresses. Instead of an admin assigning a name and IP address to each host, the admin would only assign the name. The host would figure out its local topography from Neighbor Discovery then tell the dns where it's connected. I'm not sure how well that worked out in practice.

It didn't work in practice. In many situations names don't work. One example would be games with local lan support, and you use IP addresses to make sure you are connecting to the right server. Other would be tiny embedded devices, that are not powerful enough to scan the network and need a hard-coded or user configurable IP address to connect to the right place.

> that are not powerful enough to scan the network

just look at the ND table. Nobody is ever going to scan a single /64 of v6, ever.

Then why do I still have to see the addresses?

...

how would configuring DNS even work without having to see the addresses, and how would SSH'ing to a device on the LAN work without seeing the addresses

NetBIOS/WINS protocol could discover names -> IPs by broadcast, more modernly Zeroconf/Bonjour can do it, and if there's some organization then DHCP servers can register hostnames in DNS when handing out addresses.

That requires every device to be given a LAN-unique name...

...which a local IP address is, conveniently

ipv6 is so design by commitee that it's ... not worth the trouble ... as a hobbyist. You just described a scenario where you need 3 services for the machines in the same local network to talk to each other.

I'm not willing to spend the time to set it up on my internal network until I start to lose connectivity to some places, sorry.

To be clear, I'm not defending it, just describing it. I was at the IETF meetings where all this was being discussed and remember thinking it would never work.

When people tell me ipv6 is already widely used, I ask them what name I should use when I want to ssh to their ipv6 device, their phone for example. People don't notice ipv6 isn't working because the Internet has evolved into a world of two classes of people, the rich and powerful like Amazon with addressable IP endpoints, and the second class citizens like you and me who can only connect to the rich and powerful, not to each other.

Technically I have a business connection going into my home with a public fixed ipv4 and probably a fixed ipv6, if only i could be bothered to configure pppd and whatever 5 other daemons i need to install.

Problem is, that's not my only fiber. I have two from different ISPs (Romania, so they're cheap). With ipv4 i only need to change the default route to the other router to choose which ISP i use. With ipv6 where my internal machines get an address from the ISP, i don't know where to start.

And I definitely don't want to spend a couple thousand on an "enterprise" multi home router that will do it for me...

I'm a sysadmin and find IPv6 easier to use. You can easily make short ipv6 address just by having a larger prefix and then omitting zeroes (with `::`) in your host-part that you don't need.

Take `2001:db8::1`. Here `2001:db:8` would be your network address and `1` your host-id. For example, a router. `2001:db8:2` could be a server and so on.

I don't imagine it's easy to get a global /32, so do you mean for purely local networks? In which case why not use 1::1?

Its easy to get a global /44 - /48, which is not that much more.

The prefix I get from my ISP is a complete 56 bits, more or less. Thus even if I use ::1 on the inside, it's very long and tedious to type. ULAs are better but are still supposed to be 48 bits[1].

[1]: https://en.wikipedia.org/wiki/Unique_local_address

> Something that isn't talked much about IPv6 and I believe has subtle and indirect influence on it's adoption is that it is far far far less human-readable than IPv4.

No shit Sherlock: an IPv4 is 4 bytes. An IPv6 requires 16. This is four times as much data, it has to be less readable, that’s just the price of a bigger address space.

Now one could have argued that 8 bytes, heck, even 6 bytes, would have been enough. I guess it would have, but having a /48, or even a /64 range, per user, is quite convenient: we can ditch the NAT (we probably won’t, but we can).

But even then, 8, or even 6 bytes, remain harder to read than 4.

The number of bytes isn't what makes it hard, "habanero eardrum" is 16 bytes and much easier to remember, there probably is a way to make ipv6 addresses easier to use, but hard to do now.

[prefix]::1 [prefix]::2 ... [prefix]::ffff

Or if you want mnemonics on your /64:

[prefix]::dead:beef:1 [prefix]::b00b:1 [prefix]::b00b:2

etc

"habanero eardrum" is actually less than 4 bytes -- let's say 12 bits for a common word (eardrum) + 16 bits for an uncommon word (habanero).

If it were 16 bytes, the other options from the same 16-bytes space would be, for example, "\xa3\x80W%\xa3\x82\xa1\xea\x10\xf9\x8b\x07'\xf93J" or "\xf0\xef\x9b\x8f[0\xe5\xb9,\x0b\xd4^\xb00\xed\x00" (chosen by a fair /dev/urandom roll).

If you want to convey 16 bytes using similar encoding, you need to use about 10 to 12 human words -- see for example Bitcoin wallet 12-word seed phrases or https://xkcd.com/936/ (xkcd correct horse battery staple).

For IPv6, if your addresses are not SLAAC, but DHCP or manually assigned, you can go with half of it - the "random" part is the 64bit network prefix.

We just need to agree on a 2^16 word dictionary, each 16-bit segment gets it's own word. Then we can write addresses such as correct:horse:battery:staple::one .

Hoe does it affect DNS adblocking?

ipv6 should render any use of static blocklists moot, but i would not hold my breath for blocklist vendors to go out of business

As a private user, as long as I remember the prefix assigned to my connection I much prefer having a stable [prefix]::dead:beef or ::f007:1 and ::f007:2 etc compared to the ever-changing 85.nnn.nnn.nnn v4 address.

Or simply just /think/ of it as a /112 subnet with [prefix]::0001-ffff available - still room for 65535 addresses in that one, more than I'll ever need.

No need to rely on long autogenerated SLAAC addressses if you don't want to, you can have whatever you want after your prefix and you don't have to pad it out with garbage random-ish values. A sysadmin can get creative :)

Of course your ISP will need to have proper v6 support.

I thought the whole purpose of DNS was to avoid having to deal with IP addresses?

And how do you configure your DNS and network subnets?

How often are you communicating IP addresses? Is that not the point of domains, because humans are rather terrible at remembering sequences of numbers?

Sure, if DNS was always reliable 100% of the time.

Also, in our desktop/laptops, we set the DNS servers to an IP address, not to a hostname.

I believe it's more about using :: as separator instead of dot. There must be a reason why no one wanted to copy it from C++.

Click saver:

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown

In the U.S. I run into issues most commonly with businesses. Consumer ISPs and mobile operators all seem to have IPv6. Hosting providers (and recently cloud providers...) all have dual stack or v6 only. However I don't think I've ever worked anywhere that actually had an IPv6 network (at least on the office side)

If I even turn on IPv6 in my network, my VPN to work stops working entirely. Supremely annoying.

probably missing v6 default route over the tunnel

This is good since their adoption rates are low compared to other nearby countries (France, Germany, Austria).

Oh, for all of those that keep saying it will take forever for the USA to switch to IPv6 follow the link with your cell phone.

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Minor question, does using IPv6 makes it easier to track people than when using IPv4?

For some people, but most people are very easily trackable using IPv4 + user agent. There are even better JS fingerprints that don’t use your IP.

In general, no. All operating systems default to using random host bits in SLAAC addresses, each bootup (or change of network interface) will instantiate a new address.

More than that though, IP addresses in both v4 and v6 varieties are unreliable sources for tracking and basically no actor you'd want to guard against depends on them anyway. With mobile phones being common, your public addresses are changing all the time anyway. On IPv4, CGNAT is becoming increasingly more common so that you might share a public IPv4 address with thousands of other people at the same time.

> On IPv4, CGNAT is becoming increasingly more common so that you might share a public IPv4 address with thousands of other people at the same time.

Which is an advantage from an anti-tracking perspective — an advantage you won’t get with IPv6, no?

A counterpoint is that by cycling through IPv6 addresses no one can ever tell who is who by addresses alone. Okay, they could probably tell from the IPv6 prefix because the entire company/household shares it, but people used to ("use to" if you live in a Western country, probably) share the same public IPv4 address too so I find that point rather moot.

Another very strong counterpoint to this is that, you can't really build a truly-P2P network nor self-host a service on Internet, when everyone is behind CGNAT. At some point, as IPv4 resources get scarcer, only corporates will have the ability to host services on the Internet, and I don't think it is in their interests to host Tor nodes, for example...

You get a new IPv6 address very quickly (mostly every day or every week). That makes tracking difficult too. While the prefix is mostly stable, that is akin to the public CGNAT address.

It's not really, since an IPv6 /64 prefix has one customer behind it while a CGNAT has N customers.

I mean people are just going to log into their gmail account in their chrome browser and it doesn’t matter if you change IP’s every single minute, that identity isn’t changing as often and the relevant information Google wants will be tracked.

> Which is an advantage from an anti-tracking perspective

Depends. It makes it harder for someone outside your ISP to track you, but it makes it easier for your ISP to track you, and harder for them to justify not keeping logs of where you've connected to (since that data is necessary for their CGNAT system to work).

SLACC dynamic address are basically the same as IPv4 NAT from this perspective. Everyone who cares has tables of the prefix size assigned to customers in various providers' IP space.

> All operating systems default to using random host bits in SLAAC addresses, each bootup (or change of network interface) will instantiate a new address.

Great, so I can't connect my laptop to my desktop across reboots without setting up some internal dns?

No, IPv6 devices are typically assigned both a permanent IPv6 address and a temporary one. When using the internet, it uses the temporary address for privacy reasons.

"Typically". Would you care to list all the acronyms one needs to learn about to get to 'typically' if you need to hand configure your network?

If you want to hand configure your network, set up DHCP and disable SLACC. I wouldn't recommend it, because it just makes life harder, but you can do it.

Even better though, hostname resolution works just fine on link local addresses (fe80::/16), you needn't care about public addresses to communicate on a LAN. Or hell, you're on a LAN, keep configuring IPv4 they way you always have.

On Windows, you will see a "temporary IPv6 address" and "IPv6 address" on your network configuration screen. On Linux, you will see an IPv6 address without a temporary tag, and an IPv6 address with one, when you run the command `ip address`:

    inet6 2406:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:62c9/64 scope global temporary dynamic 
    inet6 2406:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:a31c/64 scope global dynamic mngtmpaddr noprefixroute

Temporary IPv6 address changes every now and then, but your stable IPv6 address will never change unless your ISP changes your prefix, you change your network, or your network card entirely.

When you are browsing the internet, the OS will use the temporary address for outgoing connections (unless the application forces stable addressing). But when you are hosting a service, you give your users (in this case, your laptop) the stable address.

It can in the near term, as each endpoint has a unique public identifier instead of being mixed with multiple endpoints behind a NAT gateway, but less so over the long term, as privacy addresses are typically rotated at least daily.

Of course, all of this needs to be included in a broader discussion around myriad vectors of tracking and fingerprinting to arrive at a meaningful conclusion.

IPv6 privacy addressing reduces tracking.

... within the same prefix.

Yes and no.

With limited IPv4, many places have dynamic IPv4 in a way or another, or have IPv4 behind some sort of NAT, so the actual IP of the accessing device may be hidden, or are private addresses. Anyway, that doesn't mean that i.e. your ISP couldn't be asked what person was using certain dynamic IP at some time.

With IPv6 it depends on implementation. Your device may have a public IPv6 address, persistent or not, and you don't need to be behind some sort of NAT (unless it is something to access ipv4 addresses), so if a lot of those conditions apply you might be tracked.

But there is a lot of conditionals in both sides, and the elephant in the room is that you are tracked for more things than just your IP address.

You can be tracked with either, but IPv6 is not functionally worse than IPv4 in that regard. You could argue that IPv6 is less anonymous than CGNAT, but CGNATs usually have to keep detailed logs, so that balances out.

All the tricks for anonymizing IPv4 (VPN, NAT, Tor, etc.) are equally feasible on IPv6.

Of course it is, that's why conversion to IPv6 is an item in the 14th Five Year Plan (2021-2025) of the People's Republic of China

Depends if you randomize the host-part or not. IPv6 has a feature called privacy extensions.

https://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch06s05.html

yes, because even the network part has double the entropy than an v4 address and there probably is no nat involved.

practically irrelevant thou, because your browser is a much better source of fingerprinting data

Tangentially, I thought Czechia is the modern and practical name for the country. "Czech republic" was used for many years, for reasons which I never understood, even though nobody says "Italian republic" or "German federal republic". If you insist on using an old name, you might as well chose "Bohemia".

Bohemia is one of three historical states comprising the Czech Republic, the other two being Moravia and Silesia. I can't speak for all Czech people, but I can tell you there is a sizable group who don't like the name Czechia because its Czech equivalent "Cesko" while nowadays officially recognized as a short version of the country's name was originally only a conversational short name and it feels far from proper and official both as the Czech version, "Cesko", and in the English translation, "Czechia". I would be interested in a poll of the Czech public quantifying people's preferences towards which name they prefer to see how small a hill I am choosing to die on actually.

BTW the full name includes the definite article, so it is "the Czech Republic".

The reason is very similar to why people from United Kingdom get upset when you call it England. Czechia is at same time name of the main region and (now) the country as a whole.

Funnily enough the distinction between regions exists in english language - Bohemia being the name of the region. So Czechia as name for country could work. But in czech language word for Bohemia region is "Czechia" (there is no Bohemia).

So thats why for years you had people insisting on the Czech Republic. Because you don't want to overlook the other two regions Moravia and Silesia.

> But in czech language word for Bohemia region is "Czechia" (there is no Bohemia).

No. Bohemia is Čechy, Czechia is Česko.

Yes, they are sometimes confused, and maybe people are unhappy with Česko because it's just too similar to Čechy. People from Moravia and Silesia feel underrepresented when someone mistakenly uses "Čechy" (Bohemia) for the entire Česko (Czechia; Bohemia+Moravia+Silesia).

For 2032… we got a minute

Right before unix time_t eh.

Might as well blow it all up at once

an 8 year gap

What I worry about in a fully adopted IPv6 world, are the old Games that run on IPv4 p2p. (like C&C3)

Sure, you can do a IPv4 VPN with your friends, but that means no more games with strangers over the internet.

Adoption of IPv6 by large organizations for their services doesn't make IPv4 go away.

And even if ISPs stopped issuing IPv4 addresses to end users, there's nothing stopping anyone from setting up a public VPN into an IPv4-based virtual LAN -- if there was demand for it, it could easily be offered by the same services you're currently using to find "strangers over the internet" right now.

This is great, I hope we have more organizations follow.

Not that I think we should entirely/forcefully remove ipv4, but saying that it's going away will force ipv6 migrations

good - it’s time to put ipv4 to pasture

Or maybe keep it only for local networks?

Won't you always be able to use it for local networks? I like NAT and regardless of IPv6, I think I'll keep my home network as IPv4 in a NAT and completely block outgoing and incoming per-device-IPv6.

> Won't you always be able to use it for local networks?

Well for me until Linux shall support IPv4 my machines shall be on IPv4 behind NAT. And yet I'm enjoying IPv6 with my ISP-provider router transparently doing the heavy lifting and using IPv6.

> and completely block outgoing and incoming per-device-IPv6.

Same. I do just that: it's disable by a kernel parameter, in sysctl and in the firewall, just in case I'd mess up and re-enable one or two of these.

You can pry IPv4 on my LAN from my cold dead hands.

How is your isp provided router doing the heavy lifting? You’ve turned off IPv6… you won’t be able to reach IPv6 resources.

In my case I run a double NAT. I don't consider the subnet which the ISP's router offers to me as something belonging to me, but something the ISP owns. In that subnet I have one honeypot (old Raspi) and a router which treats that subnet as the internet and offers me my own subnet which I call home.

I don't care what the ISP does with the router it provides to me. If it uses IPv6 or whatever. In my case their router will only see another device which is only capable of using IPv4, so it better deal with it.

What happens if you try to reach e.g. https://loopsofzen.uk/? It sounds like it's not going to work.

Nobody is suggesting you stop using v4 on your LAN, but you do need to use v6 on it.

That won't work if you need to access IPv6-only services (as the Czech government will make theirs). In other cases it may "work" but perform worse than IPv6.

Why the desire for a NAT? It's technically possible on IPv6 too (NAT66), but SLAAC dynamic addresses + a non-NAT firewall + possibly ULA are generally a better way to get the combination of privacy + security + local addressing I think most people associate with NAT in IPv4.

You can use certainly v4 for however long you like, but you still need to use v6 as well, because you can't connect to v6 addresses using v4. (If you could, we wouldn't need v6 in the first place.)

If you want to avoid v6 altogether, you can use a proxy on the machine you're currently calling your router, and configure all of your programs to use the proxy. But... nobody wants to use proxies.

You know you can assign both IPv4 and IPv6 addresses to the same device? You can access things locally by IPv4 and have it talk to the internet via IPv6. Not sure why you'd want to but it's completely possible.

Is IPV6 really that hard. I question why there are so many MrRobot-tier-hackers on HN who just wilt in the face of learning something new.

Have you tried it?

Yes. In fact my ESP32-C3 project I just made is posting to HiveMQ.io right now via IPV6.

I've configured and preferred IPv6 everywhere. My home computer, my VPS, etc. But, local address is something I can't figure out in IPv6.

It’s been a while cause work forced me to stay with IPv4, but I spent a day on this a few years ago, and I remember IPv6 being radically easier.

Isn’t it just a prefix?

I'm talking about the LAN address. The globally routable address changes every time I reboot my router, so I don't use that for LAN. But my LAN IPv6 address isn't better. I don't know if it is stable, and it is too long. For example, my current link local address is [fe80::7713:e154:21d8:464]. Who's gonna remember or type that?

Sure, if you want to make your life harder by running two different protocols that will always be an option. Why not run IPX and AppleTalk too?

On local networks is where IPv6 is the most advantageous to me right now.

For the Internet use, it's mostly just more addresses to me, but on LANs, there are so many more useful features. Unique link local addresses, various multicast addresses...

I can drop 10 new devices into a VLAN, and ping ff02::1%iface to enumerate them all and start communicating with them right away without any kind of configuration, not even SLAAC or DHCPv6 needed.

This really needs to be an EU-wide thing, and a lot sooner.

Two years till it becomes illegal to offer something on IPv4 for the general public and not offer it on IPv6, two more years and no ISP may route IPv4.

Also no ISP NAT bullshit. A default enabled firewall refusing incoming connections is fine, but the internet should be a network of machines that can talk to each other, and for that to happen it must be possible for owners to accept incoming connections, even if it is for nothing more than remote access to their PCs.

> Two years till it becomes illegal to offer something on IPv4 for the general public and not offer it on IPv6

Why? Is there any pressing need for ipv6 only connectivity that you'd make ipv4 only illegal?

Because this of course:

> the internet should be a network of machines that can talk to each other, and for that to happen it must be possible for owners to accept incoming connections

The importance of this is quite obvious if you’re politicised enough. Stuff like Free Speech.

From the perspective of the US that makes sense. It's legal to say practically everything but hostings will kick you out if they don't like you.

But in the EU speech is restricted and hostings won't kick you out unless you say something illegal... and at that point you'll be in trouble hosting stuff using your home connection.

Its not just that - if we want to be competitive then it should be possible for a hacker to offer a new type of idea and let the world try it out - perhaps a decentralized web, or planet scale IPFS, or something that yet only exists in the head of some 17 year old nerd.

And while Europe is more restricted than the US, it is not like we are the Soviet union.

I agree completely, but bigger companies are going to lobby against that. They’ll even give reasonable sounding reasons, such as switching costs or user safety.

Their real reason though will probably be that the truly peer-to-peer networks enabled by a world free of NAT and symmetric bandwidth would undercut their precious market.

Finally, I’m not sure our governments would like the rise of Anarchist networks where speech is so free they can’t even control it. See all the attempts to criminalise or put limits to encryption. Such things would never happen under democracy, but the representative governments we live under are a little different. (Historically, representative government was conceived in explicit opposition to democracy, and democracy lost.)

In the Netherlands all government services must comply to the rules of internet.nl, which, among others, requires IPv6 connectivity.

But for some things you are dependent on others, for instance, the colo not having IPv6. (and in th case of Internet.nl: IPv6 for email is still opt-in on request with Office 365, DANE is not supported yet, etc)

It's mostly African and Asian countries with (very) low adoptions, and this translates to "screw all the countries too poor to adopt IPv6, and let's reduce their chances in the global economy even more". I'm putting it rather sharp here and I have no doubt that's not what your intent is, but that's absolutely an effect of forbidding IPv4.

There is an actual market for buying IPv4s, meanwhile you can get millions of IPv6 addresses for free. This means that connecting the next billion will be much cheaper if they don't have to compete with companies with far more money.

So no, it does not mean screwing over the poor.

This is irrelevant. The infrastructure does not exist. Creating this infrastructure within two years would be a huge task (and who will pay for it?)

I wonder how this will go?

8 years is plenty of time to make the transition even for a government, right?

For governments maybe, but for banks? They're still desperately trying to transition to IBM databases that were deprecated slightly more recently than their current one.

They only have to transition their external communications, they can keep their 90's DB2 databases that cost millions/(MB*year) just fine.

Probably easier to start a new bank.

Eight years is forever, we can wait.

Five years is a long time, let’s work on other things.

Three years isn’t terribly soon, it’ll probably be fine.

Two years is getting close, let’s consider checking.

One year is too close, let’s ask for an extension.

I would name that poem “The Ballad of REAL ID”

Strangely enough, though, it seems to be working in everyone's favor in this case.

Eight years is forever, we can wait.

I've heard that under 10 years is the optimal for a long term government project. Anything longer, and it's equal to "forever," and it's never done. This was the rationale for setting the goal of landing on the Moon to within the decade.

Which is why this time US government for example is only allowing extensions to government agencies on case by case basis, but not to vendors.

AFAIK they allowed extensions for vendors in 1990 and that's why original EOL date for IPv4 continuously slipped until success by Network Translation and its PIX devices helped kill the attempt completely.

The "ancient" code probably already speaks IPv6 due to whatever method used to hook IP connectivity to its VTAM interfaces. Or due to its age it has multiprotocol support anyway.

It's the BSD Sockets using code that is a problem - the OSes has supported v6 for a long time now.

Actually routing IPv6 is usually possible with existing equipment, once you figure out all the settings (and potentially avoid the bugs). What usually ends up being the issue is some side piece of software that isn’t ready to log IPv6 addresses or assumptions made about how long they’ll be in some database somewhere, etc.

I’ve seen hacks around that, like hashing IPv6 addresses down to 4 bytes so you can store them as fake IPv4 addresses :O

Yeah, it's just that it took time to implement, especially since IPv4 ossification (at the time when it was explicitly in works to be removed!) happened partially through introduction of hardware-assisted switching.

But we have had fast path switching for IPv6 for I think 20 years now, and it's generally available. Hell, some big networks, the kind where having fast path switching, moved fully over to v6 and simply do not transit v4 (Deutsche Telekom, for example, whose skeleton network is now "flat" IPv6 network and any v4 traffic is encapsulated to 464xlated

[dupe]

More last week: https://news.ycombinator.com/item?id=39060187

Good move.

No more GitHub?

I wish the US had balls like that.

US DOD started transitioning to IPv6-only in 2021. I wonder how it's going so far. https://media.defense.gov/2021/Jul/13/2002761414/-1/-1/0/DOD...

I predict they'll be just about done by the time 2038 rolls around.

US gov has been actively pushing for IPv6. You can question the efficacy of their efforts, but the intent is there. Of course I suspect there is lot more inertia of all sorts in US gov compared to CZ, just due size and history.

Read for example https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0... (does anyone have more recent ref?)

who will check the IP addresses?

I personally don't think making a very large amount of devices completely obsolete is the best thing, from an environmental standpoint.

Call me a dumb hippie.

Pass laws requiring long term hardware support and open source code for unsupported devices.

... and unlimited flash space for forever upgrades!

... and unlimited flash space for accepting larger and larger upgrades, forever!

If it's open source I'll delete 90% of the manufacturer provided telemetry/tracking/anti-features and use 1/20th of that free space to add the feature I want.

One response to EU recycling mandates is to just pull out of those markets. Some website operators just block the EU as it's easier than complying with privacy regulations. When new regulations per the USA's Americans with Disabilities Act mandated captions, a few MOOCs just yanked their videos.

Which devices don't support IPv6 at this point?

Smart sprinklers. Industrial equipment. CCTVs.

Do those access the Czech government website?

I was speaking to sun setting IPv4 in general.

That said, I have to imagine that there probably are plenty of those devices that do access Czech internal services at least.

IPv4 will be around for a long time. Nobody will care if it is running on internal network. Or quadruple NATed. There are enough IPv4 addresses for sites to have them. But not enough for every user.

> I was speaking to sun setting IPv4 in general.

It's 2024 and Fidonet still works.

Nobody's sunsetting IPv4. It will fade into obscurity on its own as IPv6 adoption increases and IPv4 addresses become increasingly hard to get, as it should.

police knock on the door

“DAD, YOUR SPRINKLERS ARE HACKING THE RECYCLING COLLECTION TIMETABLES AGAIN”

(spend enough time around places like this, though, and one could easily imagine this being a thing in 2032)

As an aside, I notice a lot of the recent commits to the ESP32 repo are for ipv6 fixes. It already works in the tasmota esp32 builds on devices at my place.

This said, by then, maybe the core OS will not be metal, but Linux on all these device and we'll get top ipv6 support.

More likely, in 2032, well have a bunch of crap, built from very old SOCs running Linux 2.4.

Sounds like their creators have some work to do

Sounds like IPv6-as-botnet-DDoS-prevention is a viable strategy! Can't get DDoS'd by the unmaintained crap if said crap doesn't even speak the required protocol!

Are you sure you want any of those on a public network anyway? If they're not firewalled right now then you're already in trouble.

Also, it is eight years in the future. What future devices won't support IPv6?

This is also about the Czech government sites removing IPv4 support. What devices that would be used to access site won't support IPv6? They all do today.

Plenty. Including the ones that should know better. E.g. esphome is still working on IPv6 support ( https://github.com/esphome/feature-requests/issues/718 ).

Then there's a veritable black hole of various crappy security cameras, IP phones, and WiFi printers. And they can live for a veeeeery long time.

And I don't think I've ever seen a hotel network with IPv6 support. And I've actually seen a hotel (in Palo Alto) that gives out real IPv4 addresses to clients.

Those devices won't necessarily be made obsolete, there are solutions for proxying ipv4 -> ipv6 and I think we'll see many consumer routers enabling those features by default for devices that do not support ipv6.

IPv6 support existed in even Windows XP, if not older. Things without IPv6 support are already obsolete.

A bunch of IoT hardware and other microcontroller-based hardware has IPv6 support, but that support is often disabled to save a couple of kilobytes of flash memory. You can buy all kinds of hardware today that lacks IPv6 support.

Of course, if that hardware needs to access IPv6 services, they might as well disable IPv4+ICMP+DHCPv4 support and enable the IPv6 size in firmware, and probably get similar savings.

To be honest, I'm not sure why companies still ship ESP32-like hardware with that little storage given how cheap flash storage is, but these optimisations are more common than one might think or hope.

That is basically planned obsolescence. The world (except a few regions) is essentially out of IPv4 addresses.

There are plenty of IPv4 addresses for server use, and IPv4 in client networks is easily accomplished using whatever form of NAT you prefer. DNS64+NAT64 will work fine for IoT crap (not like your thermostat is validating DNSSEC), and a whole bunch of ISPs rely on DS-Lite+CGNAT to allow IPv4 connectivity over their essentially IPv6-only backbone already.

Publicly reachable IPv4 on the consumer side is dying rapidly, but IPv4 LANs and servers can still work exactly because of the versatility IPv6 allows.

As it has been since 2011, and yet here we are.

> A bunch of IoT hardware and other microcontroller-based hardware has IPv6 support, but that support is often disabled to save a couple of kilobytes of flash memory.

Wait a minute, kilobytes? That much? It’s not like one needs to duplicate the entire IP layer, it seems to me the only changing parts are parsing & generating the packets.

For IPv6 you need to implement NDP, RA, and a bunch of changes to the DHCP server. You also need to start paying attention to ICMP.

The documentation for ESP-IDF (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...) says:

> Disabling CONFIG_LWIP_IPV6 can save about 39 KB for firmware size and 2 KB RAM when the system is powered up and 7 KB RAM when the TCP/IP stack is running. If there is no requirement for supporting IPV6, it can be disabled to save flash and RAM footprint.

> Disabling CONFIG_LWIP_IPV4 can save about 26 KB of firmware size and 600 B RAM on power up and 6 KB RAM when the TCP/IP stack is running. If the local network supports IPv6-only configuration, IPv4 can be disabled to save flash and RAM footprint.

IPv6 takes up more ROM than IPv4, and as far as I know ESP-IDF doesn't actually fully support IPv6 either.

At this point we're talking microcents of storage, but unfortunately the 13KB of size difference can make the difference between "the code fits" and "we need to spend a dollar more per unit".

My it really is kilobytes. Okay I guess my next project will be a TCP-IP stack on an 32-bit RISC-V micro-controller, we’ll see how much code this actually requires. My understanding of IP may be off, but I still feel those numbers are about an order of magnitude bigger than they actually need to be.

I mean, I can fit an entire cryptographic library¹ in 65Kib of RV32IC object code, and it’s not even particularly optimised for this use case. There’s no way the overhead of supporting IPv6 has to be that big.

[1]: https://monocypher.org

I think the individual parts will not be that large, but ESP-IDF is a fully features RTOS, not a dedicated microcontroller library. It provides socket APIs that integrate with both WiFi and ethernet, for instance.

If you're optimising for size, I bet you can do a lot better, but that's not really what ESP-IDF is doing. It's providing a network stack for TCP+UDP+IP+DHCP+ICMP+NDP+ARP+DNS with (close to) standard C APIs.

Microcontroller developers can probably download and use smaller libraries if they wanted to, but ESP-IDF provides a rather comfortable development experience compared to stringing together a whole bunch of libraries and talking to the hardware directly.

Still, doing a lot of things is not an excuse for the individual components to be bigger. Not unless you can justify it with interaction between components, stuff like TCP and UDP being aware of what goes on in the IP stack below and having to special case v4 and v6 (made up example, I don’t know if that’s true).

And now I’m wondering how much it would take to implement a full network stack with a nice C API.

IPv6 has been supported for ~20 years. Not many devices in any regular use these days with network support, lack IPv6. That pool of devices will be almost entirely gone in 8 years when this is due.

I think we simply have different definitions of "devices".

I'm not talking about just phones, tablets, and laptops.

I'm ignorant on these things, so please inform me - but given IPv6's awful adoption rate, and given how foreign it's numbering scheme is to many, why can't we introduce IPv7 and just extend the IPv4 scheme with additional octets?

Something like 0.0.0.0.0.0.0 and everything without the correct number of octets just gets filled with zeros. So 192.168.0.1 becomes 0.0.0.0.192.168.0.1. Then also don't give out /8's to universities and the like (repeating old mistakes).

This is probably naive, but it seems it would be easier for people to use vs. 2661:919a:023e:911a:44dc:f656:233e:8816

Because the problem is not the numeric representation. The problem is when you get a message from 1.0.0.0.1.1.1.1 to 0.0.0.0.192.168.0.1, and 192.168.0.1 is an IPv4 only device, what are you going to tell 192.168.0.1 about the source address? There's only a 32 bit field in the protocol.

Are you going to lie and tell it it's 1.1.1.1? Congrats, you've just reinvented NAT. Enjoy your stateful boundary system and all that complexity again.

Are you going to add some extension to IPv4 and try convince everyone to upgrade all their hardware, software and configurations? Then you have the exact same problem IPv6 adoption had, except IPv6 adoption is at like 45% globally and your new scheme is at 0%: https://www.google.com/intl/en/ipv6/statistics.html

If you have some other idea, make sure to check it against the list of IPv6 transition mechanisms before commenting - it probably exists for IPv6, and ultimately all of them have been displaced by dual stacking: https://en.wikipedia.org/wiki/IPv6_transition_mechanism

> There's only a 32 bit field in the protocol

IPv6 is 128 bits... so we already made a change. Why can IPv7 not be 128 bits as well, but vastly more readable/recognizable than IPv6. Hex is hard on the eyes, especially for those who don't stare at it all day.

> Hex is hard on the eyes

Thankfully there is near-100% compliance with PTR reverse-dns for IPv6 addresses and networks. /s

The move to hex is to avoid people having to memorise all these offhands like "so a /27 is x.x.x.0-31". Instead every "4" in the subnet is another digit.

But also do you think 24414.64517.21200.44298.46574.49887.23623.7394 is really that much easier to type? Or 231.22.96.68.14.229.38.41.242.44.72.220.156.50.232.95 if you keep to 8 bit octets?

Maybe I'm weird, but I do in fact think that is easier. People memorize long numbers all the time, such as SSN, phone numbers, account numbers, credit card numbers, etc. People are not very good at memorizing lengthy alphanumeric sequences such as randomized passwords. I don't know why, but it "just is".

But -

> The move to hex is to avoid people having to memorise all these offhands

Point taken. It does seem in practice though people will still have a need to memorize/recognize addresses for various purposes, such as administration/dns/etc.

> People memorize long numbers all the time, such as SSN, phone numbers, account numbers, credit card numbers, etc. People are not very good at memorizing lengthy alphanumeric sequences such as randomized passwords.

It's easy. Long sequence of 10 possible tokens that we're always used to seeing together. Easier to memorize because you subconsciously use any patterns you notice, and with just 10 possibilities the patterns are there. And you've been reading sequences of digits since you were old enough to get given pocket money.

Vs long sequence of 16 possible tokens, of which 10 belong in one cognitive group and 6 in another. The extra 6 you've never memorized before in random order because they're for representing your language and that has other ingrained patterns.

Let's not forget they admitted ipv6 addresses are too long and allow you to skip parts of it so now you have to count the colons carefully...

You don't understand why a sequence of 39 digits might be harder to memorise than sequences of 10? 16 is longest of the examples that people actually memorise (no, people are not memorising their bitlocker keys), and even then they have 1 example that lasts at least 5 years to deal with, instead of however many IP addresses they have to deal with.

Also many of my account numbers and my nations equivalent of a SSN are alphanumeric so 36 vs 16 choices.

I could be wrong, but I do not think it's easier to remember 45465465464938259 then it is to remember the lyrics to a popular song. Now I assume there is some sort of brain difference playing here. But while looking it up most popular memorization strategies are either ram it into your head with repetition or converting it to songs, rhymes, poems, or other word phrases.

It's quite easy to remember things like "Mmm-mmm, went the little green frog one day".

Speaking of which, the slash notation has not gone away in IPv6 notation.

At least the user networks are /64s, so, to some degree, CIDR notation isn't relevant for someone just trying to set up their system - netmask is now always 64 bits. And sure, ISP/Network Engineers still care about /56, /48, /32, etc... but that's their day, and takes about a week to have it ingrained in a way that you almost never could with IPv4.

> But also do you think is 24414.64517.21200.44298.46574.49887.23623.7394 is really that much easier to type? Or 231.22.96.68.14.229.38.41.242.44.72.220.156.50.232.95 if you keep to 8 bit octets?

I mean... yes, actually; I can type those blindly on a normal numpad. I'm sure somebody somewhere has made a hex number pad, but realistically on any normal keyboard entering hex means going back and forth between number and letter keys.

On QWERTY layouts, you can type ABCDEF with your left hand and 0123456789 with your right hand on the num pad.

That would be really convenient if : weren't in the middle of the keyboard. Maybe hardcore IP typists need an alternate keyboard layout where * maps to :

Microsoft did. The first example is pretty much what bitlocker recovery keys are.

Because 99.99% of people never see an IP address let alone interact with them.

If you'd like to figure out a nicer representation for IPv6 addresses, go for it. You needn't break any compatibility for it, just invent a new representation.

I'd argue that the most common format such as 2001:db8::f00f is already pretty darn readable, and not hard to copy+paste when you need bare addresses. Base85 is an alternative if you'd like something that's purely optimized for fewer characters, but it only really helps with exceptionally long addresses like 2001:db8:424b:b4ff:fcb5:b643:f721:b703 becoming 9R}vSk6QzV!G$<lwB;|~

> 2001:db8:424b:b4ff:fcb5:b643:f721:b703 becoming 9R}vSk6QzV!G$<lwB;|~

Memorize that :) Then try to tell it over the phone.

That's a totally contrived address just to get as long of a hex representation as possible, it's pretty far from a likely situation.

That being said, telling an address over the phone (another unlikely situation, to be honest) wouldn't be that hard in hexadecimal form.

> it's pretty far from a likely situation.

I don't know, I just checked my linux box that takes ipv6 from one of my routers and it's the full 16 bytes, no zeros to skip.

I suppose example.com has a lot of consecutive zeros and is shorter to type...

> (another unlikely situation, to be honest)

Kid calls you when you're out and asks where in your local network the minecraft server is running. Or on which samba server the mod archives are. Real story.

You're more than welcome to represent an IPv6 address in some other format. That's just a implementation detail in the UI. You don't need a new wire protocol to do that.

(There's already at least 4 different ways you can write an IPv4 address, and your OS is happy to accept any of them.)

You gotta love how they decided to use colons as part of the notation! But, oops, that is also used for port number notations. Solution? Square brackets:

  [ff00:abcd::0]:1234

Yeah it's annoying, I've come across numerous address parsing bugs because of this.

I think the reason they needed to use a different delimiter is because IPv6 addresses can also omit entire portions of zeros as a convenience feature to shorten addresses, which means there are a subset of shortened addresses that look exactly like IPv4 if not for the delimiter.

> I've come across numerous address parsing bugs because of this.

To prevent that, you can write tons of test cases. IPv6 notation parsing and generating test cases are oodles of fun.

I think two major problems that IPv6 failed to account for are the unreasonable ambiguity and "global registry" proposed by the Unique Local Address range, e.g. fc00::/7. This was even after having the opportunity to fix the previous mistakes in the fec0::/10 range.

It was entirely inappropriate for small scale personal networking and assumed an "administrative scope" that's too cumbersome and without purpose for most implementations.

I wonder if a dedicated "local" network prefix with a fixed /64 mask and an operating system recognized "alias" would have been a good mechanism to introduce. Something like fec0::/64 with an option to call it "local::". Then you might be able to more easily move from a world of 192.168.10.1, 192.168.10.2 to a world of local::1, local::2, that being translated to fec0::1 and fec0::2.

What do you mean by global registry? ULAs do have a local bit, by setting it to 1 (i.e., fd00::/8) you can have your own ULA range. I am using ULA in my own home network.

Right, and the local bit being 0 is currently undefined, but the original and lasting idea (apparently) is to create a central registry for it, so that in some future case where you have to merge corporate networks with their own ULAs there is zero chance that there would ever be a collision between the two.

Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above.

In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained.

It's been a mess, and at some point, the IETF just seems to have given up on it.

> Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above.

Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work.

There is no need for a ULA registry because you're supposed to pick a random prefix within the ULA space. The ULA space has 7 bits already defined, so you're picking a random prefix from a space 57 bits big. The chance that you will pick the same prefix as some other specific person is effectively zero.

(the birthday paradox does not apply because we don't care if your prefix matches anyone else on earth, just the one specific person/organization that you want to merge networks with).

> In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained.

Err, what? ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global. They are valid addresses within the address space and the only thing that makes them "not globally routable" is that all routers have certain prefixes baked into the firmware as non-routable. If you don't trust your router not to route them for IPv6, why do you trust it for IPv4?

> Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work.

Thanks for explaining my own motivations to me, while at the same time denying that any discussed changes are relevant to anyone.

> There is no need for a ULA registry

I was merely summarizing what the public opinion on the matter happens to currently be. Which suggests that the current recommendation to pick a random address and be happy with it is inadequate. The original posts dissatisfaction with being able to deploy IPv6 _conveniently_ also hints that improvements would be welcome by most people.

> ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global.

RFC1918 explicitly defines it's addresses as local and not globally unique. RFC4193 specifies that these addresses are meant to be globally unique. RFC1918 requires a more specific level of filtering than RFC4193, and the definition of "site local" has always had some ambiguity to it.

So, within the very specific and nuanced points I was trying to make, no, they're different.

Agree with the parent that there is no need for a ULA registry for locally assigned addresses under RFC 4193 (which is every one I've ever seen). But there is that option for globally assigning addresses that I'd be intrigued to see if anyone does anything with...

Also important to note that while RFC1918 is roughly equal to RFC4193/ULA, that "site local" is another beast entirely (FECO ) that was, as you noted, ambiguous and was deprecated in rfc3879

Well -that's not entirely true. RFC4193/ULA has a Local Bit that, in my experience, is almost set to 1, so the prefix is FDxx.... At a prior company we rolled out about 25 million nodes all in RFC4193 space (non-routability was a design objective) - and, just to be within spec, we did indeed grab a random /48 for each customer instance we rolled out (and made very good use of the 65K networks we had available within that /48).

But - what if that Local bit is set to 0 - then:

   Set to 1 if the prefix is locally assigned.
   Set to 0 may be defined in the future.

Presumably there was some thought that there might be a Global Registry that the OP was referring to?

Concur with the rest- and, honestly, RFC 4193 is one of the simply written RFCs out there - understandable within 30 minute read - I'd encourage everyone to dig into it.

> those are still _global_ addresses

They are meant to be globally _unique_ (or effectively so, by utilizing RNG you ensure that it is very, very unlikely for two organizations to have the same ULA), but they are not globally routable.

> IPv6 adoption is at like 45% globally [...] https://www.google.com/intl/en/ipv6/statistics.html

> link -> The graph shows the percentage of users that access Google over IPv6

How does this work in practice, does user equipment end up with dual IPv4 IPv6? if not how do they access IPv4 only sites (of which there are still plenty)?

The way it's supposed to work is the ISP delegates a prefix to the user's router, the router will advertise for that subnet and client devices will use slaac to configure their ipv6 addresses. Meanwhile for IPv4 it operates as normal. For incumbent, mostly wired, Western ISPs that means a pool of IPv4 addresses and subscriber level NAT. For everyone else, that probably means CGNAT.

It's just as you have described, this is called dual stacking and is currently the most common type of IPv6 deployment.

Alternatively, cellular ISPs may make use of NAT64+DNS64. In this case, the IPv4 addresses are combined with a NAT64 prefix (most likely 64:ff9b::/96), producing addresses such as `64:ff9b::198.51.100.1`. It is effectively the same as CGNAT, but pretty much everything is single stacked IPv6 up to the IPv4<->IPv6 border relay in the ISP network.

My ISP gives me both an IPv4 address and a heap of IPv6, most browsers will use what is called Happy Eyeballs to try both IPv4 and IPv6 at the same time and use the one that connects the fastest.

Are you going to lie and tell it it's 1.1.1.1? Congrats, you've just reinvented NAT. Enjoy your stateful boundary system and all that complexity again.

(Shrug) It works. What problem is being solved here, again?

The funding of the ipv6 commitee probably.

And porn for those who like overcomplicated 'enterprisey' solutions where they aren't needed.

Just look at your favourite game console provider's forum discussions on "NAT types" and you'll see that it really doesn't. Or try self host on CGNAT. Or realise the only direction for IPv4 prices at AWS etc. is up

> Are you going to add some extension to IPv4 and try convince everyone to upgrade all their hardware, software and configurations? Then you have the exact same problem IPv6 adoption had

Yeah, so I'm going to say that's just not true. If IPv6 had been significantly simpler (e.g. by mainly focusing on increasing the address space) then adoption would be much higher today – probably universal. The problem is that IPv6 changes a lot, and that implementing it is a fair amount of work. The entire business with tunnel brokers and other compatibility schemes are complex and difficult to use.

To completely change gears now would be silly and too late, but it's been almost 30 years and it baffles me how anyone does not consider the entire thing a spectacular failure. People use Python 3 as a warning about compatibility, but IPv6 is a much larger catastrofuck, and that's largely due to decisions IPv6 people made. Whether IPv6 is "better" or not doesn't even come in to play.

This comes up every time IPv6 is discussed.

Any change to IPv4 to extend the IP space (eg your example) would require a breaking change to the specification. So this would require changing every router on the planet to support it.

You're also focusing on how the IP address is written when that doesn't really matter. Changing the format isn't dragging out IP adoption.

Changing the IP protocol to support more stuff has been considered... that's how we got IPv6 in the first place.

Awful adoption rate? https://www.google.com/intl/en/ipv6/statistics.html

It's sitting just shy of 45%, based on what Google sees, and growing at a steady pace. The main issue is not technical, it's need. Right now, everything is accessible over IPv4, and probably over IPv6. There's no negative consequences from not having IPv4, it really needs initiatives like this one, and the US federal government one to drive things forwards (US federal agencies have to be single-stack IPv6 within a couple of years, which is forcing every government dealing vendor to get their act together on IPv6)

A couple months ago I got a new router and some stuff didn’t work until I turned off ipv6 (I don’t recall what, exactly)

I tried that solution early because when I first got Google Fiber the Amazon store website didn’t load, on any machine in our house, until I turned off ipv6. If stuff tries to route over ipv6, it doesn’t work, has been my entire experience with the protocol on the open internet (private networks seem Ok)

Next time try: https://test-ipv6.com/

If you get 10/10 here everything should work. Most likely your issue was a firewall rule on the IPv6 part, or a misconfigured DNS server (only returning A records)

My home connection fails because it’s disabled (of course).

Kicked my phone over to my T-Mobile cell connection. Finds that I have an ipv6 address, but dies on one of the first tests.

It’s 2024 and I have two major US ISPs available and neither will let me reliably use IPv6 unless I’m on a vpn and the addresses are all private ones that don’t (logically) route to the Internet.

> IPv6's awful adoption rate

https://www.google.com/intl/en/ipv6/statistics.html ~50% worldwide with lots of countries way over that is not what I'd call awful.

> introduce IPv7 and just extend the IPv4 scheme?

Every proposal like that requires changing all the routing hardware anyway, because we effectively ran out of bits in the IP packets to mark anything new. And once you need to change hardware, you may as well just go with a better designed protocol like ipv6.

> This is probably naive, but it seems it would be easier for people to use vs. ...

People don't use IP addresses anymore. DNS and local discovery covers this for anyone apart from geeks and IT people. If it doesn't, it's a bug at this point.

> https://www.google.com/intl/en/ipv6/statistics.html ~50% worldwide with lots of countries way over that is not what I'd call awful.

IPv6 was drafted in 1998, and ratified in 2017. 7 years after becoming "official" only 50% adoption rate world-wide is not what I would call stellar either.

Also, looking at that chart it's closer to 40%...

Industry doesn't adopt a thing until there is a need for it. In 1998, there really wasn't a need for it. Now there is. So now it gets adopted. News at 11.

Also, it's worth to keep in mind the delay on the hardware replacement. There were home routers which didn't support ipv6 even 7 years ago. And there many home routers deployed today which are over 7 years old.

Also, my provider fully supports IPv6 and so does my hardware, but I have to click a button in the control panel to activate it explicitly. That's practically around a million of people who could be on IPv6 right now if they just opted in.

I’ve noticed that the Ubiquiti UDM Pro router has IPv6 turned off by default; and I don’t really want to change the defaults, because idk, maybe something will subtly break, and in any case it works fine as-is…

It looks like it's going to be a few years until not enabling it will start subtly breaking things. ;) It's a trivial change to reverse, so if you're interested, give it a go.

Yeah, but I’m hoping that by that time, Ubiquiti will have done the work for me in an update ;)

People rely on that network every day, and I’m not on-site very often, so I’m really not keen to try any unnecessary configuration changes…

Honestly... 50% in 7 years is an impressive achievement, and far from being awful. People often compare IPv6 adoption to things such as HTTPS adoption, but upgrading to IPv6 requires hardware changes on both the ISP side and the customer side, and as we all know, hardware upgrades take forever. It's not unusual to see >10yo equipment running in the wild.

Also even for HTTPS adoption - it was introduced in 1994, and in 2010 even major websites like google and facebook were basically only bothering to secure their login page which is how Firesheep came to be. It was only really that illustration of the business need that caused anyone to start bothering, and despite that demonstration, adoption was below 50% as late as 2018

Also, lots of places and software are "stuck" at HTTP/1.1 when HTTP/2 and 3 are already out. Why are they stuck at something that came out in 1997?

Presumably it would be far easier to upgrade/replace your webserver, loadbalancers and clients than replacing all routers on your ISPs.

It's kind of a misunderstanding to say that IPv6 became official in 2017.

The IETF has multiple standardization levels, with Proposed Standard being the first and Internet Standard being the last (there used to be Draft Standard in between but it was eliminated). Proposed Standards are deemed ready for deployment and lots of important protocols (e.g., TLS, QUIC, etc.) are at Proposed Standard. IPv6 went to PS in 1998, and people have been trying to deploy it ever since, so it's really more like 25+ years since it was official.

In my country, rare are the ISPs which don't provide IPv6 (it has been the case for years, and that includes mobile internet).

I think the lagging services about ipv6 are steam, github, HN, and a few smtp servers here and there.

I think that Reddit and AWS are mostly non-ipv6 yet as well, that's a pretty big deal.

Oh, I don't use reddit, but AWS... mmmmh... and that makes me think about akamai.

It seems ipv6 is slowed down by big tech, the one with the bucks to move to ipv6, paradox, or they know IPv4 mechanically favor strongley centralized services? As it is toxic to clean and simple p2p protocols?

mmmmmh....

>IPv6's awful adoption rate

40+% adoption rate since the World IPv6 Launch Day in 2012 is not what I would call awful [0].

>extend the IPv4 scheme with additional octets?

To clarify, IPv6 and IPv4 addresses are effectively just a number. On Linux, you can even do `ping 16843009` and see the tool actually pinging the address 1.1.1.1! The octets you see in typical IPv4 addresses, or the hextets in IPv6 ones, are just a way to represent those addresses.

If you think the address representation is the main thing holding IPv6 back, you are thinking it wrong. The most likely reason is actually software & hardware support, and the industry's general sentiment of "if it ain't broken, don't fix it" keeping NATs alive.

>seems it would be easier for people to use

The ship has already sailed. If IPv4 addresses are really that easy to remember, DNS would not have been invented.

Furthermore, when it comes to memorization of IPv6 addresses it's very helpful to split them into two halves. The second half can change rather arbitrarily (to maintain privacy by preventing address tracking), but the first half often won't because it is assigned to you by the ISP.

[0]: https://www.google.com/intl/en/ipv6/statistics.html

If you mostly dislike the long addresses, you can cut out the second half. You can make your device be 2661:919a:023e:9100::1.

If you want a near-exact equivalent of 192.168.0.1, then you can use fec0::1 or fd00::1. That's even shorter than IPv4! You kind of shouldn't, but it'll work fine for a tiny network.

But as other people have explained, the compatibility will be just as bad. And IPv6 does have address ranges like that. Nobody talks about them because not much can be done with them.

And the reason it's recommended against is that you might later decide to join your local network to another one and then you'll have to renumber them. Which is exactly the same problem with IPv4 local addresses. Except unlike IPv4, there is a mechanism to prevent that ahead of time

Which is absolutely important once you're a business with a bunch of subnets, the kind of network that would be on 10. in IPv4.

If you're on 192.168 and you just want the convenient addresses, go for it.

If you're typing out IP addresses your doing it wrong. We've had DNS for checks watch 40 years.

IPv6 isn't THAT different from IPv4. It's a 128 bit number instead of a 32 bit number. When righting it out we use hex (because it's shorter).

We use multicast instead of broadcast so your Subnets can be bigger

The smallest subnet is /64 so vendors can do optimization hardware.

Routers announce the prefix they route (and a DNS server) and let endpoints autoconfigure(with built in IP conflict detection!). Instead of a stateful DHCP server(which is still an option).

And we let nodes have local and global addresses so issues with the router don't necessarily break local communication. (And they're easy to tell apart, if starts with an f it's a local adress, if it starts with 2 it's a global address)

That's pretty much all that's different. 80% of what's different is the address space.

Having done basic tech support, sometimes typing out addresses is necessary. You'd think mDNS would help computers find your modem when you're first setting up your internet connection, but the super "helpful" modern browsers all try to go to google.com/search?q=myrouter.localnet even if mDNS is providing various IP addresses to try first.

That's not IPv6's fault, but it is a pain. Especially considering that local networks differ from router to router, making it impossible to write a manual to access a router's settings for when the thing needs to be configured before it can connect to the internet.

Of course, in those cases there's nothing preventing manufacturers from providing some 192.168/16 IPv4 addresses for those specific use cases (and not route them to the internet). I've even seen one manufacturer listen on a bunch of 169.254/16 addresses for when DHCP fails somehow, and I think that'd solve the problem perfectly without even needing a DHCPv4 server.

169.254 is IPv4 link local range like IPv6 fe80

Windows will try to auto configure with a 169.254 link local if DHCP is unavailable. Not sure if anyone is actually using them for LAN. They come up sometimes in point to point or for other shenanigans (commonly on cloud or virtualized networks for special services)

Afaik for Firefox and Chrome you can add a trailing / to prevent it from doing a web search and attempt to do a DNS lookup instead

>Windows will try to auto configure with a 169.254 link local if DHCP is unavailable. Not sure if anyone is actually using them for LAN. They come up sometimes in point to point or for other shenanigans (commonly on cloud or virtualized networks for special services)

I've seen it done few times for niche devices and I've done it a few times when I needed a really quick network operational and didn't want to bother setting up any supporting infrastructure such as a DHCP server. Never for any production environment though.

I've toyed around with an IPv6 link local only environment but browsers don't support adding the zone identifier[1] for link local addresses. There's workarounds but in most cases for a fully isolated network it's about the same effort to setup a small DHCP server somewhere.

That said it's not a comprehensive solution, Android AFAIK still won't support DHCPv6. To get that to work AFAIK requires router advertisements and some more odd finagling if privacy extensions are enabled on the device.

[1]https://ungleich.ch/u/blog/ipv6-link-local-support-in-browse...

I sure hope nobody is using 169.254 for LAN (though I suppose you could, just like you could use 100.100) but I discovered it as a pretty smart fallback for routers. I suppose you could hardcode http://[fe80::1]/ on the IPv6 side as well, but I've never seen a router actually do that.

The trailing slash trick sometimes worked, but not always. It took a couple of tries to get working every time I needed it to work. I bet it's some kind of problem on the mDNS layer, but regardless, the quickest way to fix it was to use an IP address.

Another annoyance I have (which isn't the protocol's fault) is that on my phone I can't even hand-type IPv6 addresses because Mozilla is using some kind of regex to detect if things are URLs and that regex doesn't support IPv6. It did for a short while, but the IPv6 regex was too complex and slowed things down, so that was reverted.

Because that would be starting from scratch the migration with all the warts and less of the benefits.

About the only part that would be easier is that more people use less broken APIs compared to BSD Sockets, with getaddrinfo and similar solutions ported from XTI/Plan9 finally becoming the norm.

So no more "you need to duplicate code to add support for new IP version".

But that's still worse than migrating to v6, which has widespread hardware support in switching equipment, considerable preference in mobile networks and not only (TL;Dr it's cheaper to use v6 to carry v4 traffic using 464 stateless translation rather than other forms of CGNAT), and some IOT systems (industrial, not home stuff) are v6-only if they have IP connectivity on the embedded side at all.

I cant imagine how much "fun" its going to be trying to lock down a governments systems when every single device on their network is potentially reachable directly from China...

This feels like FUD. You can still assign a block of ipv6 as internal to your network and put it behind a bastion. Forcing ipv6 isn’t the same as going zero trust or something where now everything is publicly routable.

and whats stopping an intruder reassigning that block to something that can be publically accessed and how will that be monitored?

Uhhh... Whut?

You obviously need to use a ULA prefix, they are not routed (just like RFC1918 space in IPv4).

Or you can just use your allocated IPv6 space, and firewall at the border. And you hopefully have BGP hijack monitoring set up anyway.

you do know single network devices can have more than one ip address?

afaics, the biggest issue with ipv6 is if its active all devices on a network can easily be coaxed to never route traffic anywhere near the router/firewall the network admistrator intended, simply by handing out extra routing info for alternate networks.

> afaics, the biggest issue with ipv6 is if its active all devices on a network can easily be coaxed to never route traffic anywhere near the router/firewall the network admistrator intended, simply by handing out extra routing info for alternate networks.

This is not unique to IPv6.

ARP spoofing is the v4 version of this attack. RA spoofing is the v6 version of the attack. In both cases, the solution is the same: lock down your L2 by enabling MAC / ARP / RA filtering on your switch.

true, but getting even a single public ipv4 address is hard.

anyone and everyone handing out public ipv6 addresses is by design.

I have 32 IPv4 addresses, how do I utilize them to hack Amazon?

It doesn't matter that you can get IPv6 addresses, you still need to be able to get onto the L2 network of your victim company to be able to mount RA attacks. You also will somehow need to force them to announce your IPv6 space to their peers.

with IPv4 you cant really, because getting traffic routed to those ips is a major undertaking.

with IPv6, every IPv6 capable device is potentially capable of handing out something like the entire IPv4 space of public ip addresses regardless of how a single firewall or router is configured.

"trying to configure connectivity and access resources using only IPv6 addresses is borderline insane"

You clearly don't understand how routing (and the Internet) works. My IPs are useless because I can't force the victim to route to them.

I similarly won't be able to force the victim to route their traffic to IPv6 addresses that I control.

what difference do you think it makes who controls the public ipv6 address.

with ipv6, they got one, all devices on the network are now by default accessible from the public internet instead of invisible to it . Thats the whole point of ipv6.

Reassigning a block sounds a lot harder than the IPv4 version of making something accessible, sending out a single packet to hole punch the NAT.

Having a public IP != publicly reachable. IOW, have the router block incoming connections just like the goreish nature of "NAT" did for you.

having a private ip = definately not publicly reachable.

having a public ip = possibly reachable, depending on what other devices can be compromised on the network.

given the number of government machines already that participate in the various ddns botnets moving to that second one is going to be a lot of fun

at the very least all the cnc servers can move local.

If a device on the network is compromised, how is a private IP going to save you? Private IPs can be reached from within the network.

it doesnt "save you".

but on a private network a compromised device can only make outgoing connections.

public facing devices can be administered by incoming connections, thats a whole other level of complexity, potentially for every device.

set router to an allowlist configuration... and you're done. it's your "NAT" security but without terribleness. some (consumer/smb) routers even come this way out of the box to prevent exactly what you mention

add a software router to the network that hands out public ips to all the devices on the network.

or better, just accidentally switch a cable over from the router to the routers switch, see if anyone notices their private ips all became public ones.

> having a private ip = definately not publicly reachable.

> having a public ip = possibly reachable, depending on what other devices can be compromised on the network.

Lateral movement is hacking 101. Private IPs don't provide any security.

Got a webserver open to the internet and a database server on a private IP only accessible to the web server? Guess how you get to the database server?

got a vulnerable database server and a secure webserver.

guess what happens when the database server gets a public ip.

edit:wrong thread

Nothing because it's behind a firewall?

You seem to be continually conflating something having a public IP address and it being open to the internet raw dogging it. This is not how things work.

good job all the networks cables are glued in and no one ever plugged a cable into the wrong port, or doing so might result in all the devices behind that firewall getting exposed directly to the internet and no one noticing because everything still works.

but Im done burning karma on this one, good luck have fun.

> good job all the networks cables are glued in and no one ever plugged a cable into the wrong port, or doing so might result in all the devices behind that firewall getting exposed directly to the internet and no one noticing because everything still works.

So just put your database server on an IPv6 ULA (which is not globally routable)? There are other benefits to that, too, you know? Like that you can have a completely static address for the server, which is agnostic to whatever IPv6 prefix gets assigned by your upstream provider.

did the unpaid intern do that before or after the insecure database server accidentally got given a public ip address?

did they also check and update that old office use only IIS server no one uses before the department all got public ips, or wasn't there a lunch budget for that.

Good job not even attempting to secure your office switch ports with whitelisted MACs or whatever, then.

And if you then argue that MACs can be spoofed easily, well, you'd have to get the MAC of the authorised system first. And by that time you've physically broken into the building - you have worse problems than a rogue device or two...

if we're branching in to 'what other devices can be compromised' then that's a concern for any network 'private' IP or not. for example, even on a NATted v4 network if you get the right device (say if it's 'port forwarded', or you get malware on it another way (social engineering) you can pivot that way to another point in the network.

you can supply all the ACLs and firewalling to your heart's content on either private or public, it's just that public addresses have a heck of a lot less shitfuckery when you actually want to do useful things across the internet

if by "heck of a lot less shitfuckery" you mean "makes it a lot easier to exfiltrate all the data on a network" I completely agree, that was pretty much my point.

You seem to fail to grasp that it is the statefulness of NAT that provides security, not the private/public IP distinction. The same statefulness can be obtained by using... surprise, surprise, a stateful firewall. :-D

It is helpful to imagine NAT as a stateful firewall with packet modifying capabilities. Because that's what it is.

If your ISP is doing CGNAT, try pinging random 100.64.0.0/10 addresses. Marvel at the number of pongs you can receive. Hell, we even have online threads talking about this, so it can't be just my ISP being incompetent [0].

[0]: https://www.reddit.com/r/networking/comments/1910m9w/discove...

>having a private ip = definately not publicly reachable.

What component of your router prevents a packet with destination IP 192.168.1.2 arriving on the WAN interface from crossing over to the LAN interface and reaching a LAN machine with that IP? Hint: It's the same one that prevents IPv6 packets from making that same crossing.

nothing stops 192.168.1 crossing a wan interface, in fact I and most of the internet rely on being able to do exactly that, the router just needs an appropriate route in its routing table.

Reread the comment carefully.

the wan address of my router is 192.168.1.8 with a gateway of 192.168.1.1

my lan ip address is 10.10.11.10 with a gateway of 10.10.11.1

what do you think I missed?

Firewalls exist.

Better call up cloudflare and tell them no one wants their business now all the network engineers are as competent and equipped to deal with threats as they are.

Cloudflare's main business is being a CDN that can soak hundreds of gbps in bandwidth of DDoS traffic. Nothing to do with competence, though in your other comments you suggested that plugging things into different switch ports would give them new IPs and make things publicly routable so perhaps you're right to keep using Cloudflare.

Cloudflares main day job is blocking malicious incoming packets used for RCE exploits on unpatched servers.

None of which get through a firewall with a `deny` rule.

and how do you enforce using that firewall rule on tens of thousands of devices, each now with several public and private ips and several thousand routes in and out of the network?

A stateful firewall is prerequisite for NAT implementations commonly deployed in most office and consumer settings due to the session tracking requirement. So you just stop doing the NAT part and the firewall continues to deny untracked ingress connections just like it did when NAT was running.

NAT is only needed if you want to transition from a private network to a public one.

ipv6 still needs nat configuring. nothing changes there.

The only thing that changes from a network administrator perspective is it becomes much harder to ensure devices that should only have a private ip address do not have a public one.

https://www.juniper.net/documentation/us/en/software/junos/n...

My very publically available home server (static IPv6 address, AAAA record) is behind two firewalls. The first is the ISP-supplied router. That handles any attempted connection to any address on its /64 subnet.

The second is UFW on the server itself + fail2ban.

The open ports are 22 and 443.

It's basically as secure as it gets apart from not having it public at all. Public IP != open for all connections on all ports...

Reply on news.ycombinator.com