I'd really just rather get IPv6 working everywhere and not have to deal with NAT. Some more addresses just drags out the problem by reducing incentives to switch, it doesn't solve anything, which is roughly where the article seems to land:
> If we are going to start using address space that might not work for all users, it would be wise to pick the address space that we already have a considerable head start on getting accepted: IPv6.
This. It will break a lot of existing applications, devices, firewalls, and have conflicts with companies that are somewhat already using them in a public or private environments. And if we want to do it anyway despite all the trouble, it will only push forward the problem a few months or years.
In the other hand, IPv6 is already used by nearly half of internet, and probably most installed infrastructure supports it. And it have a lot of advantages over IPv4, starting with not having to use NAT.
If IPv6 would be created with a little bit more care for backward compatibility, it could have been years since last server stopped using IPv4. The whole IPv6 fiasco is self inflicted.
Yes, yes, but at this point those mistakes have been litigated sufficiently and complaining about them doesn't help solve any of the remaining problems.
Sure it does. We can just move to ipv8, 5 octlets instead of 4. We can give 2.x.x.x.x to 10. to earth, maybe 100 to 110 for moon, mars, etc.
1.x.x.x.x will be for legacy stuff. If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved.
edit: I realised people don't see the big picture here.
Step 1) We collectively engineer and deploy ipv8, along with RFCs explaining how future expansion works
2) We put all sorts of preparatory work, conversation into the eventual expansion into 6 octlets, from 5. We'll need that once we colonize multiple systems.
3) The RFC will state that "new planetary systems get space on 5th oclet, 1.200.x.x.x.x to 1.250.x.x.x.x.
4) As systems grow to need more than an ipv4 range, we transition them to their own 6th oclet. It's easy for them, because they can retain legacy 5th octlet headers.
5) We then collectively freeze our brains, so that in the future, once interplanetary, faster than light communication exists, we are thawed to deal with the 5 to 6 oclet transition!
And we all become immortal.
But no, that's fine, think small, stay non-immortal with your ipv6 Flanders!
> If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved.
Only for unidirectional UDP.
How do you think the other side would be able to respond if it's unaware of the 5th octlet?
Basically every protocol in existence requires two-way communication and there's no backward compatible way of providing that.
I covered that. Edge routers transition 1.x.x.x.x to x.x.x.x as a default, and x.x.x.x to 1.x.x.x.x. This is an interim change, so that ipv4 can communicate to ipv4 forever. Legacy systems can be supported on ipv4 only, relegating them (just as they are now!) to not having access to that new address space.
The dotted quad notation is just a human readable notation. You can’t just add another octet willy nilly. That’s exactly what ipv6 did. They added an extra 12 octets, but used hex notation (0-F) to shorten the number of characters for human readability.
Internally, an IP is just a 32bit number. Adding another octet is adding another 8bits to the number. IPv6 merely expands that number to a 128bit number.
If you do the math of say converting 8.8.8.8 to 8256^3 + 8256^2 + 8256^1 + 8256^0 and ping the resulting number, it will work.
> The dotted quad notation is just a human readable notation. You can’t just add another octet willy nilly. That’s exactly what ipv6 did. They added an extra 12 octets, but used hex notation (0-F) to shorten the number of characters for human readability.
If that's all IPv6 did that would have been one thing. ipv6 changed tons of things, from arp to nat, dhcp to dns.
Keep the structure and services around IP protocol (DNS, DHCP, NAT), just with more bits for address. Do not try to reinvent the wheel and add unnecessary breaking bell and whistles which nobody asked for.
Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. And I in fact agree with them.
And DHCPv6 isn't needed for logging/audit: the router always has an association of MAC addresses and IPv6 addresses even if hosts assign their own addresses with SLAAC.
> Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android.
Which is absolutely ridiculous. Google should not be trying to dictate to their customers how to run infrastructure. If someone wants to use stateful DHCPv6 for their Android devices, that is their right and Google has no business standing in their way.
And by having a just more bits for the address - be incompatible with IPv4.
DNS is IP^W address protocol agnostic, by the way. If you really need you can run it on IPX/SPX.
DHCP is just a lack of the autoconfiguration in IPv4. No thanks. Nor APIPA, nor DHCP with the same 192.168.0.1/24 everywhere solve that properly like in v6. Sure there were some nuances in the begging (like the inability to provide the DNS servers addresses at the beginning) but they were solved 15 years ago.
Yeah any “solution” to backwards compatibility I have heard involves updating the address scheme. And to get that to work you need to update your networking equipment, software, and start redesigning your network to accommodate the new address scheme and guess what, that’s an IPV6 migration.
If you only had to update the software for a new IP version and a longer address, and maybe even a bit of cleanup in the headers, adoption could have been much quicker.
As it is, virtually everything about networking is different in the IPv6 world. That has significantly complicated adoption for everyone, arguably needlessly. And not everyone who says they support IPv6 even actually supports everything that the designers expect (e.g. lots of ISPs give you a /64 or even a /128 for your whole network).
Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
> If you only had to update the software for a new IP version and a longer address
By 2005 all the major 'software' (read: general purpose network operating systems) had the software for IPv6 already.
If your application is hardcoded to use IPv4 addresses then you need to rewrite it anyway and no amount of IPv5 would change that.
More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work.
But the most important part here is what were (and I can bet my pumpkin latte - still are) incapable of anything of not IPv4 - because it's the hardware, which routed, NATed, checksummed all that traffic.
You just couldn't slap your IPv5 there by exactly the same reason you couldn't slap IPv6 there - you needed to replace the hardware.
> As it is, virtually everything about networking is different in the IPv6 world
Sorry, but no.
The basics, ie the networking, is exactly the same. Yes, there are some nuances, like using link-local addresses for the gateways, which absolutely, totally, makes sense after a 15 minute reading. But overall it's just another technology, not harder then everything else out there, including IPv4 itself.
> That has significantly complicated adoption for everyone, arguably needlessly
sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. Every year there is something new and you need to learn it[0]. Sometimes to abandon and forget it after a couple of years.[1]
IPv6 is not a rocket-neuroscience, just another set of RFC's and guides. If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.[2]
> And not everyone who says they support IPv6 even actually supports everything that the designers expect
Now you argue what with 'IPv5' this wouldn't happen.
> Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
I wrote about it - it's the problem of the software. I had multiple IPv4 addresses on the same interface many, many times. If that software breaks with multiple IPv6 addresses on the one interface then it would break the same with mulltiple addresses of IPv4 and 'IPv5'.
PS I have a small fleet of PowerConnect 5500 and 8000 switches. They are old, so old 5500 has SSH bolted onto a Telnet server. Yet they did already support IPv6 by 2010. It's already passed more years since the release of 8000 (2010 - 2024) than between IPv6 IETF proposal and release of 8000 (1998 - 2010).
Slow adoption has nothing to do with IPv6 itself, and no IPv5 or whatever would made it faster.
[0] if anything it's slower now
[1] MS Exchange for example. Do you know X.400? I do not, anymore. But for some years I needed to know and I learned it.
> More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work.
This is only true if you use DNS for every network request. That has never been realistic for any home network.
> sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286.
This attitude is part of why many people love IPv6 evangelism.
> If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.
"Easier than IPSec" is not exactly a ringing endorsement.
And note that IPv6 doesn't replace any of this. You still need to know the IPv4 way, and the IPv6 way, and IPSec in both flavors etc.
Sure, it's not neuroscience, but it is needlessly more work, and most people like to not fuss with more work if they can avoid it. Especially when it's entirely duplicated, since, again, you can't drop IPv4 support, you still need to do CGNAT and all that, and then add IPv6 management on top.
Well, yes, just like I learned k8s but still know iproute2 and I still use tcpdump and curl despite knowing how to debug http requests using the web console
And I still manage ipsec tunnels and NAT and I still have to know things about OSPF, even tho I learned BGP more than 10 years ago
In the real world, you cannot simply replace things in the blink of a eye. This is not possible unless you are working in your own, fully-managed environment, never talking to other people (which is a good but scarse position)
Updating the addressing scheme wasn't necessary. If I have 1.2.3.4 and I want to flip on ipv6, I should still be reachable at 1.2.3.4, just using the ipv6 header instead of v4. The hardware/software support is already there too.
Can you describe how you'd make it more backwards compatible? I often see comments like this, yet nobody can work around the fact that you're limited by 32-bit source and destination headers in V4.
It's pretty simple. If IPv6 headers were split into two parts, where the first part was the same as IPv4, and the second part had the rest of the bits, so you had say 8 octets instead of 4. The rest of the header would look like data to an IPv4 router.
So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers.
Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address.
Old IPv4 hosts wouldn't be able to talk to IPv6 endpoints, but at least this way the user could upgrade their own stack without having to wait for their ISP, and every network in between, to also upgrade.
It's pretty much carrier grade NAT but from client to client without ISP support being necessary, which is the biggest bottleneck right now.
Because the IPv4 host can't talk to new protocol hosts. IPv4 hosts can only do 32-bit addresses and don't know about the wrapping. If they did, they would be new protocol hosts.
I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.
Of course they can't. But the point is that if a client wants to interact with IPv6, they only have to upgrade themselves, and not wait for everything in between to get upgraded. And the service can serve on their IPv4 gateway and then pass the traffic back to other hosts to server IPv4 clients.
> So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers.
How does the IPv4 person craft the reply back to the not-IPv4 source?
They don't. They still have to upgrade. But at least the service owner has options to run the services on their gateway and then pass the traffic back to the hosts behind on their internal IPv6 network.
And more importantly it means that if a client wants to interact with IPv6, they only have to upgrade their client, and not wait for everyone in between to upgrade too.
In other words, your proposal establishes only not-IPv4<->not-IPv4 communication over an IPv4 tunnel, which is something actual IPv6 has had for decades?
(There's also the interesting question of how not-IPv4 addresses are supposed to get their not-IPv4 addresses if the entity they get their IP addresses from doesn't support not-IPv4.)
I'm not seeing it... can you clearly explain specifically what scenarios your not-IPv4 deployment strategy enables that doesn't exist with IPv6 today?
(If you're going to say "not-IPv4 local network with IPv4 ISP", then clearly explain how the not-IPv4 local network is supposed to get its not-IPv4 address, and why that is materially different from existing IPv6 tunnel options.)
One problem with this approach is it doesn't really expand the address space for new address assignments. We're still stuck within the 32-bit IPv4 space for the "outer" routing. This seems worse than simply tunneling IPv6 for users with ISPs that don't support it yet.
> Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address.
Any 'expanded IPv4 address' solution will (have) face the same problems that IPv6 has faced, and the solutions will end up being the same: having to slowly upgrade the network stack (hosts, routers, firewalls, ASICs), changes in networking system calls and associated structs (because the number of bits), gateways and transitions mechanisms, expansion of related protocols (DNS A records are only 32-bits, so a new record type needs to be supports (e.g., AAAA for IPv6, AAAAAA for your new proposal)).
If you want to argue that we should have (say) kept ARP instead of moving NDP, sure.
But anything to do with expanded addressing would be the exact situation: code upgrades and transition mechanisms.
I just logged into tunnelbroker.net to check: my HE account has been registered November 22, 2010 11:30:00 UTC. Today it's unused because IPv6 is basically always available in France.
That's not even the first time I tried IPv6 things, part of it being I had some access to RENATER via my engineering school, right when they kicked off IPv6 around 2002.
The past 10 years of IPv6 have been largely uneventful for me: it just works.
> The past 10 years of IPv6 have been largely uneventful for me: it just works.
Yeah, ditto. Except that it has been more like twenty than ten for me.
From my he.net tunnel, to (several years later) my Comcast-provided native IPv6 service, to IPv6 on my phone, to IPv6 with my local ISP (once I switched off of Comcast/NBCUniversal) it has been so very, very boring and reliable for so many years.
> The past 10 years of IPv6 have been largely uneventful for me: it just doesn't work.*
IPv6 worked "too well" for me: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away.
Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML.
And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again.
Someone please prove me wrong, but afaik HE's tunnelbroker requires a sane IPv4 environment, i.e. doesn't work with CGNAT. I'd love to keep using it but since we switched ISPs to one using CGNAT I don't think I can use tunnelbroker.
We switched ISPs so we could get better than 6/.768Mbps DSL w/60ms ping. Now we are on 15/2 fixed wireless w/20ms ping and CGNAT.
> The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address.
In your scheme, any IPv4 address is automatically expanded into an IPv6 gateway address, since there is no other way to map that partial addresses together. So, for every /32 of space you want to add, you have to get another IPv4 and use it as a gateway.
It's also going to be a massive amount of fun doing "second level CIDR" on those gateways.
You've just turned CGNAT inside out to no real benefit.
We do backwards and forwards compatibility between v4 and v6 using NAT64+DNS64 between IPv6 -> IPv4[1] and a reverse proxy (delorean) for IPv4 -> IPv6 [2]. To ensure reachability to IPv4 endpoints without a domain, we use visibleip.com [3].
For our users, it doesn't matter if it's IPv4 or IPv6 - they can reach it, and it can reach them.
If they didn't completely rethink how IPs are associated with hosts, with the whole SLAAC and privacy address and etc crazyness that even ended up making ifconfig deprecated, perhaps adoption could have been much quicker.
IPv6 didn't only impact networking devices, it affected end-user applications that interact with the network in many ways, and this is a big part of the slow adoption.
Each TCP/IP v7 system, whether host or router, must be able to
recognize adjacent systems in the topology that are (only) v4, and
call the appropriate conversion routine just before sending the
datagram.
[…]
On networks where ARP is not normally used, the method is to assume
that a remote system is v7. If an IPv7 datagram is received from it,
the assumption is confirmed. If, after a short time, no IPv7
datagram is received, a v7 ICMP echo is sent. If a reply is received
(in either version) the assumption is confirmed.
If no reply is recieved, the remote system is assumed not to
understand IPv7, and datagrams are converted to IPv4 just before
transmitting them.
So basically very close to what's done now in the IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and try both A and AAAA responses, and see who answers first):
And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized:
There is a non-trivial amount of software that assumes that an "int"
is the same size and shape as an IP address, and does things like
"ipaddr = *(int *)ptr". This usage has always been incorrect, but
does occur with disturbing frequency. As IPv7 8 byte addresses
appear in the application layers, this software will find those
addresses unreachable; this is preferable to interacting with a
random host.
Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6).
IPv7 would have had the exact same issues that IPv6 had with rollout.
There is no "just" when trying to expand a fixed-size data structure across the entire planet.
No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004.
The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet?
Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations.
IPv7 on the other side, had absolutely different philosophy:
The objective of conversion is to be able to upgrade systems, both
hosts and routers, in whatever order desired by their owners.
Organizations must be able to upgrade any given system without
reconfiguration or modification of any other; and IPv4 hosts must be
able to interoperate essentially forever. (IPv4 routers will
probably be effectively eliminated at some point, except where they
exist in their own remote or isolated corners.)
Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6.
> The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet?
Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?")
IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds.
Meanwhile those folks that weren't fortunate enough to around for the early IPv4 address land grab are struggling with shortages:
> IPv7 on the other side, had absolutely different philosophy:
All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition):
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
I am not sure why you keep mentioning gethostbyname(3), socket calls, and so on. As I said, this has been fixed - python's IPv6 support back in 2004 (20+ years ago!) had it all figured out and implemented. Bind 9.2 (released 2001) had AAAA support. You cannot explain difficulties in IPv6 adoption by need to rewrite in 2024.
And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users?
I think the problem with IPv6 is a decision to redo all the management methodology. Your RFC 1726 illustrates it well: there is only one brief mention of backward compatibility in 5.5, listed as "optional" feature, and whole sections about changing the protocol in incompatible way, including 5.8 which starts with:
People complain that IP is hard to manage. We cannot plug and
play. We must fix that problem.
They fixed it indeed! Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes. Certainly possible, but nowhere close to "plug device in and it gets stable IPv4 address which is unlikely to ever change".
> You cannot explain difficulties in IPv6 adoption by need to rewrite in 2024.
The difficulties encountered with IPv6 would have been the same even if another proposal would have been chosen for IPng because the exact same thing would have needed to be done: new address type for syscalls, new data structures, new surrounding infrastructure.
When your original standards do not allow for address length changes/flexibility, you have to write a new standard with the new address size, and there's no way to stuff >32 bits of data (addresses) into a 32-bit field. IPng would always have been a breaking change, regardless of proposed candidate chosen.
And if you're not going to have a flag day (à la NCP-IP changeover), then you'll need transition mechanisms with tunnels for sparse dispersal between IPng islands in a sea of IPv4.
> And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users?
All the proposals for IPng needed to have the same things done. "Technical Criteria for Choosing IP The Next Generation (IPng)":
New packet type/header, new API options, new records and data structures for DNS, transition mechanisms (tunnelling). All this needs to be rolled out to hosts, routers, firewalls, ASICs, etc.
All the while IPv4 would continued to be used, so what incentive would business and IT departments have had to move to TUBA or TP/IX-CATNIP? ("Our (IPv4) network works, why do we need IPv7?")
> Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes.
Before recently moving ISPs (to go from DSL to GPON) I had IPv6 for several years on the old one and all my hosts (cabled, Wifi), phones, printers, etc, had IPv6 addresses given out by RA by my Asus, and I had no issues.
In fact IPv6 worked "too well" for me at one point: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away.
Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML.
And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again.
The IPX/SPX and DECnet folks managed to learn IPv4, so I'm not sure why the IPv4 folks have such a hard time with IPv6. IPv6 is no more difficult a Layer 3 protocol than IPv4.
Because even in 2000-2004, when people starting more seriously talking about adding IPv6 support, BSD Sockets stupid legacy of having every user deal with gory details of used protocol made people write new software using gethostbyname(3) and connect()/listen() calls that used hand-written IPv4 parsers and artisanal sockaddr structs.
And there's a lot of software that never got corrected, that explodes when it reads an address that isn't IPv4 even if uses a more modern API.
Meanwhile IPv4 was supposed to be sunsetted in 1990, had been actively pushed to be migrated off in 1990-1995, but the cost of updating software that used the popular BSD Sockets API, introduction of NAT to remove major pain point, and certain major client (read: government and military) giving waivers on upgrading deadlines to vendors[1] meant that nothing really moved.
And everytime people try to push things forward, some big chunk of infrastructure becomes a blocker - like cloud providers[2] - or we get inundated with "why in 1995 they didn't decide to go with something backwards compatible?". Newsflash - it was impossible for BSD Sockets software to be forward-compatible. If your software was build with XTI or similar interface (like Plan9's dial(), which is present in Go), you got IPv6, IPv7, and IPv9 support back in 1996, along with X.25 and who knows what else. In fact, IPv9 aka TUBA was actually implemented in network hardware around 1992 - the original RFC pointed to experiments using nearly unmodified Sun and Cisco hardware.
[1] US government finally learnt though, and if you're selling to them you now have to support v6 or wrap your product in a black-box that will handle v6. No deferrals for products/vendors.
[2] I'd argue AWS, GCP and Azure had significantly hampered global IPv6 migration
It’s interesting because much of the “better” has eroded away in the current IPv6 landscape:
- “You don’t need NAT”: well, you still need a stable address space for your LAN that survives your ISP randomly changing your prefix (which has happened to me at least a half dozen times over the past year), and the best option for that is ULA, which erodes many of the benefits of “no NAT” because my IP’s are not routable.
- “No DHCP”, well you can’t reliably know the IP address of anything on your network without it: SLAAC with EUI-64 was supposed to make addresses stable and derived from your MAC address, but oops, that’s a privacy nightmare, so we end up randomly generating them (and rotating them!) IMO this is more complicated than DHCP, not less. Oh and DHCP lets you assign dynamic DNS names to every lease you hand out, and you lose that too with SLAAC. You can do mDNS but that doesn’t help with public hosts that you want to access from the internet, you’re left with static IPs there, and god help you if you get re-prefixed (see point #1) because now your static IP won’t route because your ISP changed the prefix.
I’m really rooting for ipv6, trust me, but it feels like all the greenfield rearchitecting they did ultimately doesn’t seem much better than the IPv4 equivalent standards. NAT is here to stay, unfortunately, and so is DHCP.
I have both globally-routable and ULA addresses assigned to the hosts on my LAN. The ULA addresses are in my local DNS, and I update global DNS whenever the site's global prefix changes. Aside from the fact that the global prefix changes way too frequently (like once a quarter) it works great for me.
> ...so we end up randomly generating them (and rotating them!)...
Yeah, I turn this shit off whenever I have the power to. This was a fucking stupid-ass thing to have on by default. Hella buncha ways you can be tracked that give zero shits about what your IP address is. (This is one time when I wish the Net Heads would have consulted with the Web Heads and learned about how trackers actually work.)
> NAT is here to stay, unfortunately, and so is DHCP.
Nothing wrong with doing DHCPv6 and SLAAC, or just DHCPv6. My network just uses SLAAC, but folks who need more features than that provides have another tool they can deploy. This is a good thing.
And you __can__ use NAT if you choose to, but if you're being assigned a publicly-routable prefix, there's no real reason to. Set up your border firewall to deny inbound unsolicited traffic, and set up uPNP (or similar) to hole-punch and you end up with the same security guarantees.
I think you’re making my point for me quite nicely…
Originally it was “IPv6 is great, you don’t need dhcp”, but then it became “well you may need DHCP anyway so here’s DHCPv6”, and then that becomes necessary often enough that you can’t really point to that as a benefit of IPv6 any more.
You don’t need NAT but you need a lot of the systems complexity that NAT requires, because you have to manage two sets of addresses in various configurations. Split DNS, etc.
You’re fine if you own the address range and it isn’t provided to you dynamically with DHCP-PD, but that isn’t the case with basically 100% of residential deployments. You need to multihome to even apply as a RIR to get your own prefix.
Thinking aloud: there needs to be a rethinking of how prefixes work in the next ::/3 we allocate for global unicast: it should be possible for individuals to get their own /48 for basically the same price as a domain name today. Hell, they could make cash as people rush to buy the memorable ones. Make personal route announcement a basic part of ISP service as defined by the FCC. We’d have a fighting chance of actually having a decentralized internet again. But I’m basically wishing for a pony at this point.
You can basically do this today. There are RIPE LIRs that will allocate you a /48 pretty cheaply. There are tunneling services that will route it to you.
I can't get any of that to my house. Comcast doesn't support BGP advertising a custom /48, and I can't even get one in the first place unless I'm dual-homed. The product you linked to has no details but it seems like you can get a /48 for their services, ie. if they're hosting my machines, they'll give me a /48. That doesn't help me.
It helps you if you set up a tunnel back to your location. I have a /48 tunneled back to my home network over wireguard. There are several RIPE LIRs that will guide you through this, even if you're in the US. (You'll need a VPS in the EU to satisfy the contractual requirements. Your other VPSes can be closer to you.)
You can. I have some PA address space, assigned by an LIR, that I announce out of my own AS. All "PA" means is it comes out of their parent block and, if you stop paying, they'll probably want it back.
Exactly. I have a PA /32 of IPv6 that I can sub-allocate and announce however I want. Or even lease to other people. It's my space, as long as I'm paying my LIR for it.
You can do whatever you want with that PA assignment. PA means that it's the provider's address space, not yours. You can announce it wherever you want though.
> I think you’re making my point for me quite nicely
Sorry, what's your point? That having both address autoconfiguration and DHCP is too complex? If so, that's has been the standardized state of the art in IPv4 since 2005 with RFC 3927, and has been non-standard actual practice with Windows and Mac since like 1998.
> ...you need a lot of the systems complexity that NAT requires...
No, all you need is a router that can do IPv6. It doesn't even have to have a firewall, which is absolutely mandatory for consumer-grade border-router NAT.
> ...Split DNS...
I don't run that. My DNS answers local queries for LAN hostnames it knows about and forwards global queries upstream. Just like nearly every consumer edge-router DNS server.
> ...DHCP-PD...
Yep. My ISP runs that on the WAN side of the router. I just do RAs on the LAN side of the router.
> Sorry, what's your point? That having both address autoconfiguration and DHCP is too complex? If so, that's has been the standardized state of the art in IPv4 since 2005 with RFC 3927, and has been non-standard actual practice with Windows and Mac since like 1998.
I don't think I've ever seen two computers communicate over a 169.254 address. Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned. The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
> I don't think I've ever seen two computers communicate over a 169.254 address.
I have. Used to do it often in the dorms when the uni's DHCP server was on the fritz. Zeroconf/Avahi wasn't really a thing, so we'd use Network Neighborhood to get people's IP addresses to browse files or play on servers they were hosting or whatever. I have also (as the RFC envisions) done it when connected to ad-hoc WiFi networks, and also while directly connecting two Windows PCs. In those scenarios, I asked my peer what their IP address was, rather than bothering with going to Network Neighborhood.
> Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned.
Correct. From the second paragraph of the Abstract of RFC 3927: [0]
> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).
> The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
No, it's also recommended when using IPv6 to not use link-local addresses if any other address is available. (Both because those addresses are only link-local, and because one usually needs to put an outbound interface specifier on the address when you go to contact another host, which is pretty obnoxious.) It just happens that IPv6's address autoconfiguration has been upgraded to be useful for globally-routable addressing, too.
So, yeah, a usual mode of both IPv4 and IPv6 networks is to have autoconfigured addresses, as well as DHCP-assigned addresses. It just so happens that most of the time IPv4 addresses are not autoconfigured, and most of the time IPv6 addresses are not assigned by DHCP.
> No, it's also recommended when using IPv6 to not use link-local addresses if any other address is available. (Both because those addresses are only link-local, and because one usually needs to put an outbound interface specifier on the address when you go to contact another host, which is pretty obnoxious.) It just happens that IPv6's address autoconfiguration has been upgraded to be useful for globally-routable addressing, too.
With what seems to be the recommended IPv6 setup at least for client machines, the Link-local address is the only stable identifier of that machine, as the actual reputable address changes all the time. So, the machine has both a link-local and a routable IPv6 at the same time, and both are going to be used. This is still different from IPv4, where link-local addresses are, again, an obscure feature that almost no one uses.
> With what seems to be the recommended IPv6 setup at least for client machines, the Link-local address is the only stable identifier of that machine...
What? ULA space is the IPv6 equivalent of RFC 1918 space. If you want a prefix you know will not change, then you go generate you a /48 and use that on your internal network(s).
Why on earth would people expect ISPs that have a "We won't give you a guaranteed-static IPv4 address." policy to have a "We will give you a guaranteed-static IPv6 prefix" policy? Thinking that way is madness.
Perhaps you're confused because you're looking at guidance for client machines, when you should be looking at guidance for customer edge routers? Check out RFC 7084, and in particular section 3 and its subsections, and section 4.3 and its subsections. [0]
> ...as the actual reputable address changes all the time
Are you talking about IPv6 address randomization? (AKA "privacy" addresses?) IF you are, then know that it's
a) Controlled by the operator of the computer, rather than the operator of the network it's connected to.
b) Optional, and SHOULD be able to be turned off by the computer operator.
c) RECOMMENDED that a stable address be generated for the machine, in addition to the random ones.
Thing c) is in part to deal with "But what if I want to put a AAAA into the local DNS?" problem, and in part to give expected-to-be-long-lived connections an address that the system knows will hang around for at least as long as the interface is up.
After all, unless you want to tear down the connections associated with it, you can't remove an address from an interface until those connections have closed. More addresses allocated to a host means more multicast groups joined for that host, which eats up resources on the local networking infrastructure... so (if you're using "privacy" addresses) you really, really wanna steer ephemeral connections to addresses that are temporary, and long-lived ones to ones that are not.
> My point is very simple: you can’t say “IPv6 is simpler because there’s no DHCP” if there’s DHCP.
DHCP is orthogonal to IPv6.
IPv6 deployment is simpler for many reasons. One being that at the typical end-user site you have neither v6 NAT nor v6 DHCP. Another being that you have enough address space (and we have collectively learned from the IPv4 allocation lessons how bad things can get) to have a good chance of setting things up so that routers need not do quite so much work to route v6 packets.
ULAs aren't the same as a NAT setup. You can assign all of your local devices stable ULAs _and_ also reputable addresses that randomly change. If you do that, there is no need for NAT.
Right, I picked the word “eroded” because it’s not like the benefit is completely gone, but it’s not what was originally envisioned.
I do ULA+global unicast too, but it would be far simpler if I actually had a reliable stable prefix and could just use that. I put my ULA addresses in local DNS (because that’s why I need ULA, I need to not worry about rewriting my zone file whenever my cable modem reboots), but that means I have to do split horizon DNS. I wish I didn’t have to. (Yes I do mDNS too but I need real DNS for lots of use cases.)
> Right, I picked the word “eroded” because it’s not like the benefit is completely gone, but it’s not what was originally envisioned.
You also said
> NAT is here to stay
Which, uh, it sure sounds like you're not using IPv6 NAT. In fact, it looks like aside from probably being confused about what "split horizon DNS" is [0] your setup is exactly like mine. Address autoconfig for both a annoyingly-frequently-changing global prefix, and a constant ULA prefix with DNS entries for the ULA addresses.
[0] Does your DNS server serve LAN _and_ WAN clients? If it doesn't, and it only serves LAN clients, you're almost certainly confused.
They pretty clearly talk about public hosts, so it seems quite likely that they are in fact doing split-horizon DNS (i.e. machine1.site.com will be resolved to an ULA address if the query is coming from the same subnet, or to the public address otherwise).
IF homie is serving public-facing DNS for the site with the same server that's serving local DNS, then yeah, sure, split-horizon DNS is probably the thing that you'd do. But:
> They pretty clearly talk about public hosts
Thing is, I ALSO have public hosts on my LAN. And they're in both the public DNS and in the DNS on my LAN. But public DNS is not served from my local DNS, so I don't have a split-horizon setup.
The mere act of maintaining (in two entirely unrelated DNS servers) records for the same resource but with different data doesn't make a split-horizon setup. If it did, then I could reasonably claim "I'm running a split-horizon setup for mit.com!" just by adding an A record for "mit.com" to my local DNS server, despite being neither connected to any MIT internal networks, nor in a position to serve any data to MIT's Internet clients.
I do DNS such that the same hostname, which I control, resolves to the ULA address if asking locally, but the public address if asking from an external machine. But it's not literally the same server, I use DNSimple for my public DNS and unbound on my local DNS. You can split hairs about whether split horizon means "the same DNS server serving both views" or not, but that's a needlessly pedantic snipe. But to cut off this argument: Sure, you're right. You score one internet point, I used the word "split horizon" incorrectly. You're very smart.
It's not generally good form to cherry-pick things I said from other threads and put them out of context. "NAT is here to stay" can for the purposes of this discussion mean "Thinking about global vs local addresses is here to stay", even if it's not NAT per se that is happening (ie. if you're using a ULA + global unicast, like I do.)
> you're almost certainly confused
I'm not confused. I do split horizon DNS. I serve WAN and LAN clients (not currently from the same DNS server, although that's what I'd prefer to do. The same hostnames are currently configured in different DNS systems depending on who's asking, hence "split horizon".)
To be clear, here's my setup. It's not unique or interesting compared to any other "home lab" setup:
- I have multiple machines that I want to be able to access by DNS name externally.
- I also want to be able to use those same DNS names for local configuration, to keep things sane.
To do this, I have two options:
1) Use the publicly-routable global unicast addresses in my DNS, and make a system to keep them updated in a reprefix
2) Use a ULA prefix for local DNS, and the global unicast equivalent addresses for public DNS, and make a system to update only the public DNS when I get reprefixed
I chose option (2) because I want to mitigate the damage that happens when my ISP reprefixes me. (It's happened 6 times over the past year, it's not uncommon.)
When I get reprefixed, any local traffic that's using DNS to lookup the address keeps working as usual, because the ULA address doesn't change. I have to worry about reconfiguring public DNS, but that's the lesser of two evils IMO:
Because if I picked option (1), I'd have to reconfigure public DNS and my local traffic would all be disrupted while the reprefix happened: My hosts would all be trying to communicate with one another via their old prefixes, and failing until DNS reconfigures.
And this is all not to mention that I have to do the exact same reconfiguration dance with my firewall config: When I get reprefixed, my pf.conf is now referencing invalid IP's. I disable-by-default so it's not a security issue, but it's something that I had to solve with automation (in my case, by templatizing my pf.conf and writing dhcpcd hooks that reconfigure it when the prefix changes. It wasn't trivial.)
Now, to get back to my original argument: IPv6's simplicity benefits "erode" when you consider that worrying about internal vs external addresses is still something you have to deal with in the real world, at least in residential deployments where you don't own your own prefix. Granted: These issues are inherent to any system where your ISP is dynamically assigning you IP's, but it's important to understand: Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work, due to it being the real world.
> It's not generally good form to cherry-pick things I said from other threads...
What? Press "parent" on the comment of yours that I'm quoting from right now four times. You'll find the comment of yours where you say "NAT is here to stay" right here in this comment tree.
> To be clear, here's my setup.
Yep, that's my setup as well, except I don't screw around with applying per-host inbound traffic firewall rules at my router. Either traffic is worth blocking to an entire subnet, or it gets blocked at the host that cares about it. Saves a ton of maintenance.
> Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work...
Yep. It's less complexity than with NAT. Substantially so. That's like the entire point. The additional complexity you keep pointing at is because of a feature that you can't have with typical end-user NAT... the ability for each host on your LAN to have a globally-accessible IP address. And you can get rid of most of what you're complaining about by paying for a static prefix and getting it tunneled to your site, as folks elsewhere in this sprawling conversation tree have mentioned (or getting friendly with a local clued-in ISP and having them statically-assign you one).
> you still need a stable address space for your LAN that survives your ISP randomly changing your prefix
The randomly changing prefix is really annoying. There's no reason for your ISP to do this other than to try and upsell you on expensive commercial services.
This was done so that networks could actually be renumbered to increase aggregation and routing efficacy. In todays work once you give out a number you cant take it back, and that leads to fragmentation (i.e. the swamp)
> In todays work once you give out a number you cant take it back
This isn't true. If it were, then home ISPs would never renumber client networks.
You're probably thinking about the larger allocations handed to folks who have ASNs, rather than the small allocations handed small ISP customer sites... and even then, those can totally be reclaimed.
I think there's an extra, important, oft-missed part implicit in your scenarios:
1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. ... but don't make anyone learn anything new
2) if we're already replacing everything, make stuff better ... and make everyone learn everything all over again
That would still require you to have two stacks and two firewall configurations and all of the other things that prevent IPv6 from being turned on. The only thing you save is by not doing SLAAC and sticking with IPv4-like DHCP you can more easily control things like assigned hostnames, but that's pretty low on the totem pole for blocking issues with IPv6.
SLAAC was just an example, but even here you're downplaying. SLAAC adds a lot of extra complexity: every host now has multiple IP addresses, which was a rarity in IPv4 land, especially for client machines in a LAN; and exactly which IP should be used to identify a host is now highly dependent on details of the network config that are hard to guess (is it using privacy extensions? Will this IP expire daily, or is it more stable?). Plus the dependence on ISPs assigning more than a /64, otherwise SLAAC is broken.
And there are also other things - more dependence on ICMP, the concept that your LAN IPs are determined by your ISP (unless you also assign ULAs in addition to all the other IPs), and probably others I'm forgetting.
The host side issues were pretty much all related to BSD Sockets being shittiest, but cheapest, network stack on the block.
For many years it embedded the idea that every application had to handle exact details of each protocol it wanted to support through its exposure of gory details in sockaddr struct and requiring that as input to connect() and listen() calls.
All the SLAAC, privacy address, etc? That's just an emanation of people cargo-culting some practices that were workable with IPv4 but only by making the network suck.
And ifconfig got deprecated because it didn't fit linux networking API anymore, and nobody wanted to maintain it instead of writing something that fit well - which was iproute2.
You could have just extended the IPv4 header in such a way that the routers in between you and the server didn't need to understand the extended protocol, and could continue to route IPv4 packets as-is, since they only see the upper 32 bit of the address. Then network inside LAN and the server need of course to understand IPv4-extended (let's call it IPv5) packets, but still you only need to update the endpoint devices, and not the core of the network (fare easy, since that evolves more quickly!). You could also implemented a mechanism "similar" to NAT, where the router did for outgoing traffic compose the extended "IPv5" packet by combining the local IPv4 and the external IPv4, and did the opposite operation for incoming packets. That way really only the router needed to be updated, and not individual devices in your house. Thus being backward compatible in both ways.
Also adopting IPv6 these days would require to maintain still IPv4, this means that for example firewall rules must be made both for IPv4 and IPv6, something that adds a lot of work to IT technicians (and they thus disable the protocol that if you disable the internet still works, that is IPv6). Extending IPv4 would mean that the same firewall rules can apply, just considering again the upper 32 bits of the address.
Finally IPv6 is in general more complex, it has some obscure things like SLAAC or the fact that an interface can have multiple IPs, that not all IPs are routable, etc, even simply the notation for IPv6 addresses that is not even consistent among software (in some software you have to put it between [] to disambiguate with port numbers, in some other not), DHCPv6 implementations that are still these days quite broken, etc. Compared to IPv4 is quite a complication...
I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4, and requires maintaining a network with two protocols, since everyone completes the migrations, this is unlikely to succeed in the next years (for example in my country, Italy, most ISP, even the most important one, don't even bother to provide you an IPv6 address! I think that because it does increment the problems and thus the requests to handle in the customer service, thus they decided that you just get IPv4 that works reliably).
> I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4
Doubt, seeing how IPv7 appeared around the same time as IPv6 (RFC1883, from year 1995) and we still don't see IPv7 anywhere.
To be fair, IPv7 seems to have been deprecated in 2012 (RFC6814). It had almost 20 years to catch up but, quoting the RFC, "IPv7 was never widely deployed".
The issue is really forwards compatibility. Every ipv4 address should've been kept valid in all ipv6 networks.
Step 1 would've been to leave all the routing, DNS, NAT, DHCP etc as-is and just get people's devices speaking ipv6. And we would've already been there years ago. Once that's done, DNS and DHCP can be updated, then people can start using the extended address space by splitting up their blocks. So if you previously had 1.2.3.4, you now also have 1.2.3.4.1 etc.
It's actually not too late to do this with the existing v6 header.
It's not the case that there were no alternative designs at the time that v6 was proposed. RFC 1385 described a backwards compatible Extended Internet Protocol which used IP Option headers to stuff in extra addressing space.
Earlier IP migrations were done when the internet was run by universities and government bodies who felt the need to migrate to a newer standard because there was a newer standard.
IPv6 took longer because the internet is now run by companies that need to see a return on investment, and as long as IPv4 was working fine for their customers, didn't see a benefit to it. It's why IPv6 adoption only started taking off when the answer to "Our projected customer growth this year is 200,000, can we have 200,000 more IPv4 addresses please?" became "No".
It was created by people who were used to the Internet being an ultra high trust relatively close knit community of universities, research, government, and industry. Upgrades across the net had happened before just fine. This one should be no problem.
This was around 1996, which is when the vertical growth phase took off. Too late.
This was deliberate: the idea was that IPng wouldn't get adopted, or even traction in the IETF, if it didn't provide additional functionality/fix perceived problems beyond just address space exhaustion. Remember also that NAT wasn't really a thing at that time. It might have existed but wasn't widely used like happened subsequently.
I can certainly understand that perspective. But from today's perspective, it seems like IPv6 adoption was slowed by ideological arguments like "people should use SLAAC, not DHCP". By all means introduce a new means of obtaining addresses, but let it live or (preferably) die on its own merits, rather than attaching it and a dozen other albatrosses around IPv6's neck. If IPv6 had started from day one by saying "just add an IPv6 block to your DHCP server and let any client that understands IPv6 get an IPv6 address", that would have been an easier sell.
This. IPV4 is a mess.....and its extremely frustrating just how unsupported ipv6 is.
IPV6 is one of those things where if isp,'s just switched over to it, I'd have so less nightmares caused by cgnat and that bullshit like how expensive static IP's are.
Many its because I'm not working at a ISP or a teir 1 backbone but forcing the transition to ipv6 seems like overall it would be less of a clusterfuck than our current ipv4 stuff. I know their is stuff going to break, anytime changes are made at this scale it often has some hickups....but dear god I really hate how static IP's are so expensive, and how expensive a small IP block is. Also IPV6 is just an excuse to get fiber everywhere.....I hate how slow many services are.
People hail CGNAT and IPv6 as the savior but don't realize you still need v4 addresses to make it work.
CGNAT at scale functions by assigning a range of ports on a shared v4 address to a downstream customer. You can normally get between a 1:8 and 1:32 "compression ratio."
We still need to free up additional IPv4 to keep the internet growing. Don't let the "just switch to v6" crowd fool you, both solutions need to addressed in parallel.
IPv6 depends on IPv4 addressing if you have downstream devices that need to reach the entire internet. If you go to ARIN they have an explicit policy of allocating IPv4 blocks to facilitate IPv6 deployment.
CGNAT is a term that broadly used to refer to carrier-scale solutions to deal with issues with number exhaustion and dual-stack deployments. What most people think "CGNAT" is, is actually NAT44. https://nfware.com/blog/why-cgnat
Mobile providers have IPv6 only networks and use NAT64 with CGNAT and DNS64 to permit access to the legacy internet. No incoming IPv4 ports. CGNAT can serve way more than 32 customers per IP, and they are pooled.
The problem is that you have to have working IPv4 in some form, because enough major sites (e.g. Twitter, Wordpress, Github, Pintrest, Vimeo, bit.ly, TikTok, Tumblr, the New York Times, but also mozilla.org and Archive.org) don't support IPv6. [1]
Likewise, some Linux mirrors don't support it. If I decide to try an IPv6-only server, and the first thing I see after "apt update" is network errors, I'm not very motivated to use IPv6 in the future.
Then add some problems where having IPv6 enabled randomly breaks things for one reason or another. I can either debug it forever, or turn the "internet is broken" switch (labeled "Enable IPv6") to "off" and get on with my day. That means more people that support IPv4 but not IPv6 (to be fair, this one seems to have gotten a lot better).
But ultimately, until some major, hard-to-avoid site says "we'll only be on IPv6", there is little reason for most to use it, and many reasons not to. That's why the transition takes forever.
It's a bit of a chicken-and-egg problem. Major sites don't deploy IPv6 because "everyone has IPv4", and people don't roll out IPv6-only servers because they still want to be able to reach IPv4-only hosts.
Amazon has hopefully started a change in this mentality by charging money for every IPv4 address used. This creates a real financial incentive to deploy IPv6-only servers, which in turn means that critical services like Github and Linux mirrors are slowly forced to provide IPv6.
afaik there was a serious lack of v6 support within aws services. has the financial incentive reached this far or do they just want to charge you more?
NAT64 is a thing, combined with CGNAT it offers a way for IPv6 only clients to acess the legacy internet. Mobile prividers are doing this, ISPs can as well. It would incentivize IPv4 only sites to upgrade, to avoid the CGNAT.
I am absolutely convinced that the main thing holding V6 back is not even that it’s a full shift rather than an incremental upgrade. It’s that the addresses are too long to easily remember or type and the text representation is unwieldy and aesthetically ugly.
Anyone who has ever done net stuff for a living knows that you type or copy paste addresses constantly. Whenever I say this to V6 evangelists they say “we’ll use DNS” which is “tell me you’ve never been a net admin without telling me.”
I’d love for V6 to get traction but I think something needs to be done about the usability issues before it will happen.
Even little details like the fact that in no terminal does double clicking on a V6 address properly select it is a huge problem. Yeah you might be able to change that but that custom config won’t be there on the next machine, etc.
Even seemingly simple usability problems are death to adoption.
I’m a NetEng for a large (>1M servers, >100 POPs) network that is IPv6-only internally.
It’s not hard to remember IPv6 addresses for DNS servers assuming your addressing plan reserved the right subnets for anycasted services.
Remembering IP addresses stops being a thing pretty quickly. If anything the challenge shifts to remembering airport codes.
If you are typing them by hand that often even in IPv4 networks I'd be worried about typos and insufficient automation.
I think it’s more that small and medium organizations just don’t have any incentive to change (and plenty of incentive to not take the risk of change) leading to the numbers we see at https://ipv6-in-real.life/
> If you are typing them by hand that often even in IPv4 networks I'd be worried about typos and insufficient automation.
Automation is all very well once the network link is up and working so you can reach the automation
But the reality is you put someone who knows what they're doing in front of a machine where the network connection isn't working, the first things they're going to be doing is ifconfig and ping 8.8.8.8 - which they'll be doing from memory, because you can't google anything when your network connection isn't working.
The fact that IPv6 will deprecate both ifconfig and 8.8.8.8 to me seems emblematic of why the adoption has been going so badly.
ifconfig got deprecated because it didn't match how networking worked in the kernel.
If you're using ifconfig on linux[1] for the last 10 years, I'm going to negatively look on your claimed expertise
As for point-to-point links, that's what simple link-local addresses are, added in ipv6. And why IP-IP is superior to OSPF, both because it doesn't hardcode address sizes and because it runs on Layer 2.
[1] ifconfig on other systems might be the right command
> Automation is all very well once the network link is up and working so you can reach the automation
With properly constructed automation and modern* hardware, you don’t need to do any manual config on-box for automation to be reachable. Zero-Touch Provisioning is a wonder to behold.
Modern being relative. I saw this work on routers terminating telco circuits nearly 20 years ago and had servers netboot and install the OS with basic config before that (though automation was far more tedious back then)
The absurd lengths this industry goes to, only to avoid the switch to IPv6. Wish the FCC would step in with a mandate or something, it’s just long overdue.
Networking software and routers without ipv6 should be considered a security issue at this point and should have CVEs assigned against them. It's amazing how we deprecated unencrypted http across the internet but still use the equivalent for ip addresses.
It’s not a logical argument, but if we only take the part about the transition to https, the difference was that https and http coexisted with mostly full compatibility to go between the 2 for its whole life. And it lives at layer 4.
A more cogent argument is that IPv4 and IPv6 have not fully coexisted like http/https, where you can pull the ipv4 rug out and every packet has an ipv6 path like http to https did.
Also more profoundly, https conversion had the benefit of every operator being able to transition on their own time frame. And people can still opt to use http if they so choose. IP not having that luxury is a profound problem.
> ...https conversion had the benefit of every operator being able to transition on their own time frame. ... IP not having that luxury is a profound problem.
This I don't get. I expect that Google will be far more likely to make it extremely difficult (or perhaps impossible) to use Chrome to visit non-TLS-wrapped HTTP sites on the Internet in the next five years than the operators of the various networks that make up the Internet are to just shut off IPv4 on their network.
I expect IPv4 will not be shut off within the lifetime of anyone posting on this forum today... and why would it be? Once just about everyone has well-functioning IPv6 access, release a recommendation to ISPs that unless a customer has an even vaguely-reasonable need for a globally-routable IPv4 address, that ISPs substantially reduce their IPv4 usage by providing IPv4 service to their customers through some CGNAT.
This would ensure that the few remaining hosts with IPv4-only service will remain reachable, that any customers who can bother to write a letter to their ISP asking for a globally-routable IPv4 address can get one, and a ton of IPv4 space gets opened up for whatever we might need to do with it in the future... just in case.
So surprised that hacker news is stuck in ipv4 land. Even if you disagree with the method, I do not consider a device not capable of IPv6 to be using the real internet anymore. It's the same with the housing market where people would rather speculate on IPV4 houses instead of building plentiful IPv6 apartments.
The industry is switching to IPv6, just slowly. Google's report of the fraction of users accessing its services on IPv6 steadily rises by a few percent a year. Right now it's at about 45%, so it'll be the majority in about two years.
Such a mandate would still be useful. Even of 80% of users can view things on ipv6, very few people will sacrafice the 20%.
I'd like to see rules that force ipv6 support, and then to prevent idiot network admins from disabling ipv6 locally because they're too lazy to learn how it works, make some websites v6 only. Start with essential government websites and move on to laws forcing more and more private websites to be v6 only to force people to maintain its functionality in their networks.
The market has been given its chance to move for DECADES and we're not NEARLY at the approximately 100% deployment that we need. It's time that we fix this mess.
Adoption rate is currently increasing roughly linearly at a rate of about 5 percentage points every 12-18 months. Also note that there is a clear weekday/weekend pattern, with weekdays about 3-4 percentage points lower than weekends.
IPv6 "adoption" is happening at roughly the same rate as the move to handheld devices becoming the primary browsing platform. The weekday split you see is people being on their work computers during the day and personal tablets/phones on weekends.
Very little progress has actually been made to move the bulk of stuff using v4 addresses over to v6. AWS v6 only instances have only been around for 20 months or so?
> AWS v6 only instances have only been around for 20 months or so?
a) According to [0], AWS has provided IPv6 addressing to EC2 instances since 2016.
> IPv6 support for Amazon Elastic Compute Cloud (Amazon EC2) has been available along with IPv6 support for several other services since 2016.
Refer to the 2016 blog post at [1], which says (among other things)
> By default, every IPv6 address is public and internet-routable. For customers requiring a private subnet on their IPv6-enabled VPCs, we are introducing a new resource within the VPC called the Egress-only Internet Gateway, which can be setup to allow one-way access to Internet resources.
b) I don't get the "This migration only counts if we can support only IPv6 and shut off IPv4" obsession. I see no reason to shut off IPv4 within our lifetimes. I expect the distant future will be providing end-users with a globally-routable IPv6 prefix and a CGNATted-to-hell-and-back IPv4 address for reaching out to those sites that may still be using v4 only.
> 2022 is when they added native IPv6 support, prior to that it was just a fancy NAT like translation.
Are you sure about that? The relevant docs from 2019 (the Wayback Machine doesn't have anything earlier) sure make it seem like you're getting globally-reachable IPv6 addresses:
From [0]:
> To complete this exercise, do the following: ...
> * Launch an Amazon EC2 instance into your subnet, and associate an IPv6 address with your instance during launch. An IPv6 address is globally unique, and allows your instance to communicate with the Internet.
Yes, the last bit of that doesn't automatically mean that your instance is globally-reachable. Read on.
From [1]:
> IPv6 addresses are globally unique, and therefore reachable over the Internet. You can control whether instances are reachable via their IPv6 addresses by controlling the routing for your subnet, or by using security group and network ACL rules. For more information, see Security.
From the "Inbound" table of the "Recommended Rules for Scenario 1" section of [2]:
> | 170 | IPv6 address range of your home network | TCP | 22 | ALLOW | Allows inbound SSH traffic from your home network (over the Internet gateway). |
Am I missing some part of the docs where they talk about how there was some fancy NAT-like translation box that made it so that these weren't globally-reachable IP addresses? Was AWS just lying in their docs?
You seem to be confusing being able to reach IPv6 with native IPv6. With rare exceptions AWS does not document how their internal network functions because it is a trade secret. However for the longest time it was fairly easy to test: if you removed the IPv4 address from an instance it was no longer reachable via IPv6.
AWS was never built with IPv6 in mind and it is mostly glued on. As of right now 88% of AWS services are IPv4 only: https://awsipv6.neveragain.de/ (uncheck the Hide IPv4 only box)
> You seem to be confusing being able to reach IPv6 with native IPv6.
I mean, on the one hand, I'm taking AWS at their word. If they wrote subtle lies into their docs, one can hardly be blamed for failing to understand the truth of the situation.
But on the other hand, if
* My VM has its globally-reachable IPv6 address assigned to it
* Can transmit packets to globally-reachable IPv6 hosts using that address
* Can receive unsolicited packets from globally-reachable IPv6 hosts on that address
whatever hairs you're splitting seem to be a distinction without a difference? Based on my professional experience, "wacky SDN stuff" is par for the course in the Public Clown.
Or, to put it another way, the customer of an ISP couldn't care less about how exactly that ISP delivers them globally-reachable IPv6 service, just so long as it behaves exactly like you'd expect globally-reachable IPv6 service to behave. Maybe between the customer's edge router and the Internet the ISP has some wacky tunnel that runs only over IPv4, and breaks IPv6 service if you turn it off... the customer doesn't give any shits, just so long as the IPv6 service works correctly and reliably.
> As of right now 88% of AWS services are IPv4 only...
This to me is an entirely irrelevant statistic. My expectation is that end-user systems aren't going to be IPv6-only for a very, very long time, but are going to nearly all have globally-reachable IPv6 addresses relatively soon.
So, one should (for the foreseeable future) expect global bidirectional reachability for end-user systems on IPv6, and typical NAT "initiated by end-user request" reachability for end-user systems on IPv4.
IPv6 is still second-class for a lot of AWS's other services, so unless you treat AWS as just an overpriced VPS/colo it's not going to work all the way through.
my ISP has no plans for it.. and even escalating it to the highest levels the best answer was something like they're focused on upgrading physical infrastructure and aren't bothering with IPv6 at this time (despite me casually asking for 10+ years)
Sure, but what happens in the U.S. part of the Internet tends to set the tone for the rest. A U.S. mandate would do a lot to swing things in the right direction, and many other countries would likely follow along and pass similar mandates.
Yeah, problem is that we’re competing with ~99.99% for IPv4. So until IPv6 gets in that ballpark, most Internet servers (HTTP and friends) will still need to IPv4 addresses. And as long as that is true, many companies won’t bother and their service will be IPv4 only. Meaning ISPs must continue to offer IPv4 connectivity to their customers.
A true chicken and egg problem.
At this rate, we’ll be struggling with IP-shortages, CGNAT and other fun things for decades to come. And it’s all so unnecessary.
This is how you end up with a nationwide ban on IPv6. When traffic lights start flashing red, flow control valves in the water distribution system fail safe closed, and ATMs don't work people will quickly discover the correlation with your silly plan.
If any of those things happen because of a one-minute interruption in internet connectivity, the people who implemented them that way should be pilloried. What an absurd strawman.
American here, I've had IPv6 on literally every device I've had for almost a decade now. Every mobile provider has been v6 since LTE. Comcast migrated to v6 over a decade ago because they exhausted 10.0.0.0/8 in their control plane network (they have a lot of cable modems). And I'm on Google Fiber now which is all v6.
There's probably a few other ISPs that need a good kick to the groin in the US, but the general feeling I get here is that the real stragglers in v6 deployment are other countries. Indeed, looking at Google's IPv6 map[0] it's all countries in Africa and the Middle East that have the worst v6 adoption. It's places where there isn't enough demand for addressing to make CGNAT unviable and IPv6 necessary.
USA is has to much legacy interim to do this. I think India has the best leverage having being one the highest IPv6 adoption and shear number of internet users, so it easier get all main blockers of IPv6 only internet usuable.
The government should start by rolling out IPv6 for its own stuff before telling others what to do. I say this because they need to learn how to do it too/first.
> While there are somewhat ongoing efforts to see 0.0.0.0/8, 127.0.0.0/8 become routable unicast space
I am curious about this statement. How can 127/8 ever become internet routable? It is after all used for the local host. Or am I misunderstanding something here?
Most deployments only use 127.0.0.1/32. Some niche cases use 127.0.0.0/24. Vanishingly few use more than that. Keep the /24 reserved for local use, and repurpose the rest for global unicast.
systemd's resolved commonly uses 127.0.0.53, Given the deployment of systemd I would not really call that a niche cases in terms of volume, but I do agree in general that 127.0.0.0/24 would in theory be enough. However the whole discussion on repurposing 127.0.0.0/8 is mostly academic as it will be basically impossible to use reliably
Except someone like Google would likely also want their site to work, and thus I expect them to be unwilling to use such a problematic IP.
If any big site (or even better, many big sites together) were willing to go that far, a much better measure would be announcing that they'll go IPv6-only on the next IPv6 day. Just for that day. And then again the next year, but for a week. Then for a month the year after. Then permanently. That would give ISPs the kick in the butt to fix it, because nobody wants their hotline to field a day full of "my Internet doesn't work" calls, only to then have to fix it anyways because otherwise it'll be a week next time.
The whole /8 is "on-net" for the loopback interface, but that doesn't mean it's usable to applications. On macOS, I can't ping or bind to 127.0.0.2, for example. Linux's behavior of allowing the whole /8 to be used, even when only a single address is assigned, is a bit of an oddity here.
> Linux's behavior of allowing the whole /8 to be used, even when only a single address is assigned, is a bit of an oddity here.
Per the RFC: "127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host."
Yes, exactly. If I connect a physical loopback adapter to a network interface, I can't just ping any on-net address and expect a response. I need to add it as an explicit interface address/alias first. Just because the packet loops back on the interface doesn't mean that it will then be treated as if it were addressed to the host.
Linux special-cases 127/8 on the virtual loopback interface and will treat all looped-back packets as if they were addressed to the host, even when the destination isn't explicitly configured as an alias. This behavior is not required by the quote from RFC3330.
I've used 127.0.0.0/16 for real work[1]. Keeping a /16 is not much cost and helps out a few more niche cases. Although, I guess if it wasn't available, I could have used a /16 in private space that didn't overlap with my existing network.
[1] I needed a lot of localhost connections to run a TLS terminator separate from the underlying service which didn't support unix sockets. Using the 127.0.X.0 bits in addressing was very helpful for diversity in the hash used for kernel socket tables, otherwise most slots had few sockets and some slots had way too many and perf was bad. Configuring multiple loopback interfaces using more address space was a lot more tractable than changing the kernel hashing behavior, adding unix socket support to the underlying service, or adding good TLS to the underlying service. Although probably since then all three things have happened.
What's the use for multiple local loopback IPs? I'm not a networking guy, just backend dev, so 99.99% of my 127.0... use is running applications locally.
For your TLS thing, is it whatever application you were using expected to use a whole swath of TCP ports at whatever IP address, so expected separate IPs?
Feels like dedicating some range of addresses to "private use" would have been useful, then if you needed a bunch of local loopbacks, could configure it so, or if your local network wants some magic, tada.
I think the intent comes from the fact that most people never use any other address that 127.0.0.1 (yes, I know about docker DNS). It sort of comes across as if you were "wasting" a large block of adresses on functions that are seldom used. In reality though, this isn't a solution and we should really just go forwards with ipv6.
Where there is a will, there is a way. Off the top of my head, most localhosts stay within 127.0.0.X/24, so one could slowly peel off the top parts of the /8 until we start encroaching too closely on the /24 most people tend to stick to.
Sometimes you see 127.0.1.X/24. I've even seen 127.1.X.X around, but I've never seen 127.254.X.X around. I'm sure someone somewhere did it just for grins and giggles or something though.
The same way that 240/4 can become internet routable: a global effort to change defaults and push code and configuration changes everywhere over the next two decades.
It isn't all in use on most machines. Many hosts only use 127.0.0.1/32 and do not use the rest of the space; changing the default netmask on the loopback interface from /8 to something like /24 would be one step of the transition.
I think that it's the most problematic proposal from all these – unlike 240/4 etc every ip stack on earth has hardcoded knowledge about 127/8 for sure and it will took at least decades to deprecate all these. And I also have seen addresses other than 127.0.0.x used in wild. As far as I understood, some orchestration systems use generated 127.x.x.x addresses to avoid conflicts between applications. Linux makes it very easy – you just bind an application to 127.45.2.189 for example and it just works. There is no need to add it to the interface or something.
An org with that level of technical control might well be an extremely security-conscious org. And "No IPv6 Anywhere, Ever" would make it somewhat easier to keep things secure.
It would presume its significantly easier to implement routing for a few more blocks of IPv4 addresses than switch the entire underlying infrastructure to IPv6, which requires different infrastructure than IPv4 to work properly (like dealing with SLAAC/DHCPv6 addresses, ICMP, and AAAA addresses)
They might have to interact with a lot of devices that only support IPv4, and will never upgrade. These include a lot of industrial PLCs and various embedded devices.
10.0.0.0/8 might seem like a lot of addresses, but certain large companies have enough fans and chillers and miscellaneous things that can fill that space, and it takes a lot of effort to reorganize their network to better allocate those addresses.
Sadly I'm in that position. I have hundreds of PLCs and legacy controllers on my network that are IPv4 only and will never be replaced. At least not in a reasonable time frame. I'm talking 20+ year life expectancies.
> 10.0.0.0/8 might seem like a lot of addresses, but certain large companies have enough fans and chillers and miscellaneous things that can fill that space
Do these large companies really have 16,777,216 fans and chillers? That would be enough for each of Wal-Mart's 10,586 stores to have 1500 IPs each.
> Do these large companies really have 16,777,216 fans and chillers?
Some of those might be regular servers or networking gear that are required to have IPv4 addresses for one reason or another. For example, they might need to interact with fans and chillers.
> legacy allocation mistakes
Requiring the same globally unique prefix for devices that share locations or functions would eat up allocations faster than the number devices would grow. But there are definitely good reasons for allocating addresses that way, just as there are probably good reasons why the number of ports on a switch isn't always a power of 2.
Sometimes they might have been able to allocate it more compactly - but how do you predict exactly what your needs will be in 20 years?
Other times they might not have been able to allocate it more compactly - are you really going to go make routes for a /25 and a /26 and a /27 when you need 200 IPs, just to save a single /27 over giving it the whole /24?
There can also be reasons to structure it more sparsely than required for UX, namely to give a more hierarchical structure - maybe by region and store, or similar.
tl;dr it's not necessarily a mistake that your allocations mean you use more space than strictly necessary
> Since the internet was at the start not obviously going to be used, the minimum allocation size for an address block was a /8 at the start, later on we got “classful” allocations where a /16 would be assigned instead (this is why you often see /16s assigned to universities or institutions of similar ages),
Classful allocation had /8s, /16s, and /24s depending on the numeric prefix (0-127 were /8, 128-191 were /16, and 192-223 were /24).
No in fact, it is so much worse! I do agree we should use IPv6, The ending of the blog post says as such :)
> If we are going to start using address space that might not work for all users, it would be wise to pick the address space that we already have a considerable head start on getting accepted: IPv6.
I'm yelling at the people doing this shit, not you :)
Somehow it is getting more and more common. I stayed at a hotel last year that used 1.0.0.0/24 on its LAN (yes, '1' not '10', I couldn't believe it at first).
This was very common in the past. People abused 1.0.0.0/24 because it was unused. There was even one of the big ISPs in Italy assigning such addresses for their customers for CGNAT...
I'm not connected with this presentation (other than having talked to Ben about it prior to his giving it, and I guess supplying some of the information on software that accepts 240/4) but I am one of the people working on the project that he describes/criticizes.
People have been reacting to this with different forms of "just do IPv6" for many years. I guess we need an official statement about that somewhere. [Edit: other than these quick thoughts below...!]
I personally think IPv6 is great (I was excited about it in the late 1990s when it was standardized, and gave some talks to promote it, and am happy to see it getting deployed and happy to find myself using it sometimes). I hope people will keep working on it and networks and services will keep adopting it.
However, people's need for IPv4 address space depends enormously on other people's behavior. IPv6 addresses are not a good substitute for IPv4 addresses when you're providing a public service, if many of your users don't have IPv6. A high fraction of demand for IPv4 address resources appears to come from organizations and networks that already support IPv6, because they need dual-stack support for compatibility with other people.
Even though IPv6 adoption has been happening, it's easy to imagine that it's "almost done" where that really doesn't seem to be the case. (This is complicated by having very different statistics in different countries: some countries are now almost all IPv6 traffic, while others have almost no IPv6 -- so people in different parts of the world often have rather different intuitions about it.) We still see enormous economic demand for IPv4 address space and projections that IPv6 adoption to a point where IPv4 would somehow no longer be useful or important is likely still decades away. If that's correct¹, we can still get a benefit from making 240/4 usable because that process can be substantially complete during a time when IPv4 is still extremely important.
One thing that Ben (and one of the questioners at the end) argued in his presentation is that even if the adoption of IPv6 is unreliable or erratic, it might be more reliable than useful adoption of 240/4. (This was kind of phrased in the converse direction.) I'll have to think about models of that issue.
Edit: We have been sad when seeing how proposals to make 240/4 usable were made in 2008, but not adopted at IETF. Among things that people said in 2008 was that IPv6 would make this irrelevant quickly. That turned out not to be right, but we lost years of opportunity to make 240/4 more useful in the meantime, where billions of devices shipped in the interim could easily have supported it by default. So, we still have the opportunity not to have the same sense of regret in 2035.
¹ I'm also aware that there are other projections here; I recently interviewed a prominent Internet greybeard figure who theorized that Internet infrastructure growth as a whole has slowed so much that IPv4 demand may be satisfied in the future out of gradual conversion of residential ISPs to using primarily carrier-grade NAT for IPv4, and then selling off their number resources. In this account, IPv4 will remain important on the Internet for a long time, but economic demand for addresses will decline because most users won't have native IPv4 at home or on their mobile devices (the latter already the case in many networks). The economic demand for IPv4 resources is something that has made reclaiming 240/4 appear worthwhile, so in this model it would become less exciting, even without having IPv4 "go away".
Just wanted to chime in and say thank you Seth for all of the work you did to create LetsEncrypt.
You've made the internet safer for all of us.
I believe that IPv6 [1] is without a doubt coming in the future. Even with carrier grade NAT'ing and the likes, there are too many major providers who have already switched to single stack IPv6 natively.
That said, I agree that 240/4 is necessary to assist with the transition. Due to the fact that most network operators aren't even dealing with /24's, it becomes increasingly hard to facilitate bridges between the legacy IP and IPv6 so more IPv4 space is always appreciated (until the day we don't need to bridge at all).
[1] I may have a bias due to affiliation with https://IPv6.rs
The disappointment is there seems to be no difference between "needing a single open port" and "needing and entire IP address" due to overzealous egress firewall rules that everyone thought was good engineering practice 20 years ago.
I wish it were just some old boxen from 20 years ago. $employer STILL does port-based firewalling and thinks it's great policy. Just getting SSH to github requires requesting an exemption.
> $employer STILL does port-based firewalling and thinks it's great policy.
And they're not wrong either, it by definition disables not just a whole class of (admittedly outdated) communication channels for malware (such as IRC), but also other stuff you don't want to happen on your network either: bittorrent, people running online games during work...
I want to say something else about IPv6 adoption! (Apart from how you can't necessarily unilaterally stop using IPv4, even if you can unilaterally start using IPv6.)
There is a great level of IPv6 awareness and enthusiasm in sort of technically elite spaces. Like at Ben's talk at RIPE that we're talking about, the audience was kind of laughing together at the non-IPv6 outgroup.
Meanwhile, I keep helping people use Let's Encrypt over on the Let's Encrypt forum. One of the most common reasons that people are failing to get their certificates is ... misconfigured IPv6 on their servers or in their DNS! And people in that situation often (1) didn't think of that as a possibility, (2) didn't notice (!!), (3) didn't necessarily care about it. Even worse, when people are told something like "your certificate issuance isn't working because your AAAA record is pointing at your old hosting provider rather than your current hosting provider" their usual response is to delete the AAAA record rather than updating it.
Other forum members may also advocate this as a solution. "Oh, just delete your AAAA record, you don't need it."
I'm not making this up, I've seen these things happen about 100 times on the Let's Encrypt forum.
Now, these are primarily sites in the long tail of Internet popularity, the proverbial Joe's Lamp Store rather than Gmail or Facebook or something. But the level of IPv6 awareness and interest among small-scale site operators and people doing small-scale IT stuff is very weak. And I've also seen that a surprisingly high fraction of web sites are IPv4-only rather than dual-stack.
I'm working on 240/4 usability, but I certainly don't want people to delete their AAAA records. I want them to know what an AAAA record is, and want to have their AAAA records be correct.
But there's quite a gap, in a way, between the elite and the non-elite tech spaces on this.
It sounded like they were saying that people had badly configured IPv6 and/or AAAA records that prevented stuff from working; the fact that you don't technically need it is why the "solution" of deleting AAAA records would make sense in this context. If my understanding is correct, then part of the problem of IPv6 adoption is people not really understanding what it is or why it might be useful, instead seeing it as a nuisance that they should avoid. Crucially, they're not exactly _wrong_ with this viewpoint because IPv6 doesn't really provide any benefits at the individual adoption level; the benefits are only realized if others adopt it as well, and that's not likely to be a convincing argument to someone having a concrete, immediate issue with their servers that they can address (pun intended) by not supporting IPv6.
If you do have AAAA records, Let's Encrypt (not unlike other software and services!) will prefer the AAAA records when doing domain validation for your domain. So if you have a correct A record and an incorrect AAAA record, your domain validation process will fail. You can then "fix" this by deleting the AAAA record, but it isn't a fix in the larger scheme of things, but indeed it makes plenty of users happy right away.
I intentionally disable IPv6. It provides no advantage whatsoever (every user will be able to connect via IPv6) and it adds complexity and security risks, because you need separate firewall rules, dns records, etc for each stack.
In addition, rate limiting with IPv6 is much harder (because IPs aren't scarce), so you risk DoS or other kind of abuse.
And rate limiting is very uncertain. If I limit per /56, users that have an entire /48 can outright bypass the rate limit. If I limit per /48, maybe I'll erroneously limit thousands of users whose ISP has all of them on the same /48.
The difference between a /48 (like my residential handoff) and a /64 (like some people get) is the same as a difference between blocking a single /32 ipv4 address and blocking an entire /16 - which is a very large allocation
If you wanted to block me, you'd have to block the whole /48. If you blocked a /48, you could be blocking 64,000 people.
I haven't experienced such congested CGNATs. And assuming there are people who are under such CGNATs, they are probably used to being rate limited all the time.
But the exact same issue exists with IPv4 due to CGNAT? A single IPv4 address could be used by a single user, or their ISP could be sharing that same single IP with many thousands of users.
My employer also disables it (choice made above me). And I get it. It really is duplicating lots of work for absolutely no benefit (to the organizations doing the work).
It's a shame that you're getting downvoted. I'm sure a lot of those people are shouting at their screen "well just learn it" but even if you're familiar enough with all the stuff it changes (RA, NDP, heck the lack of NAT), it's still a ton of work to get it properly set up and worse yet to maintain.
The whole duplication doesn't have to be as bad as it might seem at first glance.
Large companies (and even ISPs) seem to be going for "IPv6-mostly" rollouts. Basically, everything is done primarily using IPv6, with fallbacks to IPv4 only when strictly necessary. This means IPv4 traffic gets converted to IPv6 at the client, forwarded over an IPv6-only network, and turned into "native" IPv4 for the internet at an edge NAT64 gateway. Legacy IPv4-only devices (printers and such) get an isolated vlan with its own gateway, and will of course be replaced with IPv6-capable alternatives as soon as it's appropriate.
I agree that for smaller companies it's relatively little benefit for the amount of work required, but if you're overhauling your network for other reasons anyways it makes little sense not to do it.
Yes, IPv6-first is definitely the way to do it. Just be careful not to run into Github's issue (https://www.githubstatus.com/incidents/5y8b8lsqbbyq) or Google's issue (https://i.imgur.com/4gGECJ9.png - in case you're not familiar, 2002:: is the 6to4 prefix, and 2002:a0 is the 6to4 version of 10/8, so I guess somehow I was deleting old users from within Google's own network!)
I’m sure this will annoy some people, but two hurdles for me in adopting ipV6 is, #1-it’s difficult/impossible to memorize the long v6 addresses versus the easy to remember ipv4 addresses (both public and private addresses I’m referring to).
#2-lack of knowledge/understanding of how V6 addresses route versus a fairly deep knowledge of V4 addresses route/subnets.
The basic idea is that whenever you find yourself memorising an IPv4 address, there's a failure somewhere. Possibly at policy and governance level.
Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
> The basic idea is that whenever you find yourself memorising an IPv4 address, there's a failure somewhere. Possibly at policy and governance level.
Sorry, but that's a load of manure. It's not just about memorizing.
People break their DNS so often that it's a meme.
Not everything automatically does a reverse lookup on every address it sees, and when it does rDNS could quite easily be broken.
So when you need to figure out if a device is in the same building as you, is it easier to say "1.2.3. - oh, that's my building" or "1234:5678:90ab:cdef:1234:5678:90ab:: - oh, that's my building"?
> Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
> Sorry, but that's a load of manure. It's not just about memorizing.
Ok, not just memorising. It's also the culture of cargo culted broken network designs, of excel spreadsheets from hell, of thinking everyone can memorise or put few post-its with IP addresses important to them so you don't need to care for DHCP and DNS or actually setting up routing instead of throwing a ton of NATed 10.0.0.0/8 or 192.168.0.0/24 then crying when there's a need to setup 5 layers of translation to connect two services (been there, done that, kept the scars).
As others pointed out, you should have anycast addresses for core network services (DNS at least).
IPv6 arguably even makes it easier because link-local automatic configuration actually works unlike v4 APIPA, well enough to discover and talk to other nodes on given L2. I still remember my happy surprise when HP ILOs used that to let me configure them over network by just connecting to same vlan, something I can't do on v4 without messing with DHCP rules.
The fact that link local actually works, combined with multicast and predefined multicast addresses like ff02::1 or the addresses for mDNS, DNS-SD, LLMNR etc mean that you can actually get somewhere without configuring IP on the link.
Do you need to learn new things, and possibly rearchitect the network? Sure. But it's because v4 was deficient.
Also, more often than not, the "it was DNS" involves "resolver not configured" or "put BS in DNS got BS back now crying".
> Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
Essentially entire promise of DirectAccess, the transparent VPN system added in Vista, depends on the office network being IPv6-clean (as in, no user-used services that require v4 connectivity). Originally it required IPv6+IPsec connectivity at client side, due to lack of wide availability various fallbacks were added in Windows 7.
It's also why Vista and later had such a push to autoconfigure Teredo and similar V6 transition technologies.
> So when you need to figure out if a device is in the same building as you, is it easier to say "1.2.3. - oh, that's my building" or "1234:5678:90ab:cdef:1234:5678:90ab:: - oh, that's my building"?
This is a very poor straw man.
In IPv6 world you wouldn’t use all the significant digits randomly and because you have so many you could actually use one of the octets to perfectly encode the building information:
Building 1: 2001:1::
Building 2: 2001:2::
(You can go further with this concept and encode region/country/state/etc into the addressing as required)
In IPv6 world you wouldn't get 2001::/112, you'd get 2001:1234:5678:90ab::/48. So your building might actually be at best something like 2001:1234:5678:90ab:1::.
That's for globally routable addresses, which you wouldn't get as nicely allocated in v4 either, if at all.
For equivalent of 10./8 space, you'd have ULA, which can be subdivided this way just fine (and arguably since fc00::/8 is left in limbo, you can use that. Or just decide to fit whatever addressing scheme you decide into 80 bits left after typical fd00::<48bit random>/48.
A similar issue is documentation. I wish more companies defaulted to IPv6-and-also-IPv4 examples rather than other way around. Or at least make them same importance rather than ignore/hide the v6 part.
This is one of my tricks when evaluating products going through some sort of transition from a legacy to a modern standard:
I mentally swap the labels[1] when reading their marketing or release notes. If it says things like "No longer crashes when using IPv6", then I flip that and read it as "No longer crashes when using IPv4". That latter statement is absolutely insane and would have you abandoning that vendor as fast as you can tear up the contract. Nobody bats an eye with the first statement! Why not!?
Azure literally had this scenario, where merely enabling IPv6 on one network would crash their managed PostegreSQL service on another peered network with no recourse other than rebuilding everything form scratch without IPv6 to roll the change back!
[1] Or a generic placeholder than encompasses both. E.g.: "Fix: Enabling the internet protocol no longer causes irreversible outages with your database service."
Yes, but its install base is still less than half of that of IPv4, and plenty of things that claim they support IPv6 don't do it properly. There are countries and industries where it is really entrenched, but in the majority of the networking world, IPv4 is the 100% guaranteed to work solution that all new applications and deployments first target, and IPv6 support is an after-thought at best.
Even Google, one of the champions of IPv6 adoption on the Internet, only started adding IPv6 support to GCP in the 2020s. In all public clouds, there are still numerous services that don't support it at all. And I can 100% guarantee that the next public cloud that anyone creates will start off with IPv4 support; maybe it will have IPv6 as well on day one, maybe not.
On the contrary, essentially all of the IPv4 public ranges have now been allocated. The incumbents have bought up what they can, leaving essentially nothing for new clouds to use. It's one type of moat, and the three biggest providers are happy to keep everyone on the far side of it.
A new cloud starting in 2025 onwards would likely be based on an IPv6 native design with IPv4 as the "add on" for public endpoints only, such as load balancers and proxies.
They'll still have 10.0.0.0/16 or 172.16.0.0/16 VPCs as the default, even if they can't buy a large enough chunk of IPv4s to easily give out public access through IPv4 (though they'll likely find some way to partner with some ISP that is switching massively to CGNAT and can free up most of the IPs they would normally give to their clients, or something).
IPv4 is far too ingrained to start with IPv6 only.
As far back as 2015 I tried to build an all-IPv6 network for a lab environment. It very nearly worked and the few remaining issues would have been quick fixes for vendors.
I'm not saying it can't work, I'm saying it's no one's first choice, even today. It's just extra risk, less usable (10.0.123.234 vs fd00:ec2::1234:5678), extra hassle (multiple IPs per NIC, extra hoops to access Github, etc).
I have to support ipv4. Why would I want to also support ipv6, increasing my risk and my workload.
If ipv6 had been designed form the start to allow seemless transparent access to ipv4 from an ipv6 only client that would be fine. But dual stack means twice the work and very little benefit (what services are ipv6 only, even today)
A good majority chunk of cell carriers today have gone IPv6-only for phones. They rely on NAT64 gateways (rather than CGNAT) to access IPv4-only resources. A lot of consumer internet is slowly following that lead as a better alternative to CGNAT. At least if your customers are consumers we are really close to "You might only need to serve IPv6."
(It's the "Enterprise-grade internet" that is interestingly lagging and falling behind in IPv6 adoption, and maybe doesn't see enough reason to support IPv6-only well; especially if the cost of IPv4 plateaus again, as some suggest it might. Recent AWS cost increases for IPv4 have been something of a call to action to some Corporations, but in general if you are B2B you probably need IPv4 support for a while longer as the economic incentives games play out on a long, slow horizon.)
Oh yeah, that definitely needs dual stack on the outside. You could do v6-only internally, but you should support everything you reasonably can for users, which 1. applies to a lot of the stack, ex. TLS and HTTP versions, and 2. can be more or less a freebie if you're using a CDN or the like (ex. cloudflare will do it for you). So yes, I was only thinking of client-side.
Thanks for the clarification. I was mainly thinking of server-side! :-)
On the client side there are apparently some subtleties about the DNS interaction if you want to literally have IPv6-only on the clients (as opposed to IPv4 CGN). If the clients do anything to not trust their ISP's view of DNS (like DNSSEC enforcement, or using DoH and an outside resolver), the ISP can't fool them into thinking that they should connect to an IPv6 address for a service that, from the point of view of the Internet as a whole, is actually IPv4-only.
> I thought it was possible to make a pure v6 network and use NAT64 as needed? I mean, we can argue if that counts, but I argue yes:)
Can I do "ssh 1.2.3.4" on a pure ipv6 stack yet? Last time I looked at ipv6 I couldn't even ping an ipv6 host by doing "ping 1234::5678", I had to run a separate tool (ping6)
The nat64 and vice versa should have been the play from the start. Want to host a sevice? Put in ipv6 only network, host it on 1234:5678::1, have your firewall with a public ipv4 address do the port forwarding, taking your public 12.34.56.78:1234 and natting it to 1234:5678::1.
Just the same as hosting your service on 192.168.0.1 and port forwarding.
But 20 years of dual stack and horrible cludges around changing public IPs later and many people still prefer ipv4.
> Last time I looked at ipv6 I couldn't even ping an ipv6 host by doing "ping 1234::5678", I had to run a separate tool (ping6)
IIRC, it's been over a decade since the "ping" command became able to understand both IPv4 and IPv6 addresses; it was only during the early adoption of IPv6 by userspace that we had separate commands for the new IPv6 stuff. Quoting https://www.man7.org/linux/man-pages/man8/ping.8.html "As of version s20150815, the ping6 binary doesn't exist anymore. It has been merged into ping. Creating a symlink named ping6 pointing to ping will result in the same functionality as before." So it seems it has been a long time since you last looked at IPv6.
Even with a working NAT64/DNS64 setup the PlayStation 5 doesn’t fully support IPv6 only connections. It will mostly work. Until it doesn’t. Xbox is in the same spot with some games. Don’t even get me started with my TVs or numerous IoT devices.
I ran IPv6 on xfinity. It works. My devices don’t. I like my devices. Easier to just not use it.
This is something that without some pain inflicted on host and network operators, the needle will not move. The CA/B Forum could start asking that it's a requirement for CA's to issue a certificate that the validation will try AAAA records first, and warn if they can't validate, then try A. Then later require validation through both AAAA and A records. This will prepare most of the hosts to make sure every page is accessible through both networks. Then require AAAA records only, and not bothering to check A records.
Let's Encrypt does try AAAA records first and then A. That's what leads to the phenomenon that I described where many people end up deciding to delete their AAAA records. :-(
I think Let's Encrypt's behavior is correct, and I don't think anyone inside Let's Encrypt or CA/B Forum would like to inflict "pain [...] on host and network operators" beyond the current practice. Let's Encrypt's current behavior could be described as cooperating with IPv6 adoption rather than compelling IPv6 adoption, which seems like a reasonable place for a certificate authority to be.
There are cases where Let's Encrypt has made choices that potentially slightly reduce compatibility in order to encourage what it considers technically correct behavior. The first one that comes to mind is
but I know there are others. On the other hand, all of those decisions can be justified in terms of improving the correctness of PKI software (like not hard-coding things that should not be hard-coded). I can't think of any example that's like "we wish this other technical thing would happen outside of the PKI, so we'll try to force it along", and I don't foresee the broader community getting comfortable with that.
The power that Lets Encrypt has over domain operators is limited. If it becomes a requirement by the CA/B Forum, then every CA would have instructions on how to make sure you have AAAA valid records and it won't be a matter that "LE doesn't work because they fail on this scenario". I'm a behavioral scientist (aka economist), and if you want the public to change behavior you have to motivate such change and here "pain" is defined as what is necessary to effect that change, by increasing the cognitive load.
There was a comment below that in the LE forums instead of asking people to fix their AAAA records, they ask them to remove it. That's exactly the behavior you don't want to reward, so you must cause pain.
I would love to use IPv6. Verizon's page on IPv6 has literally said "check back later" for a decade. At this point there needs to be taxation penalties applied to carriers that don't support it.
Odido (formerly T-Mobile) in The Netherlands is rolling out a huge glass fiber network, also to my house. They have an IPv4-only internet offering w/CGNAT. I'm really looking forward to fiber instead of my current DSL but really _not_ looking forward to CGNAT and no IPv6
>I'm also aware that there are other projections here; I recently interviewed a prominent Internet greybeard figure who theorized that Internet infrastructure growth as a whole has slowed so much that IPv4 demand may be satisfied in the future out of gradual conversion of residential ISPs to using primarily carrier-grade NAT for IPv4, and then selling off their number resources.
That is one projection, but it is also a very bleak view of the future. One that we should actively fight at any opportunity and at almost any cost. It will centralize the internet further and squash many attempts for alternative communications.
> It will centralize the internet further and squash many attempts for alternative communications.
Would it? It seems to me that a future where 1. every home land-line Internet connection is CGNATed; but 2. every cellular Internet connection is a public IPv6 prefix (as is already mostly the case today!); is actually a promising one. Provided, that is, that residential ISPs also get off their collective asses and provide the promised "hosted edge compute" capabilities they've been tinkering with for the last 10 years.
Since the Internet's inception, people on residential connections have been stuck in a broken mindset of "your home PC can act as a monolithic Internet peer — but only an unreliable one, that can't receive messages when it's shut off and is prone to being DDoSed — so you probably shouldn't actually use it as a server/p2p node, for anything other than, say, VoIP, or hosting an ephemeral multiplayer FPS game session. And you can tinker with a development web-server on your home network — but if you want to actually host anything, you should go pay a cloud provider."
Whereas, in a world with no well-Internet-connected home PCs providing the illusion of the possibility of hosting a home server, only instead:
1. home PCs — which can compute well, but can't be a network-ingress, and also might go down (often for laptops, less often for desktops, but both far more often than a real server would);
2. smartphones — which can network-ingress, but can't spend long periods computing (without burning all your battery life), and which will go down / out of wireless range extremely often; and
3. both commercial, and more importantly ISP-residential, edge-compute clusters — which would give tiny compute slices per workload, but ones with full network-ingress, and would never go down;
...then it'd be clear to all the people who had been thinking until that point that they could get away with p2p on home PCs using STUN/TURN-based protocols, that they would have to do something else; that operating systems (esp. mobile ones) and their client-server/p2p applications would have to evolve to become inherently edge-hybrid; that applications would need to evolve frameworks to embed persistent network-ingress "edge components" that could be shipped automatically and implicitly to the active network's associated edge deploy environment as part of the application's runtime; etc.
If you can't picture that: think about a web server backend that automatically deploys/updates an associated Cloudflare Worker whenever it boots up; and which then expects to be talked to through that Cloudflare Worker proxying requests to it; and where that Worker can also buffer requests, store data into its edge key-value store, etc.
But instead of a web server backend, it's the Minecraft app on your phone; and instead of Cloudflare, it's your residential ISP; and instead of the edge worker making a forward connection to your phone, your phone holds open an ngrok-like reverse connection to the edge worker to receive requests.
(Oh, and one other point of necessary evolution: that the "server component" of any p2p app would also be a mobile workload — not shiftable to the edge itself, but rather through the persistent edge workload to any [similarly reverse-connected, not always online] "compute host nodes" owned by the same user/organization. Such that you could buy a little NUC/NAS-like box to shove under your TV at home, whose marketed purpose would be compute+storage offload for the workloads launched on your phone; or such that your office could have some server racks for free auto-offload of "server components" of apps running on any employee machine — reversing the usual "cloud app with local client" relationship into "local app with sl...
As you say, residential ISPs used to provide additional services to their customers like web hosting, email, NNTP, shell access, time synch, IRC, mirrors of popular archives. They don't anymore - frequently, not even email. ISPs have clearly shown that they're not interested in being much more than the fastest dumb pipe around, because that's what their customers want, and I don't see that trend reversing.
To be clear, residential ISPs already do provide edge-compute hosting... for corporations.
When Netflix and others put CDNs "at the edge", they aren't doing that by building their own DC inside your city; nor by renting space in a random colo facility. Rather, they partner with each of the local regional ISPs, to put their CDN inside the ISP's "edge hosting DC" — a facility that almost all ISPs own (if not necessarily manage) at least one of in every city, precisely for the purpose of enabling such agreements.
So, unlike most Over-The-Top data services (which ISPs have long since lost the competency for), this one is something ISPs are actively doing. They're just not selling it B2C; their edge data-centers are currently a pure B2B play for them. But ISPs do know how to sell things B2C — so this would just be a question of them feeling enabled by product re-packaging to give this product line over to their B2C sales and marketing departments as something to charge their customers for.
"Re-packaging" this B2B colo into something they can sell to customers, would in turn just require the mobile OS vendors to step up and write code to make doing so an ops question rather than an R&D question — just as they did for visual voicemail, wi-fi calling, eSIM deployment, and so on. Essentially, Apple and Google would just need to provide their own server racks to ISPs, which host workload hypervisors for offload of workloads from "their" devices — in such a way that offload wouldn't be something customers would be paying Apple or Google a subscription fee for, but rather, as with Visual Voicemail, something where usage records from this system could feed into the ISP's usage-accounting systems, to be reduced into billing items by arbitrary ISP data-plan business rules.
---
And hopefully — but I'm not holding my breath — this would be done using open protocols and with FOSS-replicable software, such that eventually the ISPs could stop relying on Apple and Google to provide this only for specific devices, and instead could ask for their 3GPP hardware-integration vendor of choice to provide this as part of their 6/7/8G head-end system, in such a way that any device leased an IP by said head-end could make use of it.
What would such a standard look like?
Well, we're talking about a vendor-neutral, architecture-neutral abstract machine runtime, tuned to host persistent, network-mobile, IO-bound, highly-concurrent workloads "cheaply" on a highly-multitenant basis.
And Ericsson, one of the largest 3GPP equipment providers, created a runtime a few decades back that coincidentally fits that set of constraints quite closely — so closely, in fact, that they'd likely just vaguely wave at it and say "here, standardize this." (After giving its architecture a few security tweaks to achieve multitenant safety guarantees, that is.)
Just imagine: every mobile app on your iPhone, embedding its own little BEAM-bytecode relup package; one built by XCode, compiled from a combination of project source files written in a "network dialect" of Swift, plus Erlang library dependencies. And then pushed, on app launch, to a secure-multitentant Erlang VM sandbox, run by your ISP in its edge colo. Wouldn't that be just wild? ;)
If Google and/or Apple have gone to the trouble to build the network side of this edge-computing infrastructure, presumably it's because they think their customers will see enough benefit from this to buy more devices. But then why would they tie this to the customer's telco being on board? Apple/Google surely know how to run a data centre, and there doesn't seem to be much that couldn't be hosted just as well by them as by each telco; on the contrary, owing the network side of the stack is going to make it a lot easier for them to make performance, security etcetera guarantees. And of course it means all their customers can be on board on day 1.
On the telco side, as I understand it the CDN hosting isn't seen as a revenue centre - rather, it's there because it makes their pipe faster than the competition's (for the principle use cases of most of their customers, anyway).
> Apple/Google surely know how to run a data centre, and there doesn't seem to be much that couldn't be hosted just as well by them as by each telco
Because Apple/Google can only run so many data centers. And these DCs are all too high-latency / "out of the way" of the connection path between the user's device and the devices it wants to talk to, to make "diverting" the connection path to one of these DCs worth it.
Besides that, though — doing such "diversions" would massively increase cost, because it would turn a one-backbone-path (or sometimes even zero-backbone-path) route into a two-backbone-path route.
Apple/Google would have to pay for the bandwidth to connect the two users to their own network — where, in the case of a user running e.g. a BitTorrent seed-box, this is an unbounded downside risk! (Remember that by the design of such an "offload" system, it does not charge the customer for network traffic that transits through it — only for compute. Just like Cloudflare doesn't charge for basic proxying, only for Cloudflare Worker compute time. This will only ever make financial sense if your edge compute is "in" the existing connection path — i.e. hosted in the same DC as one of the path's existing hops.)
Now put yourself in Netflix's shoes. You don't want to deal with residential ISPs; they're usually large conglomerates that have more bargaining power than a random commercial colo facility in a city would have. But you do anyway. Why? Because, by doing so, you get a connection to the ISP's customers that is:
- extremely low latency
- extremely low bandwidth cost (because there's no need to traverse a backbone for any hop — the CDN's data can stay on the un-congested "residential streets" of the ISP, without ever needing to get on the "highway" where it would have to fan in and wait on an "on-ramp")
- never-degraded QoS — because their traffic on the residential ISP's network is just delivered with a default priority class (like everything else on that network, other than maybe the residential ISP's own OTT VoIP-based POTS service); whereas, when traversing any backbone, other providers who were willing to pay more per byte (because they had far fewer bytes to send and valued them more — which is basically every provider compared to a movie streaming service) get higher priority classes, narrowing the virtual pipe [= re-allocating to fewer circuits on circuit-TDMI backbone routers] and so degrading service for the CDNs whenever other higher-priority-rate traffic wants to flow.
The argument for Apple/Google putting their edge compute offload into residential ISP DCs would be exactly the same. It takes a network path that the customer was already establishing anyway, and adds a place for a "user-programmable virtual router" to live in that network path — without lengthening the path, making QoS worse, or any of that.
---
But let's go at this another way: if the cost/benefit worked out in favor of Apple/Google doing this in their own DCs... then why wouldn't they have already offered this years ago?
Apple might not be a B2B cloud provider that has hypervisor clusters ready for customer use — but Google certainly is. Why isn't "Android Offload Services, powered by Google Cloud Run on ARM" a thing?
What I said above (doing so creating a network "diversion", doubling backbone connections, wrecking QoS, etc) still applies.
I fundamentally disagree with most of your points.
It might work for a usecase you have in mind but in general, it can't work. And it assumes that the world is a perfect place where the incentives are aligned and that ISPs cooperates and that you'd actually want to expose your phone. As if the tech we have (mobile networks, phone batteries, coverage) would allow for it, which it don't.
And somehow denial of service attacks is only worth mentioning when you have a dedicated PC with proper 100+mbit internet but not when you have a battery powered phone with wireless connection?
And I truly fail to see how all anyone could even argue that all that complexity would be better than direct access.
You’ll never get serious discussions about this unless you talk about how this IP block will be distributed if it became unicast space. Otherwise this is no different than the other 10 times this has been proposed.
The main issue has always been the logistics of defining a brand new allocation policy that won’t run out of IPs in 6 months, because otherwise nobody is going to bother spending a bunch of money to support an address block which will most likely not even work anyways.
I'm all for reclaiming 240/4 eventually, if it can be reliably used. But I saw a mention in the article of 0/8 and 127/8, and I hope those never get changed. There are too many systems out there with assumptions about those addresses, and unlike 240/4 where the failure mode is "can't reach the host", for 0/8 and 127/8 the failure mode has security implications.
I've previously talked about opening this space up (sometimes here [1]) in similar light to how Ben does in regards to it (more or less) being "an extra source of pain" rather than a solution to anything. My opinion has been the same through multiple proposals for this, though some have had minor differences to considers. There are two main reasons I believe this across all of them:
The first is, particularly on opening it up for public assignment, all of the compatibility issues mentioned. It's not enough that in 2035 99% of things could be compatible when talking about existing internet infrastructure - it has to be 100% going to work (without hoping everyone just catches up, this isn't a separate internet like IPv6's rollout is) if you want to bet interoperability of the established internet on it. The alternative is let people use it but not on the internet, that way they own their own interoperability with themselves or anyone directly interacting with their internal network. If this were a security issue I'd have different feelings on it but it's about convenience so it isn't enough that it's possibly more convenient to most 10 years from now. Especially since the problem and solutions will have evolved so much 10 years from now anyways.
The second reason is, even if it does work out 100%, it's not much a solution to anything anyways. IPv4 pressure has started causing places with large blocks of old IPv4 space moving to NAT, carries deploying double NAT via CG-NAT, cloud providers looking at public IPv4 address fees, and the entire mobile world being IPv6 first with some going as far as IPv6 only with NAT64. Each one of these solutions already in place has resulted in more usable IP space than this would open up so this solution could neither replace them or stop them from being needed in the future. Each existing alternative (however non-ideal) is either a longer term mitigation or step towards a long term solution to the shortage instead of a small basket of addresses to throw on the fire. In particular the NAT64 and 464xlat solution have proven to be a long term permanent answer for the vast majority of the cases people thought they needed these kinds of addresses for that would have left them less prepared when these too ran out. I particularly don't buy the idea that the world just so happens to need exactly a /4 more of space and everything would be alright - it only looks that way because of the above methods being pressured into happening. Remove that pressure and it (at best) can hope to delay the rollout numbers of those methods by a decade.
All that said I'm still in support of opening it up for private use cases like enabling 0.0.0.0/8 in Linux [2] did (think use cases like another /8 of space you can slap your Docker container NATs behind or your HA networks behind for software that doesn't support v6). Not only do I think that would result in less pain for the internet at large I think it would actually result in a larger decrease in IPv4 pressure long term by giving more spaces to NAT to/from for those not ready/able to NAT64 all of their internal services.
Not to mention public cloud providers dragging their feet on implementing basic IPv6 functionality as if it was some sort of obscure feature instead of… the Internet protocol for the last two decades.
All the cloud providers I rent services from offer IPv6. It's only the really big ones that seem to be dragging their feet.
I suppose the multi-AZ stuff makes things more complicated, but my $5 VPS host had IPv6 like what, ten years ago?
This does have one small benefit: since none of the large cloud providers seem to do competent IPv6, you can avoid scanners, scrapers, and other log polluters on personal services by just hosting them on IPv6.
> Is anyone aware of why those decisions not to adopt IPv6 were made?
Because they have all the IPv4 address they need and so do not see a shortage, unlike those that are not mega-corps and are struggling:
> I work for a Native American tribe in the PNW. We scrambled to get the reservation reliable internet in the later part of 2019. We managed to cover most of the reservation with wi-max and wifi with a fiber back haul configuration. We are now slowly getting more stable and reliable fiber to the home(FttH) service installed to as many homes as we can, but it is slow process covering the mostly rural landscape doing all the work in house.
[…]
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
To this day I maintain that a large part of IPv4 space wastage is due to the HTTP WG's longtime avoidance of adopting SRV or SRV-like DNS records or even the DNS itself as normative for HTTP/HTTPS, instead allowing the HTTP RFCs to just vaguely suggest that DNS might be one way to resolve the IP address of origin servers, whilst in practice squatting on the A (address) record like they owned it (and worse, all the apex records). Consequently inspiring a vast chorus of LIRs applying for /19 allocations over the years "for SSL hosting" and continuing to do so long past the introduction of SNI (RFC 3546). Saw this behaviour firsthand as a European LIR operator with friends at RIPE. Is it cracked down on now? Yes. Are there whole swathes of IPv4 space that remain unassigned or entirely unannounced? Yes. Does every large-scale DNS hosting service have some hackish way to workaround the prohibition of CNAME records at the zone apex? They sure do, and HTTP is why.
Paul Vixie saw it coming, the very first example in the original SRV proposal (RFC 2052, 1996) is resolution of HTTP. Alas that this example was omitted in later editions. The new SVCB/HTTPS RRs (RFC 9460, 2024) are literally decades overdue.
For years a combination of gaps in policy, disjointed standards development, hoarding behaviour, and administrative laxity, led to substantial wastage of IPv4 address space that persists to this day, in part because multiple independent website tenants sharing an IP address was (and often still is) difficult.
Glossary
DNS: Domain Name System, how computers discover (or resolve) each other's numeric IP addresses from symbolic hierarchical names.
HTTP WG: HTTP Working Group, the standards committee(s) responsible for defining the application-layer protocols by which a web browser talks to a web server. Under the auspices of the IETF.
IETF: Internet Engineering Task Force, the standards organization for the Internet. Most famous for being the entity that publishes TCP/IP and the cherries on top.
LIR: Local Internet Registry, an entity that applies to be the holder of block-allocated IP address space. Typically ISPs and hosting companies that assign it for their use or onward customer use.
RIPE: The European peak body, a Regional Internet Registry (RIR), responsible for (amongst many other things) allocating IP space to the LIRs, ultimately under license from the global steward IANA. Sibling of ARIN, LACNIC, AFRINIC, APNIC (North & South America, Africa, Asia-Pacific respectively).
SNI: Server Name Identification. Before SNI was introduced to SSL/TLS, the only way to tell which HTTPS origin was being requested, was by server IP address.
SRV: A specific type of record in the DNS that allows lookup of a service (e.g. IMAP mail, XMPP messaging, LDAP directories) for a given domain name, to return a set of hostname(s) that actually provide that service, and the ports on which it is available. This enables multi-tenant services on shared IP addresses and thereby conserves IP space.
/19 network prefix: A large chunk of IPv4 address space, corresponding to 8192 unique IPv4 addresses. Refers to the first 19 bits of the block of (32 bit) IPv4 addresses being allocated. Back in the 90s a /19 was a common granularity of allocation from RIR to LIR and could be granted with a low bar to justification. Mathematically, 2^(32-19) = 8192.
Address record: A specific type of record in the DNS that maps a hostname to an IP address. Technically referred to as an "A record" for IPv4 addresses, or an "AAAA" record for IPv6 addresses which are literally 4x the binary length.
Allocation, Assignment, and Announcement: IP address space is allocated in blocks by RIRs to LIRs, who then assign smaller parcels of it to specific purposes such as retail hosting and internet access, and announce it at internet exchanges and to their peers for actual traffic exchange. Very often, the quantity of assignment failed to justify a large allocation, leaving space unassigned i.e. unused, and in some cases unannounced, but still hoarded, with incentives for hoarding becoming perversely stronger as the addresses ran out and the policy screws started to tighten ca.2005-2011.
Apex: in "example.com" it is the "example.com" rather than "www.example.com". For marketing purposes, almost every entity wants their zone apex to be directly reachable as a website, which means placing an address record at the apex. This excludes using the apex address record for any other service but HTTP, which I have always regarded as downright antisocial. Since alias records (a.k.a CNAME records) aren't permitted at the apex, it also makes DNS management harder when you have frequent changes to make, as in the highly dynamic world of cloud-based services, or even just want to point your website at a third party hosting service without having to edit your zones whenever their IP addresses change.
Normative: A formal declaration in one technical standard (e.g. SMTP) that it depends in whole or in part on another standard (e.g. DNS) for full specification. It is unusual for a TCP/IP-based IETF protocol standard to omit DNS as norma...
Thanks for this. It seems the parent comment put maximum acronyms with zero information for people who are on the same wavelength / plane of existence.
Ha, seeing the list of jargon being defined was eye opening - I understood everything without a second glance but, like you I assume, I've been exposed to this world for 25+ years as this point and its second nature.
I remember the first time I used "characters" in front of a non-technical friend instead of just the more common "letters" or literally anything else.
I think "octets" is at this point historical jargon with little present value. It dates back to the day when some vendors were fighting for non-8-bit bytes. Those systems are long dead, and "byte" means "8 bits". Given that, I don't know of any context in which "octet" is an important distinction rather than an obfuscation.
Still makes a little sense as IPv4 addresses are 32 bytes and we break them down into 4 parts of 8 bits each. No one ever uses the 32 byte number, which will resolve.
On second thought I take disagreement with defining a byte as 8 bits. I would say its de facto 8 these days but not always and has always been hardware-dependent. If I give you a random page of documentation from the last 70 years of computer history and it's talking about a byte, you have no idea if that means 5 bits or 12 or anything else.... which is why I think octet is useful here as it _always_ means 8 bits and always will.
There's a reasonable distinction between "term useful to understand historical documentation" and "term useful to use in new documentation/communication". No new system or protocol or piece of documentation should ever use non-8-bit bytes. If you're reading old protocol documentation, you get used to "octet" being used in place of "byte"; that doesn't mean new documentation should cater to systems that haven't existed for a long time.
(Also, this tangent really isn't worth spending time on.)
Yet we seem to have all agreed to use octet, even for new documentation. I browsed the recent RFC submissions and had to stop looking as pretty much every one I checked that was posted this year uses octet. A few examples...
Characters is a pretty poor term these days, since it can refer to any of bytes, code points, extended grapheme clusters, or possibly more I haven't thought of.
> Since alias records (a.k.a CNAME records) aren't permitted at the apex...
Technically this is a subset of the rule that CNAME ("canonical") records cannot co-exist with any other record type with the same label. e.g. it's illegal to have `foo.example.com` be both a CNAME and an A record. Since an SOA record is required at the zone apex, you can't also have a CNAME record there. :-(
That it was historically "more difficult" to have more than one website per IP address particularly if it was using SSL because doing that needed amendments/extensions to DNS and other specs.
We now have it, but still need to use a hack to cname an apex e.g set Google.com to bah-bahs-tenant100.s3.amazon.com. Adhering to the spec we need to set google.com to an ip address e.g 8.8.4.4
Right now if you want to retrieve http://www.example.com, you have to ask DNS for the IP address of www.example.com. HTTP can multiplex multiple sites on a single IP address so you can make DNS answer with a "CNAME", i.e. let it give another hostname which could be from Cloudflare and will actually do the serving. However http://example.com cannot use CNAME because it is an apex record (historical limitation that's hard to lift and is worked around in many different ways by providers). And this caused many websites to occupy an IP address unnecessarily.
Likewise for HTTPS, though in that case multiplexing arrived only maybe 10-15 years ago instead of 25.
A proposed Internet "standard" suggested that instead you would do a different kind of query, not a query for the IP address but one for a "server". It's a kind of query that is very underused on the Internet but it's related to how you find printers on a local network for example. In that case you would do this kind of query (called SRV) for http.tcp. example.com and that would always be able to return another hostname, thus getting rid of the issue with apex domains.
> In that case you would do this kind of query (called SRV) for http.tcp. example.com
You’re forgetting the underscores: It’s actually “_http._tcp.example.com”. The underscores are there to avoid any possibility of collisions with host names, since host names are not allowed to contain underscores, but are generally allowed in the DNS.
> However http://example.com cannot use CNAME because it is an apex record [snip]. And this caused many websites to occupy an IP address unnecessarily.
That's not true. I have an server with a single IP and a number of Domains that are served from that single IP like http(s)://example.com http(s)://example.org http(s)://example.de
All of those delivery completely different websites from that single domain. You are mixing up two tings: DNS with HTTP(s). In DNS its right but for HTTP(s) it doesn't matter.
Of course you can have multiple apex A records that point to the same IP address. We are talking about CNAME records here. Are your sites using CNAME records or A records?
Even if you are using CNAMEs, that's only been possible recently due to hacks/workarounds, as bonzini said.
I'm imagining, but someone please correct me if I'm wrong, that this is related to the policy/standard/convention (?) that IPs have a single canonical name, so reverse and forward match. I've never really followed that strictly, though I've been aware of it and try to follow it as I can, because it makes management of DNS a little more sane.
Because of no SRV records for HTTP and no CNAME for apex records, you can't follow
"one true name per IP" without giving an IP to every domain.
Actually reverse and forward match is important for SMTP these days. It is one piece in the puzzle to detect spam.
I run may own email server now for more than 20 years. Only recently I in-cooperated public RBLs to deny spam. I still don't like it to depend on external services for this, which flag spam incorrectly.
I had excluded SMTP in my thinking because SMTP has the MX records, so it doesn't run into the issue with apex records not allowing CNAMEs. If I'm mailing you at pinguts@example.com, it does not require a dedicated IP for example.com, your MX record can inform my server that SMTP needs to connect to smtp.example.net, and that needs to have matching forward/reverse, but I can have a hundred domains that all specify smtp.example.net without interfering with the apex-can't-have-CNAME rule.
I think this is what people elsewhere were referring to when they said that SRV records would be nice for HTTP.
edit: Aside: I ran my own first mail server over 30 years ago. :-)
I'm talking purely about DNS, and in fact I wrote explicitly that "HTTP can multiplex multiple sites on a single IP address", because the problem exists only at the DNS level.
A compounding issue is that CDNs (or GitLab/GitHub) want to be able to change their IP addresses, so they don't want you to use an A record.
To be precise, SRV records don't immediately return an IP address; they return canonical name(s) (i.e. FQDN of hosts) whose IP addresses can either be included in the additional part of the DNS reply or resolved separately.
In addition to canonical name & port number they also include priority & weighting values, although the usefulness of these depends on the service.
SRV might not be super visible in the application developer's lane, but swim outside and there's a lot of it about. It's foundational for SIP, for example (IP telephony). Email remains a tremendously significant internet utility and SRV is used, albeit not universally, for discovery of client endpoints (SMTP submission, IMAP, CalDAV etc). However, SRV hasn't replaced MX for SMTP between MTAs, perhaps because MX already does basically the same and was established years prior. And, well, Jabber is dead, but XMPP was another fully worked demonstration of SRV's capability.
In more local environments SRV is used for resolution/discovery in Active Directory (Microsoft) and Bonjour (Apple) - if you listen to the wire on any local network you'll often see a ton of SRV over mDNS or DNS-SD. Perhaps ironically, one of the objections that sometimes arose to using SRV for HTTP was from Active Directory sites with zone cuts at _tcp.example.com and facing additional complexity in any transition.
I never understand the reasoning behind the design decision that SRV cannot just return IP address and forcing clients to query again for A/AAAA again. That decision forces an extra RTT before connection can be established, which makes people want to avoid SRV records. Totally self-inflicted wounds.
I feel like this is a drop in the bucket. Compared to the number of clients, the amount of HTTP servers on the internet (probably no more than a couple million if I had to guess) feels like it takes up a small fraction of the IPv4 address space.
The SVCB/HTTPS records won't save us, because of the same reason TLS 1.3 pretends to be TLS 1.2: middleboxes everywhere have been configured to only let traffic to port 80 and 443 through. Almost everyone is running an HTTP 1.1 server so there's completely transparent fallback for those networks, but it also means those records are kind of pointless.
I never really got the point of the new records either. From what I can tell, they're just SRV records. A separate record class could've made sense with DANE, but nobody implemented it.
> middleboxes everywhere have been configured to only let traffic to port 80 and 443 through
They are not everywhere though. They are not on the greater Internet. They are not on residential networks. I have access to the full 65535 TCP ports everywhere in the world on my average Internet connection.
These middleboxes you speak of are appliances paid for and placed inside of corporate LANs. They can pay to put more modern ones, or just getting rid of them.
The point is that these middleware appliances we often use as a scapegoat exist only in well-controlled private networks. Why should we care about them?
>The point is that these middleware appliances we often use as a scapegoat exist only in well-controlled private networks. Why should we care about them?
Perhaps for the same reason we only stopped caring about IE 6 after its usage dropped below a tiny percentage.
For better or worse, making your website available to as many groups of people as possible, regardless of their browser selection or network configuration, has been a long-standing goal in the community.
If your website isn't available to folks at the offices of company X because they use appliance Y, through no fault of user Z's, well...that's not ideal, is it?
Or they could be ignored so that the users drag their IT kicking and screaming into the 21st century once an important enough site necessitates it. Corporate users usually have more direct influence on their IT than ISP customers.
I concur. Corporate LANs are to the internet as VMs are to servers. Trunking, VLANs, and NAT have so completely decoupled these networks from underlying infrastructure that the transport protocol itself is little more than an implementation detail. IPv4 remains king because it is well-known and cheap -- the fact that we all settled on using the same interoperable protocol for both LANs and the internet was never a foregone conclusion.
If this proposal is accepted, it will make it less likely that people will simply continue to steal random unoccupied and/or unimportant ranges of addresses and reuse them for their own purposes, which in turn would make IPv4 interconnectivity more and more uncertain, which would probably drive IPv6 adoption… Hey, wait a minute… I’m suddenly not convinced this is a good idea in the long run.
I was surprised to find that back when I went to college, every computer connected to their network, whether it be the laptops that each student had via the required technology package, and even personal desktop computers and gaming consoles and every device connected to the network in the dorms, every machine was given a public facing IP address without NAT.
Even your phone or tablet on the campus wifi got a unique public IP...
Of course there were firewalls in place and all the incoming ports were blocked, but doesn't that seem like a big waste of IPs?
The university owns 155.92.0.0/16 and every machine on the network gets a 155.92.x.x IP address.
Sure, but should a school even be given all those IPs to be used like that?
Seems like a waste to me to have it where every device on the campus network gets a public IP, like every students phone, laptop, tablet, desktop, game console, etc.
Why should every individual person have their own physical mailing address? Couldn’t they just get their paper mail at their workplace? Or is it a vital component of democracy and individual freedom that people can recieve mail and other missives independent of their workplace’s curious eyes and sufferance?
Or voting. Should really everybody get a vote? Most people don’t really need to vote. This is evidenced by the huge numbers of people who don’t vote. And most people who do vote do it badly, anyway.
This is at least partly historical. Early adopters got allocated IP space before it was apparent that it would be scarce. I seem to recall that MIT has an entire class A. I think the US military had a whole pile of class As as well. I haven’t kept up with this layer so I don’t know whether any of this has been returned to ease allocation woes, but I doubt it.
As I recall, people have figured that at the speed which IPv4 addresses were given out (before they ran out), even if all possible unused addresses were reclaimed (which would be a huge pain to do), it would last at most, IIRC, a few months more. So it would help some, but would not really be worth it.
352 comments
[ 4.8 ms ] story [ 288 ms ] thread> If we are going to start using address space that might not work for all users, it would be wise to pick the address space that we already have a considerable head start on getting accepted: IPv6.
In the other hand, IPv6 is already used by nearly half of internet, and probably most installed infrastructure supports it. And it have a lot of advantages over IPv4, starting with not having to use NAT.
1.x.x.x.x will be for legacy stuff. If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved.
edit: I realised people don't see the big picture here.
Step 1) We collectively engineer and deploy ipv8, along with RFCs explaining how future expansion works
2) We put all sorts of preparatory work, conversation into the eventual expansion into 6 octlets, from 5. We'll need that once we colonize multiple systems.
3) The RFC will state that "new planetary systems get space on 5th oclet, 1.200.x.x.x.x to 1.250.x.x.x.x.
4) As systems grow to need more than an ipv4 range, we transition them to their own 6th oclet. It's easy for them, because they can retain legacy 5th octlet headers.
5) We then collectively freeze our brains, so that in the future, once interplanetary, faster than light communication exists, we are thawed to deal with the 5 to 6 oclet transition!
And we all become immortal.
But no, that's fine, think small, stay non-immortal with your ipv6 Flanders!
Only for unidirectional UDP.
How do you think the other side would be able to respond if it's unaware of the 5th octlet? Basically every protocol in existence requires two-way communication and there's no backward compatible way of providing that.
Internally, an IP is just a 32bit number. Adding another octet is adding another 8bits to the number. IPv6 merely expands that number to a 128bit number.
If you do the math of say converting 8.8.8.8 to 8256^3 + 8256^2 + 8256^1 + 8256^0 and ping the resulting number, it will work.
If that's all IPv6 did that would have been one thing. ipv6 changed tons of things, from arp to nat, dhcp to dns.
And DHCPv6 isn't needed for logging/audit: the router always has an association of MAC addresses and IPv6 addresses even if hosts assign their own addresses with SLAAC.
Which is absolutely ridiculous. Google should not be trying to dictate to their customers how to run infrastructure. If someone wants to use stateful DHCPv6 for their Android devices, that is their right and Google has no business standing in their way.
And by having a just more bits for the address - be incompatible with IPv4.
DNS is IP^W address protocol agnostic, by the way. If you really need you can run it on IPX/SPX.
DHCP is just a lack of the autoconfiguration in IPv4. No thanks. Nor APIPA, nor DHCP with the same 192.168.0.1/24 everywhere solve that properly like in v6. Sure there were some nuances in the begging (like the inability to provide the DNS servers addresses at the beginning) but they were solved 15 years ago.
As it is, virtually everything about networking is different in the IPv6 world. That has significantly complicated adoption for everyone, arguably needlessly. And not everyone who says they support IPv6 even actually supports everything that the designers expect (e.g. lots of ISPs give you a /64 or even a /128 for your whole network).
Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
By 2005 all the major 'software' (read: general purpose network operating systems) had the software for IPv6 already.
If your application is hardcoded to use IPv4 addresses then you need to rewrite it anyway and no amount of IPv5 would change that.
More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work.
But the most important part here is what were (and I can bet my pumpkin latte - still are) incapable of anything of not IPv4 - because it's the hardware, which routed, NATed, checksummed all that traffic.
You just couldn't slap your IPv5 there by exactly the same reason you couldn't slap IPv6 there - you needed to replace the hardware.
> As it is, virtually everything about networking is different in the IPv6 world
Sorry, but no.
The basics, ie the networking, is exactly the same. Yes, there are some nuances, like using link-local addresses for the gateways, which absolutely, totally, makes sense after a 15 minute reading. But overall it's just another technology, not harder then everything else out there, including IPv4 itself.
> That has significantly complicated adoption for everyone, arguably needlessly
sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. Every year there is something new and you need to learn it[0]. Sometimes to abandon and forget it after a couple of years.[1] IPv6 is not a rocket-neuroscience, just another set of RFC's and guides. If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.[2]
> And not everyone who says they support IPv6 even actually supports everything that the designers expect
Now you argue what with 'IPv5' this wouldn't happen.
> Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
I wrote about it - it's the problem of the software. I had multiple IPv4 addresses on the same interface many, many times. If that software breaks with multiple IPv6 addresses on the one interface then it would break the same with mulltiple addresses of IPv4 and 'IPv5'.
PS I have a small fleet of PowerConnect 5500 and 8000 switches. They are old, so old 5500 has SSH bolted onto a Telnet server. Yet they did already support IPv6 by 2010. It's already passed more years since the release of 8000 (2010 - 2024) than between IPv6 IETF proposal and release of 8000 (1998 - 2010).
Slow adoption has nothing to do with IPv6 itself, and no IPv5 or whatever would made it faster.
[0] if anything it's slower now
[1] MS Exchange for example. Do you know X.400? I do not, anymore. But for some years I needed to know and I learned it.
[2] Take this from someone who did and does both.
This is only true if you use DNS for every network request. That has never been realistic for any home network.
> sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286.
This attitude is part of why many people love IPv6 evangelism.
> If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.
"Easier than IPSec" is not exactly a ringing endorsement.
And note that IPv6 doesn't replace any of this. You still need to know the IPv4 way, and the IPv6 way, and IPSec in both flavors etc.
Sure, it's not neuroscience, but it is needlessly more work, and most people like to not fuss with more work if they can avoid it. Especially when it's entirely duplicated, since, again, you can't drop IPv4 support, you still need to do CGNAT and all that, and then add IPv6 management on top.
And I know what I am talking about: I am one of them :)
People who fails to adapt because "it is new" has no place in IT. The only skill required to work in IT is a great ability to adapt.
If IPv6 were a simple replacement for all things IPv4, and you simply had to learn IPv6 instead of IPv4, no one would complain.
But you need to learn IPv6 in addition to IPv4, in almost all areas of networking. The complexity adds up, it isn't replaced.
And I still manage ipsec tunnels and NAT and I still have to know things about OSPF, even tho I learned BGP more than 10 years ago
In the real world, you cannot simply replace things in the blink of a eye. This is not possible unless you are working in your own, fully-managed environment, never talking to other people (which is a good but scarse position)
So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers.
Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address.
Old IPv4 hosts wouldn't be able to talk to IPv6 endpoints, but at least this way the user could upgrade their own stack without having to wait for their ISP, and every network in between, to also upgrade.
It's pretty much carrier grade NAT but from client to client without ISP support being necessary, which is the biggest bottleneck right now.
I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.
How does the IPv4 person craft the reply back to the not-IPv4 source?
And more importantly it means that if a client wants to interact with IPv6, they only have to upgrade their client, and not wait for everyone in between to upgrade too.
(There's also the interesting question of how not-IPv4 addresses are supposed to get their not-IPv4 addresses if the entity they get their IP addresses from doesn't support not-IPv4.)
(If you're going to say "not-IPv4 local network with IPv4 ISP", then clearly explain how the not-IPv4 local network is supposed to get its not-IPv4 address, and why that is materially different from existing IPv6 tunnel options.)
So:
* https://en.wikipedia.org/wiki/Teredo_tunneling
* https://en.wikipedia.org/wiki/6in4
* https://en.wikipedia.org/wiki/ISATAP
You can sign up for an IPv6 connection, without any IPv6 support from your ISP, via Hurricane Electric's tunnel service:
* https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup
* https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunn...
It's been around for at least a decade:
* https://www.internetsociety.org/blog/2014/01/weekend-project...
Any 'expanded IPv4 address' solution will (have) face the same problems that IPv6 has faced, and the solutions will end up being the same: having to slowly upgrade the network stack (hosts, routers, firewalls, ASICs), changes in networking system calls and associated structs (because the number of bits), gateways and transitions mechanisms, expansion of related protocols (DNS A records are only 32-bits, so a new record type needs to be supports (e.g., AAAA for IPv6, AAAAAA for your new proposal)).
If you want to argue that we should have (say) kept ARP instead of moving NDP, sure.
But anything to do with expanded addressing would be the exact situation: code upgrades and transition mechanisms.
I just logged into tunnelbroker.net to check: my HE account has been registered November 22, 2010 11:30:00 UTC. Today it's unused because IPv6 is basically always available in France.
That's not even the first time I tried IPv6 things, part of it being I had some access to RENATER via my engineering school, right when they kicked off IPv6 around 2002.
The past 10 years of IPv6 have been largely uneventful for me: it just works.
Yeah, ditto. Except that it has been more like twenty than ten for me.
From my he.net tunnel, to (several years later) my Comcast-provided native IPv6 service, to IPv6 on my phone, to IPv6 with my local ISP (once I switched off of Comcast/NBCUniversal) it has been so very, very boring and reliable for so many years.
I moved away about 13 months ago.
(Worse yet their modem/router did RAs or whatever but there was no connectivity out)
The past 10 years of IPv6 have been largely uneventful for me: it just doesn't work.
IPv6 worked "too well" for me: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away.
Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML.
And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again.
We switched ISPs so we could get better than 6/.768Mbps DSL w/60ms ping. Now we are on 15/2 fixed wireless w/20ms ping and CGNAT.
In your scheme, any IPv4 address is automatically expanded into an IPv6 gateway address, since there is no other way to map that partial addresses together. So, for every /32 of space you want to add, you have to get another IPv4 and use it as a gateway.
It's also going to be a massive amount of fun doing "second level CIDR" on those gateways.
You've just turned CGNAT inside out to no real benefit.
No You'd need a full rewrite at the parser level
As everybody said : ipv4 cannot be made compatible with larger addr space
For our users, it doesn't matter if it's IPv4 or IPv6 - they can reach it, and it can reach them.
[1] https://blog.ipv6.rs/ipv4-activated-via-nat64/
[2] https://github.com/ipv6rslimited/delorean
[3] https://github.com/ipv6rslimited/legacydns
IPv6 didn't only impact networking devices, it affected end-user applications that interact with the network in many ways, and this is a big part of the slow adoption.
1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere.
2) if we're already replacing everything, make stuff better
We chose #2, with varying degrees of what is "better".
AFAIU it was "just" defining an option type; the IPv4 packet header itself didn't even need to be changed.
1993 was more than 30 years ago.
So people who wanted to keep it backwards-compatible with IPv4 already had a chance.
* https://en.wikipedia.org/wiki/Happy_Eyeballs
And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized:
Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6).IPv7 would have had the exact same issues that IPv6 had with rollout.
There is no "just" when trying to expand a fixed-size data structure across the entire planet.
The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet?
Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations.
IPv7 on the other side, had absolutely different philosophy:
this would get things converted much faster.Okay: so given that gethostbyname(3) only dealt with struct hostent with type of AF_INET:
* https://pubs.opengroup.org/onlinepubs/000095399/functions/ge...
* https://www.akkadia.org/drepper/userapi-ipv6.html
Those had to be rewritten to support AF_INET6 and use use that new address type. See also changing all socket(2) calls.
* https://datatracker.ietf.org/doc/html/rfc3493
* https://datatracker.ietf.org/doc/html/rfc4038
Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6.
> The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet?
Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?")
IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds.
Meanwhile those folks that weren't fortunate enough to around for the early IPv4 address land grab are struggling with shortages:
* https://community.roku.com/t5/Features-settings-updates/It-s...
* https://news.ycombinator.com/item?id=35047624
> IPv7 on the other side, had absolutely different philosophy:
All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition):
*And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users?
I think the problem with IPv6 is a decision to redo all the management methodology. Your RFC 1726 illustrates it well: there is only one brief mention of backward compatibility in 5.5, listed as "optional" feature, and whole sections about changing the protocol in incompatible way, including 5.8 which starts with:
They fixed it indeed! Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes. Certainly possible, but nowhere close to "plug device in and it gets stable IPv4 address which is unlikely to ever change".The difficulties encountered with IPv6 would have been the same even if another proposal would have been chosen for IPng because the exact same thing would have needed to be done: new address type for syscalls, new data structures, new surrounding infrastructure.
When your original standards do not allow for address length changes/flexibility, you have to write a new standard with the new address size, and there's no way to stuff >32 bits of data (addresses) into a 32-bit field. IPng would always have been a breaking change, regardless of proposed candidate chosen.
And if you're not going to have a flag day (à la NCP-IP changeover), then you'll need transition mechanisms with tunnels for sparse dispersal between IPng islands in a sea of IPv4.
> And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users?
All the proposals for IPng needed to have the same things done. "Technical Criteria for Choosing IP The Next Generation (IPng)":
* https://datatracker.ietf.org/doc/html/rfc1726
New packet type/header, new API options, new records and data structures for DNS, transition mechanisms (tunnelling). All this needs to be rolled out to hosts, routers, firewalls, ASICs, etc.
All the while IPv4 would continued to be used, so what incentive would business and IT departments have had to move to TUBA or TP/IX-CATNIP? ("Our (IPv4) network works, why do we need IPv7?")
> Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes.
Before recently moving ISPs (to go from DSL to GPON) I had IPv6 for several years on the old one and all my hosts (cabled, Wifi), phones, printers, etc, had IPv6 addresses given out by RA by my Asus, and I had no issues.
In fact IPv6 worked "too well" for me at one point: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away.
Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML.
And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again.
The IPX/SPX and DECnet folks managed to learn IPv4, so I'm not sure why the IPv4 folks have such a hard time with IPv6. IPv6 is no more difficult a Layer 3 protocol than IPv4.
And there's a lot of software that never got corrected, that explodes when it reads an address that isn't IPv4 even if uses a more modern API.
Meanwhile IPv4 was supposed to be sunsetted in 1990, had been actively pushed to be migrated off in 1990-1995, but the cost of updating software that used the popular BSD Sockets API, introduction of NAT to remove major pain point, and certain major client (read: government and military) giving waivers on upgrading deadlines to vendors[1] meant that nothing really moved.
And everytime people try to push things forward, some big chunk of infrastructure becomes a blocker - like cloud providers[2] - or we get inundated with "why in 1995 they didn't decide to go with something backwards compatible?". Newsflash - it was impossible for BSD Sockets software to be forward-compatible. If your software was build with XTI or similar interface (like Plan9's dial(), which is present in Go), you got IPv6, IPv7, and IPv9 support back in 1996, along with X.25 and who knows what else. In fact, IPv9 aka TUBA was actually implemented in network hardware around 1992 - the original RFC pointed to experiments using nearly unmodified Sun and Cisco hardware.
[1] US government finally learnt though, and if you're selling to them you now have to support v6 or wrap your product in a black-box that will handle v6. No deferrals for products/vendors.
[2] I'd argue AWS, GCP and Azure had significantly hampered global IPv6 migration
- “You don’t need NAT”: well, you still need a stable address space for your LAN that survives your ISP randomly changing your prefix (which has happened to me at least a half dozen times over the past year), and the best option for that is ULA, which erodes many of the benefits of “no NAT” because my IP’s are not routable.
- “No DHCP”, well you can’t reliably know the IP address of anything on your network without it: SLAAC with EUI-64 was supposed to make addresses stable and derived from your MAC address, but oops, that’s a privacy nightmare, so we end up randomly generating them (and rotating them!) IMO this is more complicated than DHCP, not less. Oh and DHCP lets you assign dynamic DNS names to every lease you hand out, and you lose that too with SLAAC. You can do mDNS but that doesn’t help with public hosts that you want to access from the internet, you’re left with static IPs there, and god help you if you get re-prefixed (see point #1) because now your static IP won’t route because your ISP changed the prefix.
I’m really rooting for ipv6, trust me, but it feels like all the greenfield rearchitecting they did ultimately doesn’t seem much better than the IPv4 equivalent standards. NAT is here to stay, unfortunately, and so is DHCP.
I have both globally-routable and ULA addresses assigned to the hosts on my LAN. The ULA addresses are in my local DNS, and I update global DNS whenever the site's global prefix changes. Aside from the fact that the global prefix changes way too frequently (like once a quarter) it works great for me.
> ...so we end up randomly generating them (and rotating them!)...
Yeah, I turn this shit off whenever I have the power to. This was a fucking stupid-ass thing to have on by default. Hella buncha ways you can be tracked that give zero shits about what your IP address is. (This is one time when I wish the Net Heads would have consulted with the Web Heads and learned about how trackers actually work.)
> NAT is here to stay, unfortunately, and so is DHCP.
Nothing wrong with doing DHCPv6 and SLAAC, or just DHCPv6. My network just uses SLAAC, but folks who need more features than that provides have another tool they can deploy. This is a good thing.
And you __can__ use NAT if you choose to, but if you're being assigned a publicly-routable prefix, there's no real reason to. Set up your border firewall to deny inbound unsolicited traffic, and set up uPNP (or similar) to hole-punch and you end up with the same security guarantees.
Originally it was “IPv6 is great, you don’t need dhcp”, but then it became “well you may need DHCP anyway so here’s DHCPv6”, and then that becomes necessary often enough that you can’t really point to that as a benefit of IPv6 any more.
You don’t need NAT but you need a lot of the systems complexity that NAT requires, because you have to manage two sets of addresses in various configurations. Split DNS, etc.
You’re fine if you own the address range and it isn’t provided to you dynamically with DHCP-PD, but that isn’t the case with basically 100% of residential deployments. You need to multihome to even apply as a RIR to get your own prefix.
https://lagrange.cloud/products/lir £15 one-off for an ASN and £7/y for a /48.
Then you just need to find someone to give you a BGP session. https://bgp.services
The Wikipedia explanation is flat-out wrong.
There is no functional difference between PA and PI.
Sorry, what's your point? That having both address autoconfiguration and DHCP is too complex? If so, that's has been the standardized state of the art in IPv4 since 2005 with RFC 3927, and has been non-standard actual practice with Windows and Mac since like 1998.
> ...you need a lot of the systems complexity that NAT requires...
No, all you need is a router that can do IPv6. It doesn't even have to have a firewall, which is absolutely mandatory for consumer-grade border-router NAT.
> ...Split DNS...
I don't run that. My DNS answers local queries for LAN hostnames it knows about and forwards global queries upstream. Just like nearly every consumer edge-router DNS server.
> ...DHCP-PD...
Yep. My ISP runs that on the WAN side of the router. I just do RAs on the LAN side of the router.
I don't think I've ever seen two computers communicate over a 169.254 address. Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned. The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
I have. Used to do it often in the dorms when the uni's DHCP server was on the fritz. Zeroconf/Avahi wasn't really a thing, so we'd use Network Neighborhood to get people's IP addresses to browse files or play on servers they were hosting or whatever. I have also (as the RFC envisions) done it when connected to ad-hoc WiFi networks, and also while directly connecting two Windows PCs. In those scenarios, I asked my peer what their IP address was, rather than bothering with going to Network Neighborhood.
> Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned.
Correct. From the second paragraph of the Abstract of RFC 3927: [0]
> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).
> The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
No, it's also recommended when using IPv6 to not use link-local addresses if any other address is available. (Both because those addresses are only link-local, and because one usually needs to put an outbound interface specifier on the address when you go to contact another host, which is pretty obnoxious.) It just happens that IPv6's address autoconfiguration has been upgraded to be useful for globally-routable addressing, too.
So, yeah, a usual mode of both IPv4 and IPv6 networks is to have autoconfigured addresses, as well as DHCP-assigned addresses. It just so happens that most of the time IPv4 addresses are not autoconfigured, and most of the time IPv6 addresses are not assigned by DHCP.
That's equivalent complexity.
[0] <https://www.rfc-editor.org/rfc/rfc3927>
With what seems to be the recommended IPv6 setup at least for client machines, the Link-local address is the only stable identifier of that machine, as the actual reputable address changes all the time. So, the machine has both a link-local and a routable IPv6 at the same time, and both are going to be used. This is still different from IPv4, where link-local addresses are, again, an obscure feature that almost no one uses.
What? ULA space is the IPv6 equivalent of RFC 1918 space. If you want a prefix you know will not change, then you go generate you a /48 and use that on your internal network(s).
Why on earth would people expect ISPs that have a "We won't give you a guaranteed-static IPv4 address." policy to have a "We will give you a guaranteed-static IPv6 prefix" policy? Thinking that way is madness.
Perhaps you're confused because you're looking at guidance for client machines, when you should be looking at guidance for customer edge routers? Check out RFC 7084, and in particular section 3 and its subsections, and section 4.3 and its subsections. [0]
> ...as the actual reputable address changes all the time
Are you talking about IPv6 address randomization? (AKA "privacy" addresses?) IF you are, then know that it's
a) Controlled by the operator of the computer, rather than the operator of the network it's connected to.
b) Optional, and SHOULD be able to be turned off by the computer operator.
c) RECOMMENDED that a stable address be generated for the machine, in addition to the random ones.
Thing c) is in part to deal with "But what if I want to put a AAAA into the local DNS?" problem, and in part to give expected-to-be-long-lived connections an address that the system knows will hang around for at least as long as the interface is up.
After all, unless you want to tear down the connections associated with it, you can't remove an address from an interface until those connections have closed. More addresses allocated to a host means more multicast groups joined for that host, which eats up resources on the local networking infrastructure... so (if you're using "privacy" addresses) you really, really wanna steer ephemeral connections to addresses that are temporary, and long-lived ones to ones that are not.
[0] <https://datatracker.ietf.org/doc/html/rfc7084>
My point is very simple: you can’t say “IPv6 is simpler because there’s no DHCP” if there’s DHCP. It’s pretty obvious right?
DHCP is orthogonal to IPv6.
IPv6 deployment is simpler for many reasons. One being that at the typical end-user site you have neither v6 NAT nor v6 DHCP. Another being that you have enough address space (and we have collectively learned from the IPv4 allocation lessons how bad things can get) to have a good chance of setting things up so that routers need not do quite so much work to route v6 packets.
I do ULA+global unicast too, but it would be far simpler if I actually had a reliable stable prefix and could just use that. I put my ULA addresses in local DNS (because that’s why I need ULA, I need to not worry about rewriting my zone file whenever my cable modem reboots), but that means I have to do split horizon DNS. I wish I didn’t have to. (Yes I do mDNS too but I need real DNS for lots of use cases.)
You also said
> NAT is here to stay
Which, uh, it sure sounds like you're not using IPv6 NAT. In fact, it looks like aside from probably being confused about what "split horizon DNS" is [0] your setup is exactly like mine. Address autoconfig for both a annoyingly-frequently-changing global prefix, and a constant ULA prefix with DNS entries for the ULA addresses.
[0] Does your DNS server serve LAN _and_ WAN clients? If it doesn't, and it only serves LAN clients, you're almost certainly confused.
> They pretty clearly talk about public hosts
Thing is, I ALSO have public hosts on my LAN. And they're in both the public DNS and in the DNS on my LAN. But public DNS is not served from my local DNS, so I don't have a split-horizon setup.
The mere act of maintaining (in two entirely unrelated DNS servers) records for the same resource but with different data doesn't make a split-horizon setup. If it did, then I could reasonably claim "I'm running a split-horizon setup for mit.com!" just by adding an A record for "mit.com" to my local DNS server, despite being neither connected to any MIT internal networks, nor in a position to serve any data to MIT's Internet clients.
I do DNS such that the same hostname, which I control, resolves to the ULA address if asking locally, but the public address if asking from an external machine. But it's not literally the same server, I use DNSimple for my public DNS and unbound on my local DNS. You can split hairs about whether split horizon means "the same DNS server serving both views" or not, but that's a needlessly pedantic snipe. But to cut off this argument: Sure, you're right. You score one internet point, I used the word "split horizon" incorrectly. You're very smart.
No, I'm really rock-stupid.
I also happen to be correct about the terminology.
> > NAT is here to stay
It's not generally good form to cherry-pick things I said from other threads and put them out of context. "NAT is here to stay" can for the purposes of this discussion mean "Thinking about global vs local addresses is here to stay", even if it's not NAT per se that is happening (ie. if you're using a ULA + global unicast, like I do.)
> you're almost certainly confused
I'm not confused. I do split horizon DNS. I serve WAN and LAN clients (not currently from the same DNS server, although that's what I'd prefer to do. The same hostnames are currently configured in different DNS systems depending on who's asking, hence "split horizon".)
To be clear, here's my setup. It's not unique or interesting compared to any other "home lab" setup:
- I have multiple machines that I want to be able to access by DNS name externally.
- I also want to be able to use those same DNS names for local configuration, to keep things sane.
To do this, I have two options:
1) Use the publicly-routable global unicast addresses in my DNS, and make a system to keep them updated in a reprefix
2) Use a ULA prefix for local DNS, and the global unicast equivalent addresses for public DNS, and make a system to update only the public DNS when I get reprefixed
I chose option (2) because I want to mitigate the damage that happens when my ISP reprefixes me. (It's happened 6 times over the past year, it's not uncommon.)
When I get reprefixed, any local traffic that's using DNS to lookup the address keeps working as usual, because the ULA address doesn't change. I have to worry about reconfiguring public DNS, but that's the lesser of two evils IMO:
Because if I picked option (1), I'd have to reconfigure public DNS and my local traffic would all be disrupted while the reprefix happened: My hosts would all be trying to communicate with one another via their old prefixes, and failing until DNS reconfigures.
And this is all not to mention that I have to do the exact same reconfiguration dance with my firewall config: When I get reprefixed, my pf.conf is now referencing invalid IP's. I disable-by-default so it's not a security issue, but it's something that I had to solve with automation (in my case, by templatizing my pf.conf and writing dhcpcd hooks that reconfigure it when the prefix changes. It wasn't trivial.)
Now, to get back to my original argument: IPv6's simplicity benefits "erode" when you consider that worrying about internal vs external addresses is still something you have to deal with in the real world, at least in residential deployments where you don't own your own prefix. Granted: These issues are inherent to any system where your ISP is dynamically assigning you IP's, but it's important to understand: Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work, due to it being the real world.
What? Press "parent" on the comment of yours that I'm quoting from right now four times. You'll find the comment of yours where you say "NAT is here to stay" right here in this comment tree.
> To be clear, here's my setup.
Yep, that's my setup as well, except I don't screw around with applying per-host inbound traffic firewall rules at my router. Either traffic is worth blocking to an entire subnet, or it gets blocked at the host that cares about it. Saves a ton of maintenance.
> Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work...
Yep. It's less complexity than with NAT. Substantially so. That's like the entire point. The additional complexity you keep pointing at is because of a feature that you can't have with typical end-user NAT... the ability for each host on your LAN to have a globally-accessible IP address. And you can get rid of most of what you're complaining about by paying for a static prefix and getting it tunneled to your site, as folks elsewhere in this sprawling conversation tree have mentioned (or getting friendly with a local clued-in ISP and having them statically-assign you one).
The randomly changing prefix is really annoying. There's no reason for your ISP to do this other than to try and upsell you on expensive commercial services.
This isn't true. If it were, then home ISPs would never renumber client networks.
You're probably thinking about the larger allocations handed to folks who have ASNs, rather than the small allocations handed small ISP customer sites... and even then, those can totally be reclaimed.
1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. ... but don't make anyone learn anything new
2) if we're already replacing everything, make stuff better ... and make everyone learn everything all over again
And there are also other things - more dependence on ICMP, the concept that your LAN IPs are determined by your ISP (unless you also assign ULAs in addition to all the other IPs), and probably others I'm forgetting.
For many years it embedded the idea that every application had to handle exact details of each protocol it wanted to support through its exposure of gory details in sockaddr struct and requiring that as input to connect() and listen() calls.
All the SLAAC, privacy address, etc? That's just an emanation of people cargo-culting some practices that were workable with IPv4 but only by making the network suck.
And ifconfig got deprecated because it didn't fit linux networking API anymore, and nobody wanted to maintain it instead of writing something that fit well - which was iproute2.
Also adopting IPv6 these days would require to maintain still IPv4, this means that for example firewall rules must be made both for IPv4 and IPv6, something that adds a lot of work to IT technicians (and they thus disable the protocol that if you disable the internet still works, that is IPv6). Extending IPv4 would mean that the same firewall rules can apply, just considering again the upper 32 bits of the address.
Finally IPv6 is in general more complex, it has some obscure things like SLAAC or the fact that an interface can have multiple IPs, that not all IPs are routable, etc, even simply the notation for IPv6 addresses that is not even consistent among software (in some software you have to put it between [] to disambiguate with port numbers, in some other not), DHCPv6 implementations that are still these days quite broken, etc. Compared to IPv4 is quite a complication...
I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4, and requires maintaining a network with two protocols, since everyone completes the migrations, this is unlikely to succeed in the next years (for example in my country, Italy, most ISP, even the most important one, don't even bother to provide you an IPv6 address! I think that because it does increment the problems and thus the requests to handle in the customer service, thus they decided that you just get IPv4 that works reliably).
Sounds like IPv7, from year 1993: https://datatracker.ietf.org/doc/html/rfc1475
> I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4
Doubt, seeing how IPv7 appeared around the same time as IPv6 (RFC1883, from year 1995) and we still don't see IPv7 anywhere.
To be fair, IPv7 seems to have been deprecated in 2012 (RFC6814). It had almost 20 years to catch up but, quoting the RFC, "IPv7 was never widely deployed".
The author(s) of IPv7 (TP/IX) 'abandoned' / altered it to CATNIP:
* https://datatracker.ietf.org/doc/html/rfc1707
This was put up for consideration for IPng, and compared with TUBA and SIPP:
* https://datatracker.ietf.org/doc/html/rfc1752
The general idea of SIPP(-16) was chosen (and tweaked) to be IPng, now called IPv6.
The criteria needed for IPng candidates were:
* https://datatracker.ietf.org/doc/html/rfc1726
"IPng" was the general thing that would come after IPv4, and not a specific proposal.
The specific proposal that was chosen (over TUBA (aka ISO's CLNP), as well as CATNIP) was Simple Internet Protocol Plus (SIPP):
* https://datatracker.ietf.org/doc/html/rfc1752
Step 1 would've been to leave all the routing, DNS, NAT, DHCP etc as-is and just get people's devices speaking ipv6. And we would've already been there years ago. Once that's done, DNS and DHCP can be updated, then people can start using the extended address space by splitting up their blocks. So if you previously had 1.2.3.4, you now also have 1.2.3.4.1 etc.
It's actually not too late to do this with the existing v6 header.
https://datatracker.ietf.org/doc/html/rfc1385
IPv6 took longer because the internet is now run by companies that need to see a return on investment, and as long as IPv4 was working fine for their customers, didn't see a benefit to it. It's why IPv6 adoption only started taking off when the answer to "Our projected customer growth this year is 200,000, can we have 200,000 more IPv4 addresses please?" became "No".
This was around 1996, which is when the vertical growth phase took off. Too late.
Source: was there.
IPV6 is one of those things where if isp,'s just switched over to it, I'd have so less nightmares caused by cgnat and that bullshit like how expensive static IP's are.
Many its because I'm not working at a ISP or a teir 1 backbone but forcing the transition to ipv6 seems like overall it would be less of a clusterfuck than our current ipv4 stuff. I know their is stuff going to break, anytime changes are made at this scale it often has some hickups....but dear god I really hate how static IP's are so expensive, and how expensive a small IP block is. Also IPV6 is just an excuse to get fiber everywhere.....I hate how slow many services are.
CGNAT at scale functions by assigning a range of ports on a shared v4 address to a downstream customer. You can normally get between a 1:8 and 1:32 "compression ratio."
We still need to free up additional IPv4 to keep the internet growing. Don't let the "just switch to v6" crowd fool you, both solutions need to addressed in parallel.
CGNAT is a term that broadly used to refer to carrier-scale solutions to deal with issues with number exhaustion and dual-stack deployments. What most people think "CGNAT" is, is actually NAT44. https://nfware.com/blog/why-cgnat
Likewise, some Linux mirrors don't support it. If I decide to try an IPv6-only server, and the first thing I see after "apt update" is network errors, I'm not very motivated to use IPv6 in the future.
Then add some problems where having IPv6 enabled randomly breaks things for one reason or another. I can either debug it forever, or turn the "internet is broken" switch (labeled "Enable IPv6") to "off" and get on with my day. That means more people that support IPv4 but not IPv6 (to be fair, this one seems to have gotten a lot better).
But ultimately, until some major, hard-to-avoid site says "we'll only be on IPv6", there is little reason for most to use it, and many reasons not to. That's why the transition takes forever.
[1] http://www.delong.com/ipv6_alexa500.html
Amazon has hopefully started a change in this mentality by charging money for every IPv4 address used. This creates a real financial incentive to deploy IPv6-only servers, which in turn means that critical services like Github and Linux mirrors are slowly forced to provide IPv6.
There still is, even though they've started charging for v4!
Anyone who has ever done net stuff for a living knows that you type or copy paste addresses constantly. Whenever I say this to V6 evangelists they say “we’ll use DNS” which is “tell me you’ve never been a net admin without telling me.”
I’d love for V6 to get traction but I think something needs to be done about the usability issues before it will happen.
Even little details like the fact that in no terminal does double clicking on a V6 address properly select it is a huge problem. Yeah you might be able to change that but that custom config won’t be there on the next machine, etc.
Even seemingly simple usability problems are death to adoption.
It’s not hard to remember IPv6 addresses for DNS servers assuming your addressing plan reserved the right subnets for anycasted services.
Remembering IP addresses stops being a thing pretty quickly. If anything the challenge shifts to remembering airport codes.
If you are typing them by hand that often even in IPv4 networks I'd be worried about typos and insufficient automation.
I think it’s more that small and medium organizations just don’t have any incentive to change (and plenty of incentive to not take the risk of change) leading to the numbers we see at https://ipv6-in-real.life/
Automation is all very well once the network link is up and working so you can reach the automation
But the reality is you put someone who knows what they're doing in front of a machine where the network connection isn't working, the first things they're going to be doing is ifconfig and ping 8.8.8.8 - which they'll be doing from memory, because you can't google anything when your network connection isn't working.
The fact that IPv6 will deprecate both ifconfig and 8.8.8.8 to me seems emblematic of why the adoption has been going so badly.
If you're using ifconfig on linux[1] for the last 10 years, I'm going to negatively look on your claimed expertise
As for point-to-point links, that's what simple link-local addresses are, added in ipv6. And why IP-IP is superior to OSPF, both because it doesn't hardcode address sizes and because it runs on Layer 2.
[1] ifconfig on other systems might be the right command
With properly constructed automation and modern* hardware, you don’t need to do any manual config on-box for automation to be reachable. Zero-Touch Provisioning is a wonder to behold.
Modern being relative. I saw this work on routers terminating telco circuits nearly 20 years ago and had servers netboot and install the OS with basic config before that (though automation was far more tedious back then)
... :-( ... goes to cry in a corner
This makes no sense, http is flawed because its unencrypted and allows MITMing information.
IPv4 is flawed merely because it doesn't have enough addresses.
How are these two comparable? Your proposed "solution" is overkill and is completely ridiculous.
A more cogent argument is that IPv4 and IPv6 have not fully coexisted like http/https, where you can pull the ipv4 rug out and every packet has an ipv6 path like http to https did.
Also more profoundly, https conversion had the benefit of every operator being able to transition on their own time frame. And people can still opt to use http if they so choose. IP not having that luxury is a profound problem.
This I don't get. I expect that Google will be far more likely to make it extremely difficult (or perhaps impossible) to use Chrome to visit non-TLS-wrapped HTTP sites on the Internet in the next five years than the operators of the various networks that make up the Internet are to just shut off IPv4 on their network.
I expect IPv4 will not be shut off within the lifetime of anyone posting on this forum today... and why would it be? Once just about everyone has well-functioning IPv6 access, release a recommendation to ISPs that unless a customer has an even vaguely-reasonable need for a globally-routable IPv4 address, that ISPs substantially reduce their IPv4 usage by providing IPv4 service to their customers through some CGNAT.
This would ensure that the few remaining hosts with IPv4-only service will remain reachable, that any customers who can bother to write a letter to their ISP asking for a globally-routable IPv4 address can get one, and a ton of IPv4 space gets opened up for whatever we might need to do with it in the future... just in case.
I'd like to see rules that force ipv6 support, and then to prevent idiot network admins from disabling ipv6 locally because they're too lazy to learn how it works, make some websites v6 only. Start with essential government websites and move on to laws forcing more and more private websites to be v6 only to force people to maintain its functionality in their networks.
See: https://konecipv4.cz/en/
The market has been given its chance to move for DECADES and we're not NEARLY at the approximately 100% deployment that we need. It's time that we fix this mess.
Adoption rate is currently increasing roughly linearly at a rate of about 5 percentage points every 12-18 months. Also note that there is a clear weekday/weekend pattern, with weekdays about 3-4 percentage points lower than weekends.
Very little progress has actually been made to move the bulk of stuff using v4 addresses over to v6. AWS v6 only instances have only been around for 20 months or so?
I don't know how to quantify "very little progress", but my home ISP (Verizon FiOS in NYC) got IPv6 relatively recently (maybe a year or two ago).
Anyway, don't most people connect to WiFi while using their handheld devices at home anyway?
a) According to [0], AWS has provided IPv6 addressing to EC2 instances since 2016.
> IPv6 support for Amazon Elastic Compute Cloud (Amazon EC2) has been available along with IPv6 support for several other services since 2016.
Refer to the 2016 blog post at [1], which says (among other things)
> By default, every IPv6 address is public and internet-routable. For customers requiring a private subnet on their IPv6-enabled VPCs, we are introducing a new resource within the VPC called the Egress-only Internet Gateway, which can be setup to allow one-way access to Internet resources.
b) I don't get the "This migration only counts if we can support only IPv6 and shut off IPv4" obsession. I see no reason to shut off IPv4 within our lifetimes. I expect the distant future will be providing end-users with a globally-routable IPv6 prefix and a CGNATted-to-hell-and-back IPv4 address for reaching out to those sites that may still be using v4 only.
[0] <https://aws.amazon.com/blogs/publicsector/aws-enables-us-fed...>
[1] <https://aws.amazon.com/about-aws/whats-new/2016/12/announcin...>
Yes, but that isn't what we are talking about. 2022 is when they added native IPv6 support, prior to that it was just a fancy NAT like translation.
Are you sure about that? The relevant docs from 2019 (the Wayback Machine doesn't have anything earlier) sure make it seem like you're getting globally-reachable IPv6 addresses:
From [0]:
> To complete this exercise, do the following: ...
> * Launch an Amazon EC2 instance into your subnet, and associate an IPv6 address with your instance during launch. An IPv6 address is globally unique, and allows your instance to communicate with the Internet.
Yes, the last bit of that doesn't automatically mean that your instance is globally-reachable. Read on.
From [1]:
> IPv6 addresses are globally unique, and therefore reachable over the Internet. You can control whether instances are reachable via their IPv6 addresses by controlling the routing for your subnet, or by using security group and network ACL rules. For more information, see Security.
From the "Inbound" table of the "Recommended Rules for Scenario 1" section of [2]:
> | 170 | IPv6 address range of your home network | TCP | 22 | ALLOW | Allows inbound SSH traffic from your home network (over the Internet gateway). |
Am I missing some part of the docs where they talk about how there was some fancy NAT-like translation box that made it so that these weren't globally-reachable IP addresses? Was AWS just lying in their docs?
[0] <https://web.archive.org/web/20190131164146/https://docs.aws....>
[1] <https://web.archive.org/web/20190801182729/https://docs.aws....>
[2] <https://web.archive.org/web/20191021190354/https://docs.aws....>
AWS was never built with IPv6 in mind and it is mostly glued on. As of right now 88% of AWS services are IPv4 only: https://awsipv6.neveragain.de/ (uncheck the Hide IPv4 only box)
I mean, on the one hand, I'm taking AWS at their word. If they wrote subtle lies into their docs, one can hardly be blamed for failing to understand the truth of the situation.
But on the other hand, if
* My VM has its globally-reachable IPv6 address assigned to it
* Can transmit packets to globally-reachable IPv6 hosts using that address
* Can receive unsolicited packets from globally-reachable IPv6 hosts on that address
whatever hairs you're splitting seem to be a distinction without a difference? Based on my professional experience, "wacky SDN stuff" is par for the course in the Public Clown.
Or, to put it another way, the customer of an ISP couldn't care less about how exactly that ISP delivers them globally-reachable IPv6 service, just so long as it behaves exactly like you'd expect globally-reachable IPv6 service to behave. Maybe between the customer's edge router and the Internet the ISP has some wacky tunnel that runs only over IPv4, and breaks IPv6 service if you turn it off... the customer doesn't give any shits, just so long as the IPv6 service works correctly and reliably.
> As of right now 88% of AWS services are IPv4 only...
This to me is an entirely irrelevant statistic. My expectation is that end-user systems aren't going to be IPv6-only for a very, very long time, but are going to nearly all have globally-reachable IPv6 addresses relatively soon.
So, one should (for the foreseeable future) expect global bidirectional reachability for end-user systems on IPv6, and typical NAT "initiated by end-user request" reachability for end-user systems on IPv4.
A true chicken and egg problem.
At this rate, we’ll be struggling with IP-shortages, CGNAT and other fun things for decades to come. And it’s all so unnecessary.
There's probably a few other ISPs that need a good kick to the groin in the US, but the general feeling I get here is that the real stragglers in v6 deployment are other countries. Indeed, looking at Google's IPv6 map[0] it's all countries in Africa and the Middle East that have the worst v6 adoption. It's places where there isn't enough demand for addressing to make CGNAT unviable and IPv6 necessary.
[0] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
> While there are somewhat ongoing efforts to see 0.0.0.0/8, 127.0.0.0/8 become routable unicast space
I am curious about this statement. How can 127/8 ever become internet routable? It is after all used for the local host. Or am I misunderstanding something here?
Agreed that it would be impractical to actually use these. Maybe for linknets?
If any big site (or even better, many big sites together) were willing to go that far, a much better measure would be announcing that they'll go IPv6-only on the next IPv6 day. Just for that day. And then again the next year, but for a week. Then for a month the year after. Then permanently. That would give ISPs the kick in the butt to fix it, because nobody wants their hotline to field a day full of "my Internet doesn't work" calls, only to then have to fix it anyways because otherwise it'll be a week next time.
You can as soon as you define it as an alias.
> Linux's behavior of allowing the whole /8 to be used, even when only a single address is assigned, is a bit of an oddity here.
Per the RFC: "127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host."
Linux special-cases 127/8 on the virtual loopback interface and will treat all looped-back packets as if they were addressed to the host, even when the destination isn't explicitly configured as an alias. This behavior is not required by the quote from RFC3330.
[1] I needed a lot of localhost connections to run a TLS terminator separate from the underlying service which didn't support unix sockets. Using the 127.0.X.0 bits in addressing was very helpful for diversity in the hash used for kernel socket tables, otherwise most slots had few sockets and some slots had way too many and perf was bad. Configuring multiple loopback interfaces using more address space was a lot more tractable than changing the kernel hashing behavior, adding unix socket support to the underlying service, or adding good TLS to the underlying service. Although probably since then all three things have happened.
For your TLS thing, is it whatever application you were using expected to use a whole swath of TCP ports at whatever IP address, so expected separate IPs?
Feels like dedicating some range of addresses to "private use" would have been useful, then if you needed a bunch of local loopbacks, could configure it so, or if your local network wants some magic, tada.
Sometimes you see 127.0.1.X/24. I've even seen 127.1.X.X around, but I've never seen 127.254.X.X around. I'm sure someone somewhere did it just for grins and giggles or something though.
It isn't all in use on most machines. Many hosts only use 127.0.0.1/32 and do not use the rest of the space; changing the default netmask on the loopback interface from /8 to something like /24 would be one step of the transition.
Like 240/8 it's probably not worth the effort.
I think that it's the most problematic proposal from all these – unlike 240/4 etc every ip stack on earth has hardcoded knowledge about 127/8 for sure and it will took at least decades to deprecate all these. And I also have seen addresses other than 127.0.0.x used in wild. As far as I understood, some orchestration systems use generated 127.x.x.x addresses to avoid conflicts between applications. Linux makes it very easy – you just bind an application to 127.45.2.189 for example and it just works. There is no need to add it to the interface or something.
If your #1 goal is to keep your 133t bragging rights, then there are no such things as unnecessary nor excessive complexities.
10.0.0.0/8 might seem like a lot of addresses, but certain large companies have enough fans and chillers and miscellaneous things that can fill that space, and it takes a lot of effort to reorganize their network to better allocate those addresses.
Do these large companies really have 16,777,216 fans and chillers? That would be enough for each of Wal-Mart's 10,586 stores to have 1500 IPs each.
Or do they just have legacy allocation mistakes?
Some of those might be regular servers or networking gear that are required to have IPv4 addresses for one reason or another. For example, they might need to interact with fans and chillers.
> legacy allocation mistakes
Requiring the same globally unique prefix for devices that share locations or functions would eat up allocations faster than the number devices would grow. But there are definitely good reasons for allocating addresses that way, just as there are probably good reasons why the number of ports on a switch isn't always a power of 2.
Other times they might not have been able to allocate it more compactly - are you really going to go make routes for a /25 and a /26 and a /27 when you need 200 IPs, just to save a single /27 over giving it the whole /24?
There can also be reasons to structure it more sparsely than required for UX, namely to give a more hierarchical structure - maybe by region and store, or similar.
tl;dr it's not necessarily a mistake that your allocations mean you use more space than strictly necessary
Classful allocation had /8s, /16s, and /24s depending on the numeric prefix (0-127 were /8, 128-191 were /16, and 192-223 were /24).
https://en.wikipedia.org/wiki/Classful_network#Classful_addr...
IPv6 has none of these problems by design: use it.
No in fact, it is so much worse! I do agree we should use IPv6, The ending of the blog post says as such :)
> If we are going to start using address space that might not work for all users, it would be wise to pick the address space that we already have a considerable head start on getting accepted: IPv6.
Somehow it is getting more and more common. I stayed at a hotel last year that used 1.0.0.0/24 on its LAN (yes, '1' not '10', I couldn't believe it at first).
subpar replacements w/o real alternatives
I'm not connected with this presentation (other than having talked to Ben about it prior to his giving it, and I guess supplying some of the information on software that accepts 240/4) but I am one of the people working on the project that he describes/criticizes.
Here is our current proposal.
https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...
People have been reacting to this with different forms of "just do IPv6" for many years. I guess we need an official statement about that somewhere. [Edit: other than these quick thoughts below...!]
I personally think IPv6 is great (I was excited about it in the late 1990s when it was standardized, and gave some talks to promote it, and am happy to see it getting deployed and happy to find myself using it sometimes). I hope people will keep working on it and networks and services will keep adopting it.
However, people's need for IPv4 address space depends enormously on other people's behavior. IPv6 addresses are not a good substitute for IPv4 addresses when you're providing a public service, if many of your users don't have IPv6. A high fraction of demand for IPv4 address resources appears to come from organizations and networks that already support IPv6, because they need dual-stack support for compatibility with other people.
Even though IPv6 adoption has been happening, it's easy to imagine that it's "almost done" where that really doesn't seem to be the case. (This is complicated by having very different statistics in different countries: some countries are now almost all IPv6 traffic, while others have almost no IPv6 -- so people in different parts of the world often have rather different intuitions about it.) We still see enormous economic demand for IPv4 address space and projections that IPv6 adoption to a point where IPv4 would somehow no longer be useful or important is likely still decades away. If that's correct¹, we can still get a benefit from making 240/4 usable because that process can be substantially complete during a time when IPv4 is still extremely important.
One thing that Ben (and one of the questioners at the end) argued in his presentation is that even if the adoption of IPv6 is unreliable or erratic, it might be more reliable than useful adoption of 240/4. (This was kind of phrased in the converse direction.) I'll have to think about models of that issue.
Edit: We have been sad when seeing how proposals to make 240/4 usable were made in 2008, but not adopted at IETF. Among things that people said in 2008 was that IPv6 would make this irrelevant quickly. That turned out not to be right, but we lost years of opportunity to make 240/4 more useful in the meantime, where billions of devices shipped in the interim could easily have supported it by default. So, we still have the opportunity not to have the same sense of regret in 2035.
¹ I'm also aware that there are other projections here; I recently interviewed a prominent Internet greybeard figure who theorized that Internet infrastructure growth as a whole has slowed so much that IPv4 demand may be satisfied in the future out of gradual conversion of residential ISPs to using primarily carrier-grade NAT for IPv4, and then selling off their number resources. In this account, IPv4 will remain important on the Internet for a long time, but economic demand for addresses will decline because most users won't have native IPv4 at home or on their mobile devices (the latter already the case in many networks). The economic demand for IPv4 resources is something that has made reclaiming 240/4 appear worthwhile, so in this model it would become less exciting, even without having IPv4 "go away".
You've made the internet safer for all of us.
I believe that IPv6 [1] is without a doubt coming in the future. Even with carrier grade NAT'ing and the likes, there are too many major providers who have already switched to single stack IPv6 natively.
That said, I agree that 240/4 is necessary to assist with the transition. Due to the fact that most network operators aren't even dealing with /24's, it becomes increasingly hard to facilitate bridges between the legacy IP and IPv6 so more IPv4 space is always appreciated (until the day we don't need to bridge at all).
[1] I may have a bias due to affiliation with https://IPv6.rs
The disappointment is there seems to be no difference between "needing a single open port" and "needing and entire IP address" due to overzealous egress firewall rules that everyone thought was good engineering practice 20 years ago.
edit: spelling
Aside: in this vernacular, plural of ox is oxen; plural of box is boxen. “boxens” is never appropriate.
And they're not wrong either, it by definition disables not just a whole class of (admittedly outdated) communication channels for malware (such as IRC), but also other stuff you don't want to happen on your network either: bittorrent, people running online games during work...
There is a great level of IPv6 awareness and enthusiasm in sort of technically elite spaces. Like at Ben's talk at RIPE that we're talking about, the audience was kind of laughing together at the non-IPv6 outgroup.
Meanwhile, I keep helping people use Let's Encrypt over on the Let's Encrypt forum. One of the most common reasons that people are failing to get their certificates is ... misconfigured IPv6 on their servers or in their DNS! And people in that situation often (1) didn't think of that as a possibility, (2) didn't notice (!!), (3) didn't necessarily care about it. Even worse, when people are told something like "your certificate issuance isn't working because your AAAA record is pointing at your old hosting provider rather than your current hosting provider" their usual response is to delete the AAAA record rather than updating it.
Other forum members may also advocate this as a solution. "Oh, just delete your AAAA record, you don't need it."
I'm not making this up, I've seen these things happen about 100 times on the Let's Encrypt forum.
Now, these are primarily sites in the long tail of Internet popularity, the proverbial Joe's Lamp Store rather than Gmail or Facebook or something. But the level of IPv6 awareness and interest among small-scale site operators and people doing small-scale IT stuff is very weak. And I've also seen that a surprisingly high fraction of web sites are IPv4-only rather than dual-stack.
I'm working on 240/4 usability, but I certainly don't want people to delete their AAAA records. I want them to know what an AAAA record is, and want to have their AAAA records be correct.
But there's quite a gap, in a way, between the elite and the non-elite tech spaces on this.
If you do have AAAA records, Let's Encrypt (not unlike other software and services!) will prefer the AAAA records when doing domain validation for your domain. So if you have a correct A record and an incorrect AAAA record, your domain validation process will fail. You can then "fix" this by deleting the AAAA record, but it isn't a fix in the larger scheme of things, but indeed it makes plenty of users happy right away.
In addition, rate limiting with IPv6 is much harder (because IPs aren't scarce), so you risk DoS or other kind of abuse.
Users aren't getting single IPv6 addresses though. Most assign a /48 which is at least a bit better.
And rate limiting is very uncertain. If I limit per /56, users that have an entire /48 can outright bypass the rate limit. If I limit per /48, maybe I'll erroneously limit thousands of users whose ISP has all of them on the same /48.
If you wanted to block me, you'd have to block the whole /48. If you blocked a /48, you could be blocking 64,000 people.
Looks like crote brought the issue up in a sibling thread.
It's a shame that you're getting downvoted. I'm sure a lot of those people are shouting at their screen "well just learn it" but even if you're familiar enough with all the stuff it changes (RA, NDP, heck the lack of NAT), it's still a ton of work to get it properly set up and worse yet to maintain.
Large companies (and even ISPs) seem to be going for "IPv6-mostly" rollouts. Basically, everything is done primarily using IPv6, with fallbacks to IPv4 only when strictly necessary. This means IPv4 traffic gets converted to IPv6 at the client, forwarded over an IPv6-only network, and turned into "native" IPv4 for the internet at an edge NAT64 gateway. Legacy IPv4-only devices (printers and such) get an isolated vlan with its own gateway, and will of course be replaced with IPv6-capable alternatives as soon as it's appropriate.
I agree that for smaller companies it's relatively little benefit for the amount of work required, but if you're overhauling your network for other reasons anyways it makes little sense not to do it.
Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
Sorry, but that's a load of manure. It's not just about memorizing.
People break their DNS so often that it's a meme.
Not everything automatically does a reverse lookup on every address it sees, and when it does rDNS could quite easily be broken.
So when you need to figure out if a device is in the same building as you, is it easier to say "1.2.3. - oh, that's my building" or "1234:5678:90ab:cdef:1234:5678:90ab:: - oh, that's my building"?
> Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
Ok, not just memorising. It's also the culture of cargo culted broken network designs, of excel spreadsheets from hell, of thinking everyone can memorise or put few post-its with IP addresses important to them so you don't need to care for DHCP and DNS or actually setting up routing instead of throwing a ton of NATed 10.0.0.0/8 or 192.168.0.0/24 then crying when there's a need to setup 5 layers of translation to connect two services (been there, done that, kept the scars).
As others pointed out, you should have anycast addresses for core network services (DNS at least).
IPv6 arguably even makes it easier because link-local automatic configuration actually works unlike v4 APIPA, well enough to discover and talk to other nodes on given L2. I still remember my happy surprise when HP ILOs used that to let me configure them over network by just connecting to same vlan, something I can't do on v4 without messing with DHCP rules.
The fact that link local actually works, combined with multicast and predefined multicast addresses like ff02::1 or the addresses for mDNS, DNS-SD, LLMNR etc mean that you can actually get somewhere without configuring IP on the link.
Do you need to learn new things, and possibly rearchitect the network? Sure. But it's because v4 was deficient.
Also, more often than not, the "it was DNS" involves "resolver not configured" or "put BS in DNS got BS back now crying".
> Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
Essentially entire promise of DirectAccess, the transparent VPN system added in Vista, depends on the office network being IPv6-clean (as in, no user-used services that require v4 connectivity). Originally it required IPv6+IPsec connectivity at client side, due to lack of wide availability various fallbacks were added in Windows 7.
It's also why Vista and later had such a push to autoconfigure Teredo and similar V6 transition technologies.
> when it's broken it's broken cuz you broke it
No duh, but that doesn't make it any less broken.
Forcing the change seems to be the only way to fix some networks and some software, in fact.
> No duh, but that doesn't make it any less broken.
Nor does it make ones inability to ship minimal HOSTS file any less bad.
This is a very poor straw man.
In IPv6 world you wouldn’t use all the significant digits randomly and because you have so many you could actually use one of the octets to perfectly encode the building information:
Building 1: 2001:1:: Building 2: 2001:2::
(You can go further with this concept and encode region/country/state/etc into the addressing as required)
In IPv6 world you wouldn't get 2001::/112, you'd get 2001:1234:5678:90ab::/48. So your building might actually be at best something like 2001:1234:5678:90ab:1::.
For equivalent of 10./8 space, you'd have ULA, which can be subdivided this way just fine (and arguably since fc00::/8 is left in limbo, you can use that. Or just decide to fit whatever addressing scheme you decide into 80 bits left after typical fd00::<48bit random>/48.
So sorry, your v4 strawman isn't too good either.
I mentally swap the labels[1] when reading their marketing or release notes. If it says things like "No longer crashes when using IPv6", then I flip that and read it as "No longer crashes when using IPv4". That latter statement is absolutely insane and would have you abandoning that vendor as fast as you can tear up the contract. Nobody bats an eye with the first statement! Why not!?
Azure literally had this scenario, where merely enabling IPv6 on one network would crash their managed PostegreSQL service on another peered network with no recourse other than rebuilding everything form scratch without IPv6 to roll the change back!
[1] Or a generic placeholder than encompasses both. E.g.: "Fix: Enabling the internet protocol no longer causes irreversible outages with your database service."
Even Google, one of the champions of IPv6 adoption on the Internet, only started adding IPv6 support to GCP in the 2020s. In all public clouds, there are still numerous services that don't support it at all. And I can 100% guarantee that the next public cloud that anyone creates will start off with IPv4 support; maybe it will have IPv6 as well on day one, maybe not.
On the contrary, essentially all of the IPv4 public ranges have now been allocated. The incumbents have bought up what they can, leaving essentially nothing for new clouds to use. It's one type of moat, and the three biggest providers are happy to keep everyone on the far side of it.
A new cloud starting in 2025 onwards would likely be based on an IPv6 native design with IPv4 as the "add on" for public endpoints only, such as load balancers and proxies.
IPv4 is far too ingrained to start with IPv6 only.
We’re closer than most people assume.
If ipv6 had been designed form the start to allow seemless transparent access to ipv4 from an ipv6 only client that would be fine. But dual stack means twice the work and very little benefit (what services are ipv6 only, even today)
It does. It's called NAT64, and it works/breaks as well as regular NAT44.
A good majority chunk of cell carriers today have gone IPv6-only for phones. They rely on NAT64 gateways (rather than CGNAT) to access IPv4-only resources. A lot of consumer internet is slowly following that lead as a better alternative to CGNAT. At least if your customers are consumers we are really close to "You might only need to serve IPv6."
(It's the "Enterprise-grade internet" that is interestingly lagging and falling behind in IPv6 adoption, and maybe doesn't see enough reason to support IPv6-only well; especially if the cost of IPv4 plateaus again, as some suggest it might. Recent AWS cost increases for IPv4 have been something of a call to action to some Corporations, but in general if you are B2B you probably need IPv4 support for a while longer as the economic incentives games play out on a long, slow horizon.)
I thought it was possible to make a pure v6 network and use NAT64 as needed? I mean, we can argue if that counts, but I argue yes:)
On the client side there are apparently some subtleties about the DNS interaction if you want to literally have IPv6-only on the clients (as opposed to IPv4 CGN). If the clients do anything to not trust their ISP's view of DNS (like DNSSEC enforcement, or using DoH and an outside resolver), the ISP can't fool them into thinking that they should connect to an IPv6 address for a service that, from the point of view of the Internet as a whole, is actually IPv4-only.
Can I do "ssh 1.2.3.4" on a pure ipv6 stack yet? Last time I looked at ipv6 I couldn't even ping an ipv6 host by doing "ping 1234::5678", I had to run a separate tool (ping6)
The nat64 and vice versa should have been the play from the start. Want to host a sevice? Put in ipv6 only network, host it on 1234:5678::1, have your firewall with a public ipv4 address do the port forwarding, taking your public 12.34.56.78:1234 and natting it to 1234:5678::1.
Just the same as hosting your service on 192.168.0.1 and port forwarding.
But 20 years of dual stack and horrible cludges around changing public IPs later and many people still prefer ipv4.
IIRC, it's been over a decade since the "ping" command became able to understand both IPv4 and IPv6 addresses; it was only during the early adoption of IPv6 by userspace that we had separate commands for the new IPv6 stuff. Quoting https://www.man7.org/linux/man-pages/man8/ping.8.html "As of version s20150815, the ping6 binary doesn't exist anymore. It has been merged into ping. Creating a symlink named ping6 pointing to ping will result in the same functionality as before." So it seems it has been a long time since you last looked at IPv6.
I ran IPv6 on xfinity. It works. My devices don’t. I like my devices. Easier to just not use it.
I think Let's Encrypt's behavior is correct, and I don't think anyone inside Let's Encrypt or CA/B Forum would like to inflict "pain [...] on host and network operators" beyond the current practice. Let's Encrypt's current behavior could be described as cooperating with IPv6 adoption rather than compelling IPv6 adoption, which seems like a reasonable place for a certificate authority to be.
There are cases where Let's Encrypt has made choices that potentially slightly reduce compatibility in order to encourage what it considers technically correct behavior. The first one that comes to mind is
https://community.letsencrypt.org/t/adding-random-entries-to...
but I know there are others. On the other hand, all of those decisions can be justified in terms of improving the correctness of PKI software (like not hard-coding things that should not be hard-coded). I can't think of any example that's like "we wish this other technical thing would happen outside of the PKI, so we'll try to force it along", and I don't foresee the broader community getting comfortable with that.
There was a comment below that in the LE forums instead of asking people to fix their AAAA records, they ask them to remove it. That's exactly the behavior you don't want to reward, so you must cause pain.
https://www.verizon.com/support/residential/internet/getting...
there should be an itu mandate to label this kind of service distinctly different (e.g internet lite/basic)
That is one projection, but it is also a very bleak view of the future. One that we should actively fight at any opportunity and at almost any cost. It will centralize the internet further and squash many attempts for alternative communications.
Would it? It seems to me that a future where 1. every home land-line Internet connection is CGNATed; but 2. every cellular Internet connection is a public IPv6 prefix (as is already mostly the case today!); is actually a promising one. Provided, that is, that residential ISPs also get off their collective asses and provide the promised "hosted edge compute" capabilities they've been tinkering with for the last 10 years.
Since the Internet's inception, people on residential connections have been stuck in a broken mindset of "your home PC can act as a monolithic Internet peer — but only an unreliable one, that can't receive messages when it's shut off and is prone to being DDoSed — so you probably shouldn't actually use it as a server/p2p node, for anything other than, say, VoIP, or hosting an ephemeral multiplayer FPS game session. And you can tinker with a development web-server on your home network — but if you want to actually host anything, you should go pay a cloud provider."
Whereas, in a world with no well-Internet-connected home PCs providing the illusion of the possibility of hosting a home server, only instead:
1. home PCs — which can compute well, but can't be a network-ingress, and also might go down (often for laptops, less often for desktops, but both far more often than a real server would);
2. smartphones — which can network-ingress, but can't spend long periods computing (without burning all your battery life), and which will go down / out of wireless range extremely often; and
3. both commercial, and more importantly ISP-residential, edge-compute clusters — which would give tiny compute slices per workload, but ones with full network-ingress, and would never go down;
...then it'd be clear to all the people who had been thinking until that point that they could get away with p2p on home PCs using STUN/TURN-based protocols, that they would have to do something else; that operating systems (esp. mobile ones) and their client-server/p2p applications would have to evolve to become inherently edge-hybrid; that applications would need to evolve frameworks to embed persistent network-ingress "edge components" that could be shipped automatically and implicitly to the active network's associated edge deploy environment as part of the application's runtime; etc.
If you can't picture that: think about a web server backend that automatically deploys/updates an associated Cloudflare Worker whenever it boots up; and which then expects to be talked to through that Cloudflare Worker proxying requests to it; and where that Worker can also buffer requests, store data into its edge key-value store, etc.
But instead of a web server backend, it's the Minecraft app on your phone; and instead of Cloudflare, it's your residential ISP; and instead of the edge worker making a forward connection to your phone, your phone holds open an ngrok-like reverse connection to the edge worker to receive requests.
(Oh, and one other point of necessary evolution: that the "server component" of any p2p app would also be a mobile workload — not shiftable to the edge itself, but rather through the persistent edge workload to any [similarly reverse-connected, not always online] "compute host nodes" owned by the same user/organization. Such that you could buy a little NUC/NAS-like box to shove under your TV at home, whose marketed purpose would be compute+storage offload for the workloads launched on your phone; or such that your office could have some server racks for free auto-offload of "server components" of apps running on any employee machine — reversing the usual "cloud app with local client" relationship into "local app with sl...
As you say, residential ISPs used to provide additional services to their customers like web hosting, email, NNTP, shell access, time synch, IRC, mirrors of popular archives. They don't anymore - frequently, not even email. ISPs have clearly shown that they're not interested in being much more than the fastest dumb pipe around, because that's what their customers want, and I don't see that trend reversing.
When Netflix and others put CDNs "at the edge", they aren't doing that by building their own DC inside your city; nor by renting space in a random colo facility. Rather, they partner with each of the local regional ISPs, to put their CDN inside the ISP's "edge hosting DC" — a facility that almost all ISPs own (if not necessarily manage) at least one of in every city, precisely for the purpose of enabling such agreements.
So, unlike most Over-The-Top data services (which ISPs have long since lost the competency for), this one is something ISPs are actively doing. They're just not selling it B2C; their edge data-centers are currently a pure B2B play for them. But ISPs do know how to sell things B2C — so this would just be a question of them feeling enabled by product re-packaging to give this product line over to their B2C sales and marketing departments as something to charge their customers for.
"Re-packaging" this B2B colo into something they can sell to customers, would in turn just require the mobile OS vendors to step up and write code to make doing so an ops question rather than an R&D question — just as they did for visual voicemail, wi-fi calling, eSIM deployment, and so on. Essentially, Apple and Google would just need to provide their own server racks to ISPs, which host workload hypervisors for offload of workloads from "their" devices — in such a way that offload wouldn't be something customers would be paying Apple or Google a subscription fee for, but rather, as with Visual Voicemail, something where usage records from this system could feed into the ISP's usage-accounting systems, to be reduced into billing items by arbitrary ISP data-plan business rules.
---
And hopefully — but I'm not holding my breath — this would be done using open protocols and with FOSS-replicable software, such that eventually the ISPs could stop relying on Apple and Google to provide this only for specific devices, and instead could ask for their 3GPP hardware-integration vendor of choice to provide this as part of their 6/7/8G head-end system, in such a way that any device leased an IP by said head-end could make use of it.
What would such a standard look like?
Well, we're talking about a vendor-neutral, architecture-neutral abstract machine runtime, tuned to host persistent, network-mobile, IO-bound, highly-concurrent workloads "cheaply" on a highly-multitenant basis.
And Ericsson, one of the largest 3GPP equipment providers, created a runtime a few decades back that coincidentally fits that set of constraints quite closely — so closely, in fact, that they'd likely just vaguely wave at it and say "here, standardize this." (After giving its architecture a few security tweaks to achieve multitenant safety guarantees, that is.)
Just imagine: every mobile app on your iPhone, embedding its own little BEAM-bytecode relup package; one built by XCode, compiled from a combination of project source files written in a "network dialect" of Swift, plus Erlang library dependencies. And then pushed, on app launch, to a secure-multitentant Erlang VM sandbox, run by your ISP in its edge colo. Wouldn't that be just wild? ;)
On the telco side, as I understand it the CDN hosting isn't seen as a revenue centre - rather, it's there because it makes their pipe faster than the competition's (for the principle use cases of most of their customers, anyway).
Because Apple/Google can only run so many data centers. And these DCs are all too high-latency / "out of the way" of the connection path between the user's device and the devices it wants to talk to, to make "diverting" the connection path to one of these DCs worth it.
Besides that, though — doing such "diversions" would massively increase cost, because it would turn a one-backbone-path (or sometimes even zero-backbone-path) route into a two-backbone-path route.
Instead of,
and/or, you'd instead have: Apple/Google would have to pay for the bandwidth to connect the two users to their own network — where, in the case of a user running e.g. a BitTorrent seed-box, this is an unbounded downside risk! (Remember that by the design of such an "offload" system, it does not charge the customer for network traffic that transits through it — only for compute. Just like Cloudflare doesn't charge for basic proxying, only for Cloudflare Worker compute time. This will only ever make financial sense if your edge compute is "in" the existing connection path — i.e. hosted in the same DC as one of the path's existing hops.)Now put yourself in Netflix's shoes. You don't want to deal with residential ISPs; they're usually large conglomerates that have more bargaining power than a random commercial colo facility in a city would have. But you do anyway. Why? Because, by doing so, you get a connection to the ISP's customers that is:
- extremely low latency
- extremely low bandwidth cost (because there's no need to traverse a backbone for any hop — the CDN's data can stay on the un-congested "residential streets" of the ISP, without ever needing to get on the "highway" where it would have to fan in and wait on an "on-ramp")
- never-degraded QoS — because their traffic on the residential ISP's network is just delivered with a default priority class (like everything else on that network, other than maybe the residential ISP's own OTT VoIP-based POTS service); whereas, when traversing any backbone, other providers who were willing to pay more per byte (because they had far fewer bytes to send and valued them more — which is basically every provider compared to a movie streaming service) get higher priority classes, narrowing the virtual pipe [= re-allocating to fewer circuits on circuit-TDMI backbone routers] and so degrading service for the CDNs whenever other higher-priority-rate traffic wants to flow.
The argument for Apple/Google putting their edge compute offload into residential ISP DCs would be exactly the same. It takes a network path that the customer was already establishing anyway, and adds a place for a "user-programmable virtual router" to live in that network path — without lengthening the path, making QoS worse, or any of that.
---
But let's go at this another way: if the cost/benefit worked out in favor of Apple/Google doing this in their own DCs... then why wouldn't they have already offered this years ago?
Apple might not be a B2B cloud provider that has hypervisor clusters ready for customer use — but Google certainly is. Why isn't "Android Offload Services, powered by Google Cloud Run on ARM" a thing?
What I said above (doing so creating a network "diversion", doubling backbone connections, wrecking QoS, etc) still applies.
But I think there's another obvious reason:...
It might work for a usecase you have in mind but in general, it can't work. And it assumes that the world is a perfect place where the incentives are aligned and that ISPs cooperates and that you'd actually want to expose your phone. As if the tech we have (mobile networks, phone batteries, coverage) would allow for it, which it don't.
And somehow denial of service attacks is only worth mentioning when you have a dedicated PC with proper 100+mbit internet but not when you have a battery powered phone with wireless connection?
And I truly fail to see how all anyone could even argue that all that complexity would be better than direct access.
The main issue has always been the logistics of defining a brand new allocation policy that won’t run out of IPs in 6 months, because otherwise nobody is going to bother spending a bunch of money to support an address block which will most likely not even work anyways.
The first is, particularly on opening it up for public assignment, all of the compatibility issues mentioned. It's not enough that in 2035 99% of things could be compatible when talking about existing internet infrastructure - it has to be 100% going to work (without hoping everyone just catches up, this isn't a separate internet like IPv6's rollout is) if you want to bet interoperability of the established internet on it. The alternative is let people use it but not on the internet, that way they own their own interoperability with themselves or anyone directly interacting with their internal network. If this were a security issue I'd have different feelings on it but it's about convenience so it isn't enough that it's possibly more convenient to most 10 years from now. Especially since the problem and solutions will have evolved so much 10 years from now anyways.
The second reason is, even if it does work out 100%, it's not much a solution to anything anyways. IPv4 pressure has started causing places with large blocks of old IPv4 space moving to NAT, carries deploying double NAT via CG-NAT, cloud providers looking at public IPv4 address fees, and the entire mobile world being IPv6 first with some going as far as IPv6 only with NAT64. Each one of these solutions already in place has resulted in more usable IP space than this would open up so this solution could neither replace them or stop them from being needed in the future. Each existing alternative (however non-ideal) is either a longer term mitigation or step towards a long term solution to the shortage instead of a small basket of addresses to throw on the fire. In particular the NAT64 and 464xlat solution have proven to be a long term permanent answer for the vast majority of the cases people thought they needed these kinds of addresses for that would have left them less prepared when these too ran out. I particularly don't buy the idea that the world just so happens to need exactly a /4 more of space and everything would be alright - it only looks that way because of the above methods being pressured into happening. Remove that pressure and it (at best) can hope to delay the rollout numbers of those methods by a decade.
All that said I'm still in support of opening it up for private use cases like enabling 0.0.0.0/8 in Linux [2] did (think use cases like another /8 of space you can slap your Docker container NATs behind or your HA networks behind for software that doesn't support v6). Not only do I think that would result in less pain for the internet at large I think it would actually result in a larger decrease in IPv4 pressure long term by giving more spaces to NAT to/from for those not ready/able to NAT64 all of their internal services.
[1] https://news.ycombinator.com/item?id=39804231, https://news.ycombinator.com/item?id=32796355
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I suppose the multi-AZ stuff makes things more complicated, but my $5 VPS host had IPv6 like what, ten years ago?
This does have one small benefit: since none of the large cloud providers seem to do competent IPv6, you can avoid scanners, scrapers, and other log polluters on personal services by just hosting them on IPv6.
Because they have all the IPv4 address they need and so do not see a shortage, unlike those that are not mega-corps and are struggling:
> I work for a Native American tribe in the PNW. We scrambled to get the reservation reliable internet in the later part of 2019. We managed to cover most of the reservation with wi-max and wifi with a fiber back haul configuration. We are now slowly getting more stable and reliable fiber to the home(FttH) service installed to as many homes as we can, but it is slow process covering the mostly rural landscape doing all the work in house.
[…]
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* https://news.ycombinator.com/item?id=35047624
Anyone who (a) got in early on the IPv4 address land grab, or (b) has buckets of cash, can 'safely' ignore IPv6.
Paul Vixie saw it coming, the very first example in the original SRV proposal (RFC 2052, 1996) is resolution of HTTP. Alas that this example was omitted in later editions. The new SVCB/HTTPS RRs (RFC 9460, 2024) are literally decades overdue.
For years a combination of gaps in policy, disjointed standards development, hoarding behaviour, and administrative laxity, led to substantial wastage of IPv4 address space that persists to this day, in part because multiple independent website tenants sharing an IP address was (and often still is) difficult.
Glossary
DNS: Domain Name System, how computers discover (or resolve) each other's numeric IP addresses from symbolic hierarchical names.
HTTP WG: HTTP Working Group, the standards committee(s) responsible for defining the application-layer protocols by which a web browser talks to a web server. Under the auspices of the IETF.
IETF: Internet Engineering Task Force, the standards organization for the Internet. Most famous for being the entity that publishes TCP/IP and the cherries on top.
LIR: Local Internet Registry, an entity that applies to be the holder of block-allocated IP address space. Typically ISPs and hosting companies that assign it for their use or onward customer use.
RIPE: The European peak body, a Regional Internet Registry (RIR), responsible for (amongst many other things) allocating IP space to the LIRs, ultimately under license from the global steward IANA. Sibling of ARIN, LACNIC, AFRINIC, APNIC (North & South America, Africa, Asia-Pacific respectively).
SNI: Server Name Identification. Before SNI was introduced to SSL/TLS, the only way to tell which HTTPS origin was being requested, was by server IP address.
SRV: A specific type of record in the DNS that allows lookup of a service (e.g. IMAP mail, XMPP messaging, LDAP directories) for a given domain name, to return a set of hostname(s) that actually provide that service, and the ports on which it is available. This enables multi-tenant services on shared IP addresses and thereby conserves IP space.
/19 network prefix: A large chunk of IPv4 address space, corresponding to 8192 unique IPv4 addresses. Refers to the first 19 bits of the block of (32 bit) IPv4 addresses being allocated. Back in the 90s a /19 was a common granularity of allocation from RIR to LIR and could be granted with a low bar to justification. Mathematically, 2^(32-19) = 8192.
Address record: A specific type of record in the DNS that maps a hostname to an IP address. Technically referred to as an "A record" for IPv4 addresses, or an "AAAA" record for IPv6 addresses which are literally 4x the binary length.
Allocation, Assignment, and Announcement: IP address space is allocated in blocks by RIRs to LIRs, who then assign smaller parcels of it to specific purposes such as retail hosting and internet access, and announce it at internet exchanges and to their peers for actual traffic exchange. Very often, the quantity of assignment failed to justify a large allocation, leaving space unassigned i.e. unused, and in some cases unannounced, but still hoarded, with incentives for hoarding becoming perversely stronger as the addresses ran out and the policy screws started to tighten ca.2005-2011.
Apex: in "example.com" it is the "example.com" rather than "www.example.com". For marketing purposes, almost every entity wants their zone apex to be directly reachable as a website, which means placing an address record at the apex. This excludes using the apex address record for any other service but HTTP, which I have always regarded as downright antisocial. Since alias records (a.k.a CNAME records) aren't permitted at the apex, it also makes DNS management harder when you have frequent changes to make, as in the highly dynamic world of cloud-based services, or even just want to point your website at a third party hosting service without having to edit your zones whenever their IP addresses change.
Normative: A formal declaration in one technical standard (e.g. SMTP) that it depends in whole or in part on another standard (e.g. DNS) for full specification. It is unusual for a TCP/IP-based IETF protocol standard to omit DNS as norma...
I remember the first time I used "characters" in front of a non-technical friend instead of just the more common "letters" or literally anything else.
(Also, this tangent really isn't worth spending time on.)
https://www.rfc-editor.org/rfc/rfc9565.txt
https://www.rfc-editor.org/rfc/rfc9598.txt
https://www.rfc-editor.org/rfc/rfc9574.txt
https://www.rfc-editor.org/rfc/rfc9582.txt
So why try to force byte into this role?
(agreed)
Technically this is a subset of the rule that CNAME ("canonical") records cannot co-exist with any other record type with the same label. e.g. it's illegal to have `foo.example.com` be both a CNAME and an A record. Since an SOA record is required at the zone apex, you can't also have a CNAME record there. :-(
We now have it, but still need to use a hack to cname an apex e.g set Google.com to bah-bahs-tenant100.s3.amazon.com. Adhering to the spec we need to set google.com to an ip address e.g 8.8.4.4
Likewise for HTTPS, though in that case multiplexing arrived only maybe 10-15 years ago instead of 25.
A proposed Internet "standard" suggested that instead you would do a different kind of query, not a query for the IP address but one for a "server". It's a kind of query that is very underused on the Internet but it's related to how you find printers on a local network for example. In that case you would do this kind of query (called SRV) for http.tcp. example.com and that would always be able to return another hostname, thus getting rid of the issue with apex domains.
You’re forgetting the underscores: It’s actually “_http._tcp.example.com”. The underscores are there to avoid any possibility of collisions with host names, since host names are not allowed to contain underscores, but are generally allowed in the DNS.
That's not true. I have an server with a single IP and a number of Domains that are served from that single IP like http(s)://example.com http(s)://example.org http(s)://example.de
All of those delivery completely different websites from that single domain. You are mixing up two tings: DNS with HTTP(s). In DNS its right but for HTTP(s) it doesn't matter.
Even if you are using CNAMEs, that's only been possible recently due to hacks/workarounds, as bonzini said.
Because of no SRV records for HTTP and no CNAME for apex records, you can't follow "one true name per IP" without giving an IP to every domain.
I run may own email server now for more than 20 years. Only recently I in-cooperated public RBLs to deny spam. I still don't like it to depend on external services for this, which flag spam incorrectly.
I think this is what people elsewhere were referring to when they said that SRV records would be nice for HTTP.
edit: Aside: I ran my own first mail server over 30 years ago. :-)
A compounding issue is that CDNs (or GitLab/GitHub) want to be able to change their IP addresses, so they don't want you to use an A record.
Dns SRV record = IP:port
Not sure why SRV never really caught on for most internet stuff.
(Edit: SRV records are hostnames, not IPs, so I guess it takes two lookups?)
In addition to canonical name & port number they also include priority & weighting values, although the usefulness of these depends on the service.
SRV might not be super visible in the application developer's lane, but swim outside and there's a lot of it about. It's foundational for SIP, for example (IP telephony). Email remains a tremendously significant internet utility and SRV is used, albeit not universally, for discovery of client endpoints (SMTP submission, IMAP, CalDAV etc). However, SRV hasn't replaced MX for SMTP between MTAs, perhaps because MX already does basically the same and was established years prior. And, well, Jabber is dead, but XMPP was another fully worked demonstration of SRV's capability.
In more local environments SRV is used for resolution/discovery in Active Directory (Microsoft) and Bonjour (Apple) - if you listen to the wire on any local network you'll often see a ton of SRV over mDNS or DNS-SD. Perhaps ironically, one of the objections that sometimes arose to using SRV for HTTP was from Active Directory sites with zone cuts at _tcp.example.com and facing additional complexity in any transition.
Binding IP addresses into the TCP tuple is the thing that makes saddest about the could-have-been Internet.
Lack of adoption of SRV records is a close #2. So much IP space would have been saved. Load balancing and failover would have been so much easier.
(32-bit addresses is up there too...)
Using SRV and increasing IP address space “by 64k” is only valuable for large single consumers such as AWS.
I never really got the point of the new records either. From what I can tell, they're just SRV records. A separate record class could've made sense with DANE, but nobody implemented it.
They are not everywhere though. They are not on the greater Internet. They are not on residential networks. I have access to the full 65535 TCP ports everywhere in the world on my average Internet connection.
These middleboxes you speak of are appliances paid for and placed inside of corporate LANs. They can pay to put more modern ones, or just getting rid of them.
The point is that these middleware appliances we often use as a scapegoat exist only in well-controlled private networks. Why should we care about them?
Perhaps for the same reason we only stopped caring about IE 6 after its usage dropped below a tiny percentage.
For better or worse, making your website available to as many groups of people as possible, regardless of their browser selection or network configuration, has been a long-standing goal in the community.
If your website isn't available to folks at the offices of company X because they use appliance Y, through no fault of user Z's, well...that's not ideal, is it?
https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6
We did? Half of the sites I find posted on HN literally only work in ONE single browser.
Personally, I would've preferred to ignore the spec incompliant middleboxes, or even report an error about something meddling with the connection to the user when it's obvious they're the cause of any connectivity issues. That's not a very popular approach for spec designers, though, because they're afraid people will blame the new software rather than the Enterprise™ NetworkProtection© box they paid six figures for. After all, the software is what changed, not the box!
Let's just put ipv4 on life support, reclaiming 240.0.0.0/4 is a bad idea.
Even your phone or tablet on the campus wifi got a unique public IP...
Of course there were firewalls in place and all the incoming ports were blocked, but doesn't that seem like a big waste of IPs?
The university owns 155.92.0.0/16 and every machine on the network gets a 155.92.x.x IP address.
https://ipinfo.io/AS11500/155.92.0.0/16
Is this normal? Or shouldn't the IPs all be NAT'd behind a few public IPs?
Seems like a waste to me to have it where every device on the campus network gets a public IP, like every students phone, laptop, tablet, desktop, game console, etc.
That said at this point I kind of half-seriously prefer keeping the IPv4 space as exhausted as possible if it’ll even slightly drive adoption of IPv6.
Or voting. Should really everybody get a vote? Most people don’t really need to vote. This is evidenced by the huge numbers of people who don’t vote. And most people who do vote do it badly, anyway.
/s
Remember, NAT breaks IPv4. A NAT-ed network is not fully compliant IPv4 network.