AWS IPv4 Estate Now Worth $4.5B(toonk.io) |
AWS IPv4 Estate Now Worth $4.5B(toonk.io) |
"Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...
"Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible.
"Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses.
The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels a need to migrate to IPv6.
E.g.: How many customers would you gain by supporting IPv6? Generally zero. That doesn't sell well internally when the network team is asking for a budget.
The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden.
The sudden bit will happen when IPv4 address will cost $1K to $10K annually. At that point, customers will be reaching those IPv4 endpoints via three layers of proxies or NAT gateways, and IPv6 will be noticeably faster, more reliable, and free.
So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.
This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers.
For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today.
IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.
One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64
Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now).
You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen.
Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.
Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging.
However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
You need new protocol, sure. But do you _have_ to switch from "1 almost fixed address per interface" to "tons of addresses per interface and dynamically changing"? Did you have to present it as a separate protocol to apps? Did you have to use : in representation, breaking most ad-hoc text processing code? etc..
if they goal was "herr is a new verion of IPv4 with same semantics" then we'd just need to wait for new kernels and libraries to come out, and it would be all done years ago.
There are billions of phones so sure, they should be on ipv6. ipv6 is a kind of super NAT that few people bother to learn
Sorry about that ipv6 committee
That would have saved a lot of pain.
NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users.
NAT and by extension CGNAT are the unsung heroes of the Internet.
Though granted, there is support and support. I use hyperoptic in the UK as an ISP. I replaced the native router and I still can't figure out a way to get an IPv6 address.
I don't think that's true.
Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done?
There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I tried to access it from my home. Lookups from other points of the world could resolve the IP but not my little home network. I felt forced to continue paying the 2€ I paid for a IPv4 address just because of that.
Edit: to make it abundantly clear, I'm looking at you, Vodafone. You suck.
NO!!!
this is what the parent comment meant about ipv6 design. Add an octet and that's it. Same protocol with same rules just a bigger address.
It may be a different version of IP but the protocol and supporting protocols like ARP and DHCP just need to support the new IP.
The reason IPv6 failed is the same reason why when new devs join a team, they find how everything is wrong and try to fix it all and leave a bigger mess than what they started with. You solve problems one step at a time. Overhauls are only justified when your objective is specifically to improve the whole system.
"The reason for the slow IPv6 adoption is that there was no financial or business pressure."
That is only part of the reason. The other part is it is a pain to use, there is no way to use it without also supporting v4 and on top of that you have to learn and adapt other new protocols, addressing schemes, gotcha's and much more.
Just add a freaking octet!
Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations.
I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.
That's a fresh alternative to the boiling frog metaphor.
The big issue is that the router vendors hated it, the OS vendors hated it, the programming language people hated it, and the software writers hated it. How do I know? NOBODY WANTS TO ADOPT IT except by force, even now.
Worryingly, pro-IPV6 people are consistently arrogant and dismissive. Essentially their argument always boiled down to "ha, you'll be forced to use it eventually and then I'll be RIGHT!!!" which is why IPV6 people hate NATs with a vehement irrational passion, because it floated IPV4 for, what, two decades at least?
I'm guessing it is because IPV6 was a tossed-over-the-wall protocol that didn't get reference implementations from the biggest router vendors first. Here's a very very very very very very troubling link:
https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/networ...
That is Cisco bragging about it's IPV6 website on a pdf from 2011! 2011! Fifteen years after the birth of the protocol. If Cisco did not have an IPv6 site up until FIFTEEN YEARS after protocol definition ... oh god.
Comcast routers weren't IPV6 functional back in 2015, at least they weren't on my cable modem. If an ISP that makes bank on renting and turning over its consumer routing hardware can't roadmap ipv6 adoption within 22 years... ugh.
And my biggest complaint about ipv6 is that they didn't increase the number of ports. Really. We have to keep shoehorning apps into 64k ports rather than a sensible 4 billion, but maybe there's some OS mapping concern with that, doesn't matter, the ship sailed.
https://en.wikipedia.org/wiki/Internet_Protocol_version_4
Somewhere in IPV4 is an options header (up to 40 bytes). Why that didn't provide the necessary space for some degree of backwards compatibility somehow is beyond me.
What should have happened is that the big router vendors got together and agreed on a standard protocol. Then the major OS vendors and language standards bodies got together and made reference implementations for basic networking.
Once that was working / adopted by next gen hardware and software releases, then things might have gotten rolling.
I mean, how much work was that relative to the mind boggling amount of work done to implement NAT and firewall traversal/busting code in, say, Skype? Ever seen those whitepapers? Wow are they doozies. Holy crap are people willing to write code.
This is all screaming at the darkness.
IPv6 is as backward compatible as is possible within this constraint. You can embed IPv4 space within IPv6, there is NAT64, tunneling IPv6 over IPv4 and many other transition technologies. It's not possible to design a protocol that is any more backwards-compatible.
Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html
FWIW I couldn't find the link to that post until finding it on one of the comments here, https://news.ycombinator.com/item?id=33894933 . That whole thread has lots of good commentary.
I still don't understand how people can defend ipv6. I remember the "we better get ready to switch to ipv6" noise a quarter century ago when I started my career. And yet we're still talking about how v4 addresses are worth billions. Ipv6 has been an unmitigated disaster. The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads.
The idea of 32 becoming scarce was laughable.
Also the complaint about ipv6 isn't a technical one, it's a usability one. Extending it to 48 bits would have been easy enough for people - like international calling.
Those 16 bits could be in hex, as a convention, so something like "(4EA7) 8.8.4.2".
However, I've constantly heard that the 128 bit hexadecimal with colons just looks too complicated and inconvenient.
You might be brilliant and find it easy but to a lot of people ipv6 addresses look like cryptographic hashes
IPv4 was designed for a handful of research institutions. It is not the fault of the designers that it "escaped" the lab into the 'real world'.
Okay we are back in 1992 and are wearing a mullet. 'The Internet' is still a relatively small number of mostly university and government sites, and is barely used for anything important, so a flag day seems pretty feasible.
But the biggest problems of all: You can write an IPv4 address on a phone call. You might be even able to remember it. Not the case for IPv6, you need to be an expert in Hex and remember the specs design. I can't do it as a developer, I don't think normal people will be able to do it either.
IPv4 is useful because it's just a number (at least from a person's perspective). It works. Just add a letter to it and then you have x26 the capacity.
IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate, and it failed at that.
"Well-known" NAT64 prefix: 64:ff9b::
Everything is so confusing in numbering and addressing: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=006...
=
If problem was allocation, we could have added one number in front: 123.114.123.130.200
Now for backward compatibility:
If your device, operating system and application are compatible with IPv6, congratulations, you receive 123.114.123.130.200 and talk natively in IPv6.
Otherwise, if you are on an IPv4 device, you receive only a portion of the IP address but from a fake IP starting with 250.x.x.x
inetnum: 250.0.0.0 - 250.255.255.255
organisation: Future use
status: RESERVED
For example, your local home/ISP router can send a truncated version of the IP address: 250.123.130.200 and then it's the responsibility of this translation router to remember the routes at least for some time (and there is always possibility to hardcode routes if needed).
=
A bit like Stateful NAT64 or "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments" or "464XLAT: Combination of Stateful and Stateless Translation"
But now, with all these millions of standards it's such a productivity loss for any tech working in networking.
Similarly when switching CPUs over from 32 bits to 64 bits, the idea was to change the size of words stored in memory, not change the size of words and change the alphabet in use.
I actually feel antagonist towards the designers for it.
RIPE had a policy to extremely rate limit allocations from their last /8, which is how they were able to continue allocating for an extra 7 years. The other RIRs had no such policy.
https://www.ferc.gov/internet-protocol-version-6-ipv6-policy
interesting idea
Make of that what you will.
Send the bill to end users is not what should be done.
All this ipv6 endeavour already cost me a lot of time learning and troubleshooting software, and sometimes realizing that some modems doesn't have a good ipv6 stack and the best solution is to turn it off.
The price for IP for connections is already builtin to the price. Also, ISPs just use CGNAT to share IPs with multiple customers when they are short, It makes sense to charge more for static IP.
How long ago did you do try IPv6? These days it should just work. If your router doesn’t work, get a better router since it is broken.
Honestly, I've never had such a strong incentive.
How does one buy a block of IPv4 as an individual? (If that's allowed)
After you purchase it, how does it come into your possession?
How do you utilize them?
EDIT: I guess this is the cost to _rent_ an IP per month and not the cost of _owning_ an IPv4 address.
At some point. At SOME point, IPv6 will work in enough situations that we can ignore the small minority of situations where it doesn't. If even 90% of the visitors to my web sites could connect on IPv6 I would change tomorrow, but it just isn't that high yet.
But in some sense it’s even more wonderful that your phone can (probably) render 1080p60 video without skipping a beat. Not to mention that it is transmitted over thin air, originating from someone (probably) thousands of miles away.
And even more wonderful is that no one thinks of it as anything special, at all.
I also don't think there are many places willing to announce your ultra specific route because it's not great for routing tables.
You can also acquire and use a /24 out of a class A or B block, thanks to this newfangled thing called CIDR. ;)
Thats what I have in my RIPE Account.
RIRs do allow you to transfer your IP blocks to other organizations but you can only do so if the receiving organization proves to the RIR they have a good reason to hold those blocks of IPs. This valuation is based on what a typical IPv4 owner receives in exchange for that transfer of IPv4 addresses.
Just like any assets which you hold a lot of, if AWS dumped their IP addresses on the transfer market, the price of IPv4s would likely fall significantly so I doubt they could actually get that price for all their IPv4s.
[1] https://en.wikipedia.org/wiki/Regional_Internet_registry
Said another way, AWS owns approximately 3% of all IPv4 addresses.
Essentially, how are they better than IPv6 addresses?
Having something that's addressable on the internet is trivial when you have a public IPv4 address.
Don't do that.
Fast forward a couple of decades and everyone needs 10 IPs each. You have your phone, your laptop, your work computer, your TV, your door lock, your door bell camera, your thermostat, etc. And every web site in the world traditionally needed its own IP. And so the world pretty much ran out of those 4Bn addresses.
The "Powers That Be" developed IPv6 which solves this, but not everything works properly yet when connecting with IPv6, so if you want to make sure your software/hardware is guaranteed to connect to everything then you need one of those precious IPv4 addresses.
Now, in the early days of the Internet there were so many addresses that they were handed out like Halloween candy. And many people had so many they didn't even use a fraction of them. So now you can make good money selling your old addresses as they are prime real estate.
Your phone perhaps, but the rest of these devices never need a public IP address.
Based on data from the IPv4 brokerage ipv4.global, the cost of IPv4 addresses has seen a notable increase. In 2014, the price ranged from $6 to $24 per IP, depending on the size of the subnet. By 2021, this range had jumped to between $23 and $60 per IP. The fluctuation between the lowest and highest sales prices for each IPv4 address remained relatively stable until 2021, when we began to see more significant spikes.
The peak prices for IPv4 addresses in 2021 were observed in September and October. During these months, IP addresses allocated by RIPE NCC and ARIN fetched as much as $60 each. Specifically, a /24 block from RIPE NCC sold for $15,360, while ARIN's /22 and /23 blocks went for $61,440 and $30,720, respectively.
Fast forward to October 2022, and the highest sale of the year was recorded: IP addresses allocated by ARIN sold for $60.70 each, or $15,540 for a complete /24 block. Despite these peaks, the IPv4 market appears to have reached a more stable pricing structure, especially when compared to the more volatile price shifts seen in 2021.
$30-35 is the low end per IPv4 address over the last year.
I've tried running web servers as pure IPv6 plays, which I would happily, happily prefer. It is just not possible. Even things I'm convinced will work, like cellphones, which are mostly IPv6 these days, won't connect.
You must be an RIR member to hold IPs and there are membership dues that you must pay each year to maintain your allocation. Once you are a member of an RIR you just have to make a request and at least with ARIN that request and fulfillment is free.
BGP is a very insecure protocol. Most of its "security" are enforced by money and contract.
Is this how BGP hijacking is done?
You need to provide justification, and frankly it's not that big of a challenge to get a /22 which is what I got. As long as you can show how you would like to use them and over what time frame, they will allow you to go through with the acquisition. An ASN is not required to get any IP block. You can always associate your IPs with any ASN that you want so long as that ASN owner is cooperating with you. I went ahead and grabbed an ASN for ease but some ISPs will allow you to use their ASN.
You also do not have to purchase an IPv4 block from someone. You can go through the normal IPv4 request process, however the waitlist [1] is now over a year long for IPv4. However IPv6 are given out very quickly. IPs you acquire this way are "free" to acquire with your ARIN membership. Your membership dues are determined by the assets you hold, there is a fee schedule [2] and you need to pay it annually to maintain your membership and ASN/IP assignments.
I encourage anyone interested in understanding this process to go through it, it didn't take a ton of time nor did it cost a lot in the grand scheme of things. Being an ARIN member also entitles you to be a part of how IPs are governed in the region you acquired them in. They will occasionally send out surveys and you can vote on issues.
I wonder if sanctions may ever apply to the internet itself and we may see a break up of the internet into regional internet's.
And if we want to ensure global connectivity these associations would need to be completely independent and voluntary standard and such fees would be paid to an international standards body not beholden to any particular nation's whims?
What if nations started adding intercontinental NAT gateways acting as the entry and exit points between their national boundaries and the rest of the world.
2. You are assigned a BGP Autonomous System Number (ASN) as part of the process. The IPs are assigned to your ASN.
3. You sign a peering contract with ISPs and peer with them using BGP on your router. You use your ASN to announce your block to have traffic routed to/from your router.
One of the tragedies of IPv6, IMO, is not having a better/streamlined process for end users to get allocations without all the red tape. There's tons of space, let's pretend it's the 90s and give away IP blocks to whoever asks. Either require ISPs to give static allocations or make it easier for getting a personal block. No, prefix delegation is not good enough.
This is by design. If we let arbitrary routings of /64 blocks pollute the global routing table shit is going to go sideways as the rest of the net scales up and up. We made that mistake with IPv4 and the only reason our routers haven't gone thermonuclear keeping up with the announced routes is we literally ran out of address space.
We're not going to get the IPv6 equivalent of IPv4 /24s announced ever again. While minimum prefix lengths aren't hard enforced (yet), unless you have the means/reason to be multihomed using /48s you're pretty much going to be under the hierarchical routing of your transport or last mile provider.
Mandating something like a static /56 (physical location locked) to be available at no extra cost if the customer asks for it, would work fine, though. I'd even accept requiring this only for contracts that allow more than one customer device to access the Internet simultaneously. Yes, a phone plan with two SIMs on one contract would already trigger this.
Having a ton of people/businesses with their own announced and unaggregatable /48s would add a lot of entries to routing tables.
If you're asking for a minimum sized range, you don't have to justify more than one ip. It's not super hard to find somewhere where you can be multihomed either, although it's unlikely to be at your home. (Maybe ask isn't exactly the right verb, assuming ARIN/RIPE are out of addresses, you're asking for them to process a transfer that you paid/will pay the current responsible party for)
Also, there is no organization that can require anything of an ISP’s addressing plan. The IETF and the RIRs are associations, not governing bodies.
Just buy service which does what you actually want - rather than insisting it should be mandatory which means everybody has to pay for it. I have static allocations (both IPv6 and, very small, IPv4) because I care. Most people don't care.
Good luck, update us if you do it!
If you run only online service, enable ipv6 on it.
Basically, help move the needle on the chicken and egg issue of adoption. Move more traffic to v6 as much as you have control over.
Most content distribution networks (CDNs) support IPv6 even if the back-end is IPv4. For most web sites, a CDN is a good idea in general, so just use one.
For developers: don't hard-code IPv4 as an assumption. E.g.: don't validate network addresses with an IPv4-only regex, and don't store addresses into a 32-bit unsigned integer. Most SDKs and APIs have supported IPv4/IPv6 dual-mode addresses for like... two decades by default. Just don't... undo... all that effort!
Generally: Use DNS instead of IP addresses. Do it properly by respecting TTLs and using multiple upstream DNS servers in a fast failover configuration. This is not the default in many systems, especially Linux distros used in servers. Many admins "prefer" raw IP addresses because they think "DNS is unreliable". It isn't, it's just the default config that's poor.
- Compatibility bridges for v6-only hosts to connect to v4 servers
- The IP address market encouraging old v4 allocation owners to sell off their space (at the expense of a bloated routing table)
In 2009, IANA and the RIRs created a process for buying and selling IP addresses. Which is something they never wanted to allow, but their hand was forced by the abysmal levels of v6 adoption back then. Two years later IANA would allocate the last /8s, and the RIRs that got those allocations would exhaust them in the years following[1]. The only virgin v4 address space remaining is reserved specifically for ISPs setting up v4 compatibility for native v6 networks.
You did not notice this because the v6 transition has already happened, and it was boring. In 2023, Google reports 40-45% v6 adoption[0]. This is largely due to LTE making v6 a mandatory feature. Had we kept mobile traffic on v4, networks would've adopted shedloads of CGNAT, and even then that hits a wall when you start running out of ephemeral ports to disguise addressing information inside of. This would have resulted in significantly worse behavior for smartphone users, especially in heavily populated countries like India (which have far higher v6 utilization).
[0] https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...
The article you're responding to is a dramatic demonstration that it has happened: Amazon's IPs would not be worth $4.5B if we hadn't run out. It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free.
iphones are v6 only as are indian consumer connections.
Sigh
And then random stuff just doesn't work. Various websites hang, various widgets just don't load, etc. Then I turn it off and everything gets better again.
I'be been too lazy to diagnose why exactly it doesn't work, I just figure it's easier to run with it off. At some point a website I really want to access will require IPv6.
Hopefully by then whatever is broken will be fixed.
Before I switched ISPs a few weeks ago to one without IPv6, I was with an ISP with IPv6 (dual-stack) for about five years and had zero problems.
In fact it worked 'too well' initially: when I was still IPv4-only I had put a bunch of Facebook domains in my iMac's /etc/hosts file pointing to 127.0.0.1 so that all those little icons would stop loading. At some point I noticed they were back.
After some head scratching over a day or so I realized that Facebook was IPv6-enabled, and so the icons were loading because AAAA records were working. Adding ::1 for Facebook in hosts fixed things.
kek - i too am waiting
Tell that to 45% of the Internet.
Also, half of the bingo items there are intentionally humorous, and if you are taking those items literally (I wouldn't be able to tell, you never listed them out) - congratulations, you are part of the bingo :)
true, for now.
sometime it will reverse and i am exited about what will happen in/with the "legacy internet"
Hi, I've adopted it for many reasons and I'm happy. You'll need to update your count. Seriously though, there's lots of people who adopted it - you'll need some more data for a generalisation like this.
> We have to keep shoehorning apps into 64k ports
With ipv6 you typically get a whole range assigned to your machine rather than a single address. Why expand ports, when you can assign millions of apps to different addresses, with the same port that correctly identifies the service type? As a bonus, this already works with DNS AAAA entries so you don't have to mess with SRV to find the right port.
They also did offer IPv6 availability for a short while as a test, but that was quickly shut down, so there is probably a technical issues they can't figure out or they would've kept the trial system running for longer.
Either way, Github isn't communicating, so it's hard to tell if this is indifference or incompetence. As an end user, the distinction doesn't really matter.
So no router can route it sensibly and no existing client works ? How would that help ?
How would that be an improvement over the existing situation?
https://en.wikipedia.org/wiki/Thread_(network_protocol)
Some IoT devices are now IPv6-required.
Still unsure of the benefit of dual stack, but there are numerous costs.
Take a look at the state of RPKI. ROA validation is common these days, and ASPA validation will be common soon. You still need to manually validate that your peer truly represents the AS that they claim to, but if that's been done, ROA+ASPA validation prevents unauthorized announcements.
Absent RPKI, people have been filtering based on IRR for ages, which will not necessarily prevent unauthorized announcements, but will require an attacker to leave a paper trail when making one.
But good ISPs filter the prefixes their customers can announce to only those they actually own.
Then you have shitty providers that dont do it, and thats how you get BGP hijacking.
And you cant do this just from any connection, fyi.
You will need a datacenter, cloud host or residential ISP that actually allows you to peer with them and announce routes. This isnt a standard thing you get just by being a customer.
i was struck by an issue in this area a few years ago and i think it was fixed by tuning gai.conf to prefer v4 because there were some repo servers that had broken v6
edit: but this was quite a few years ago, from grepping my IRC logs, somewhere around 2016!
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
I could request a /32, but a /48 is definitely enough for me. Might request a second /48 at some point maybe.
I don't think that's an informed, thought-out take. The internet works just fine for all intents and purposes if you have some services reachable through IPv4. There is no obligation to shut down IPv4 in order to work with IPv6.
If you're able to go through your daily work seamlessly hitting services with IPv6, that's a successful migration. It matters nothing if an unrelated service hasn't went through their migration yet.
2/3 of their internal services don’t. You can do ipv6 only vpc but not if you wanted to use rds or ecr or …
We can debate whether that's a good thing or a bad thing, but that is the way IPv6 is supposed to work.
Pretty much every cell network gives the phone an IP on the subnet, and then uses NAT, or CG-NAT[1] to share the same public IPs for multiple mobile devices.
On IPv4 or NAT there's just 65535 ports to check. On a /48 with privacy extensions there's 2^80 addresses to go through, which from an external point of view don't remain constant. You can't even ping all of that.
Are you sure about this? Do you have a link with details?
If I disconnect from WiFi and use the SIM card currently in my iPhone, and I go to one of the websites that tell me my public IPv4 and IPv6 address it shows that the mobile internet connection I have with this SIM card is IPv4 only.
iPhone 14 Pro
actually there is a v4 default route on the wwan-interface that appears to be a p2p link (192/32) probably to a cgnat.
besides 127/8, there are a only v6 routes, a lot of them.
There can only be ~4.3 billion IPv4 addresses, which means that mathematically IP addresses are severely limited - you can't assign even one single globally routable IPv4 address per human. That's why we have NAT and its evolution CGNAT in the first place.
However we got layers upon layers of closed-source middleboxes and everything ossified as a result.
Understand very little about the problem space and complain about the best-compromise solution that the people who do know what they're talking about came up with. It's a very comfortable position to be in, I recommend it to everyone.
Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.
I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.
IPv10. The next IP version number that is unassigned, that is conveniently 4+6.
Basically something that is not breaking compatibility with IPv4 and doesn’t require those dual network stacks nonsense.
If you are from The Netherlands I can recommend Freedom Internet [1]. A /29 (6 usable IPv4) costs 17 EUR/month (VAT equivalent included). That is less than 3 EUR per IPv4 a month.
I have no idea how they manage IP allocation internally there though.
IMO we'll see this happen in our lifetimes.
edit: I've been running dual-stack with Windows, macOS, iOS & Linux for at least a decade now - I think it's closer to 20 years than 10! I've never seen it be like the parent post for my personal use, but I have seen it broken like that in places I've worked with incorrectly configured routers/firewalls.
edit 2: this isn't a good idea for v4 either, but it's less broken than v6!
I’m sure I do. But that’s sort of the point. I only use standard commercial hardware with the default config.
If that doesn’t work out of the box, what chance does someone who doesn't have my decades of networking experience have in fixing it?
Granted I’m probably more sensitive than most because I know what network issues look like. Most people probably just think some things are slow sometimes.
My ultimate point though is that this is probably a barrier to adoption.
1. people who just use the router their ISP provides
2. people who go and buy off the shelf consumer routers/wifi - eg Netgear, Linksys, TP-Link
3. the kinds of people who run home labs and use small/medium business targeted routers/wifi like pfSense, VyOS, Unifi, Mikrotik, or even things like Juniper SRXes etc.
The first group will get a 'blessed' and hopefully well tested IPv6 configuration when their ISP rolls it out, and I'd expect minimal problems there. Certainly haven't noticed anything big in the UK with some of our biggest ISPs rolling out v6.
The third group will inevitably have teething troubles, but v6 works okay on those kinds of platforms once you know how to configure it, from my experience.
The second group is where a lot of the pain will sit, imo. I've found consumer routers have really bad IPv6 implementations (things like broken prefix delegation, broken firewalling that can't be changed, IPv6 negotiation not working over PPPoE, weird RA settings, etc). The firmware on these kinds of devices is usually not great, and things like hardware acceleration engines in router CPUs are also frequently missing acceleration paths for v6 for things they already accelerate for v4. It will get fixed eventually, but it's going to be a pain point for a lot of years to come.
I'm in that 40%. I use IPv6 on my phone whenever it's not in my house.
It's possible that your block is a part of a legacy allocation, they are governed differently.
This timeline suggests that it's still a legacy allocation. The new governance structure does not apply unless you sign an RSA or LRSA agreement with ARIN.
https://www.arin.net/resources/fees/fee_schedule/#legacy-reg...
So you won't be subject to the new fee structure.
If you want to route then you will need an ASN and an ISP willing to announce them. So long as you are up on your LSRA dues I don't see how you won't be able to utilize them.
That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4".
Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers).
>NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience
I think there would be many more that wanted this if it were trivially easy to do
>but there has to be some sacrifice to keep the Internet running for the billions of users.
What's the sacrifice in using IPv6?
I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs.
> What's the sacrifice in using IPv6?
Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge.
If it were really just a "flip of a switch", everyone would've done it by now.
Gamers get errors about "strict NAT." Traditionally the solution to this problem caused by NAT was to forward the ports. If their ISPs has chosen CGNAT port forwarding is impossible.
VoIP calls that have one way audio are a symptom of reachability issues caused by a firewall or address translation problems. VoIP services have adapted to IPv4 NAT by relying on proxying instead of STUN but CGNAT really degrades reliability.
Smaller newer ISPs that can't obtain one IPv4 address per household are incurring signicant CGNAT costs. https://news.ycombinator.com/item?id=35047624
Video chat uses the kludges of TURN when peer to peer connectivity does not work. This increases costs for the video chat service who in turn require a paid subscription as they will not relay traffic for free.
BitTorrent and file transfer services need direct IP connectivity. If p2p file transfers worked on any network we would not need to mind Gmail's 25MB attachment limit, or pay for intermediary cloud storage.
A CGNAT is a stateful component which makes it expensive to operate. Failover to a backup is hard, as is scalability with this kind of components. And then there are legal requirements. You have to know what user had which IP address at a given time. I'd rather invest in dual stack instead.
It can open the firewall simply by sending something. If it can communicate its public-facing ipv6 address/src port number to the remote side using a SIP proxy (ok, for this signalling, you need a relay), it can receive traffic. No TURN needed either.
What scenario do you have in mind?
I sure as hell wouldn't want to be the canary in that coalmine...
What is confusing me is the Netherlands. We only have about 13% adoption. I'm on one of the largest ISPs KPN and get 10/10 on IPv6 tests. Is this because I use a custom router? I'd expect it to be a lot higher since apparently KPN supports IPv6.
A small number of people use routers you can buy from Amazon, or in a store.
A really tiny number of people use more professional equipment at home.
The problem is, most IT professionals fall into one of the smaller two groups, so they get more friction than others, and that leads to them having more reluctance to roll out v6 at work, etc.
Its an app.
None of the entries in the cellular routing table is IPv6 with my current SIM card. So I am doubting more and more the claim that iPhone is somehow IPv6 only.
Seems more like some people have carriers that choose to provide them IPv6 only, and because of that they think that it has to do with the iPhone itself.
PDP_IPO (CELLULAR DATA)
default via 10.10.67.87 UGSC
10.10.67.87 via 10.10.67.87 UHr
10.10.67.87/32 via link#3 UCS
10.255.91.156 via 10.10.67.87 UGHWli
17.57.144.87 via 10.10.67.87 UGHWli
224.0.0/4 via link#3 UmCS
255.255.255.255/32 via link#3 UCS
The second option may not even work with more paranoid firewalls, which might not allow TCP SYN packets on existing connections.
Make sense now why Cloudflare would be one of the only companies that could handle it!
(not worried about them, just curious)
If you were BGP peering then you'd probably get a real route into your local table though.
So yeah, some stuff would probably have just broken, but that's the risk you take using parts of the IP space you shouldn't be using!
To be honest I feel as bad for them as I do for Hamachi, when their (otherwise quite nice in that it was a spiritual predecessor to Tailscale!) overlay VPN service fell apart once 5.0.0.0/24 became publicly assigned.
Anyone who can either man-in-the-middle your traffic or is the intended recipient will be able to do fingerprinting based on your TCP/IP traffic. In addition, a lot of your traffic will likely be HTTP(S), in which case the recipient servers will also be able to set cookies, and perform various additional forms of fingerprinting to learn even more about you. The idea that hiding behind a single IP address gives you any protection is delusional.
* VodafoneZiggo has 40-45% of the home market, but also 25-30% of the business market and 20-25% of the mobile market [1]. They seem to offer IPv6 on their home and business connections, but not on their mobile connections [2, 3, 4].
* KPN (35-40% home/biz, 25-30% mobile): IPv6 for homes (except older modem types) and mobiles, but not by default for businesses [5, 6].
* Odido [ex T-Mobile] (30-35% mobile, 5-10% home/biz): no IPv6 across the board [7, 8].
* Eurofiber (20-25% biz): has IPv6 [9].
* Delta (5-10% home): no IPv6 [10].
* Unspecified smaller ISPs (0-5% home/biz, 10-15% mobile): unknown.
* Finally, a number of wholesale access providers, where the customer presumably has a say in IPv6 support.
This works out to 75-90% IPv6 in homes, 45-60% in businesses (ignoring wholesale) and only 35-45% for mobiles.
So, the mystery is not solved, because this data still doesn’t support Google’s 13% figure…
[1] https://public.tableau.com/app/profile/autoriteit.consument....
[2] https://www.ziggo.nl/klantenservice/internet-wifi/ipv6-bij-z...
[3] https://community.ziggo.nl/t5/Internet/Instellen-ipv6-zakeli...
[4] https://community.vodafone.nl/t5/Archief/IPv6-op-mobiel/td-p...
[5] https://www.kpn.com/service/internet/ipv6.htm
[6] https://zakelijkforum.kpn.com/internet-bellen-9/ipv6-werkt-n...
[7] https://community.odido.nl/bekabeld-internet-492/ipv6-wannee...
[8] https://community.odido.nl/netwerk-en-verbinding-559/wanneer...
[9] https://www.eurofiber.com/nl-nl/snel-internet
[10] https://www.delta.nl/klantenservice/vrije-modemkeuze/, expand ‘stap 4’
The Ziggo shift would have made a huge impact on the national total.
The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4.
Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change.
You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
No it is not:
* You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
* You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant.
Basically all the stuff that is happening with IPv6.
You're re-inventing IPv6.
There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.
Option 1: "6to4" https://en.wikipedia.org/wiki/6to4
Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 + DNS64
Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike)
Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling
Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment
Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications)
Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism
The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
Section 5.5:
CRITERION
The protocol must have a straightforward transition plan from the current IPv4. Category: Informational
Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within.Clients can be IPv6 only and ideally need a CLAT installed to handle the edge case of IPv4 literals in apps that don't use DNS. The ISP's internal network can be IPv6 only. Only this NAT64 translator needs to speak both IPv6 and IPv4, and only for non-IPv6 traffic.
Then it's not IPv4 and is not compatible with IPv4.
> perhaps we could look at the 240.0.0.0/4 reserved for future use block
What's the current rate of v4 address space consumption? How long will this block last?
> and add more address bytes in the payload or something.
This is, by definition, not backward compatible.
See my suggestion as some kind of NAT-PT at scale. With a better marketing name and user experience.
The problem is indeed hard because no one manage to find a solution at scale since 3 decades.
The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.
No. The NAT64 hack involves intercepting the DNS requests and rewriting the IPv6 packets in flight so that the IPv6 only clients see outside IPv4 hosts as IPv6. Among many issues, it breaks any end-to-end encrypted protocol that includes IP literals, such as FTP and SIP.
Also, NAT64 presents no immediate benefit to a client upgrading in a IPv4 only environment, since it still doesn't allow two clients behind NAT64 gateways to connect to each other if there isn't an IPv6 connection between them. So the same old IPv6 self-fulfilling tragedy, everybody must upgrade before anybody can see any benefit, therefore nobody upgrades (or uses NAT64).
The main benefit of a backwards compatible packet format is that IPv4.1 islands see each other from day one in the legacy IPv4 internet and get the full benefits of the new protocol, without any configuration or tunnels. The "encapsulation" seen by legacy hops is in fact the canonical, definitive packet structure, there is no temporary transition technology that can break or needs to be configured.
> the problem of IPv4 clients trying to connect to servers with only IPv6 addresses
This is not a problem that can or should be solved, and it's not the problem significantly preventing IPv6 adoption. A non-upgraded client will just see an IPv4 internet, just like an USB 1.0 won't be able to use USB 2.0 speeds.
The difference is that, while a software&hardware upgrade to IPv6 won't bring you any new connectivity without extra configuration from your upstream provider, an IPv4.1 upgrade will instantly allow you to see (and connect end-to-end) to all existing IPv4.1 islands and hosts, using only your legacy, IPv4 connection. The hierarchical extended address space (IPv4 subdivisions) is immediately available, incentivizing adoption without risking connection issues, while the upward extended space becomes available when you have a native IPv4.1 connections, just like with IPv6.
2. Of course there's no immediate benefit for IPv4 clients - there isn't in your proposal either! It's a compatibility measure, allowing IPv6-only clients to talk to IPv4 servers. (I make that distinction because under no scheme can an IPv4 host initiate a connection to a host with no IPv4 address.)
3. I have no idea what you're talking about with the idea that NAT64 requires IPv4 clients to talk to each other over an IPv6 subsegment. I suspect you're thinking of a different transition technology solving a different problem. NAT64 provides a virtual IPv6 subnet containing the entire IPv4 address space. IPv6 clients can send packets to this subnet, at which point they are routed to the nearest NATting gateway and passed into the v4 internet after packet rewriting.
4. FTP and SIP containing IP literals is an irreducible incompatibility, which cannot accommodate an address size change without intrusive packet rewriting anyway.
You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
That is called DS-Lite and we have it
Still doesn't solve a problem of old clients not being able to access new servers
No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user.
The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc.
> Still doesn't solve a problem of old clients not being able to access new servers
See sibling comment on why this is not the right problem to solve either.
So… NAT.
Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.
Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.
No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly.
A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path.
It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.
Do you mean applying some kind of network address translation?
> So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.
Ahem.
as well you should. the phone has to keep working.
my point was that smartphone ecosystem is ime very well established in the v6 internet and i doubt that any carrier assigns public v4 here.
So there is a bit of a demand, especially here, for forward compatibility.
There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself.
Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course).
When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.
> Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.
464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device
nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit.
> That thing is there to stay for 5-10 years, and you just work around it as best you can.
IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat
> nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device
How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.
This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.
If you're unlucky you'll also have to sacrifice a goat to appease the JVM gods. JVM behaviours vary hugely across implementation, version and underlying platform. Not to mention the short sighted decision made by many sysadmins to disable IPv6 completely...
The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches.
But Ipv6 features take a few extra bytes and are a problem.
Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around.
No one pays for the extra free gigabyte that Chrome takes over.
Sure they do. It just doesn’t show up in Chrome’s metrics so Chrome doesn’t care about it.
* Start-up time of other applications. If a program needs 1 GB of RAM, and Chrome is holding all but 512 MB, then the program must perform multiple allocations, waiting for Chrome to release its cache after each one.
* Smaller cache in other programs. Consider a program that can run with 4 MB of RAM, but could use up to 1 GB of RAM to cache intermediate results and improve performance. Such a program would check the amount of RAM available and scale their own cache size accordingly.
* Competing caches in multiple Chrome instances. Multiple independent Chrome instances, such as from Electron shells, each try to cache as much as possible until RAM is exhausted.
From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.
The existence of fridges with twitter integration proves that there is a need to a Lettice to tweet.
There are all kinds of things that exist, steam-powered motorbike among them. Not all of them exist for the right reasons.
Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?
The uses that I found while searching weren't very convincing, I was hoping you could give an example.
It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.
Mostly everyone could handle this, not just CloudFlare.
The last public analysis was done in 2010 by RIPE and APNIC. At the time, 1.1.1.0/24 was 100 to 200Mb/s of traffic, most of it being audio traffic. In March, when Cloudflare announced 1.0.0.0/24 and 1.1.1.0/24, ~10Gbps of unsolicited background traffic appeared on our interfaces.
Also having 64-bit for the network address (and 64-bit for the device) does have certain benefits that make it easier to use than shorter addresses in practice for a single entity, since one can hierarchically model the network and do things like <my_network>:<site-id>:<vlan>. So even in absence of DNS one doesn't quite have to remember 128-bit of information for every device.
the pyramids in egypt took over a lifetime to build; a marvel of engineering, as theyve lasted thousands of years and noones had to build replacement pyramids. the problem, though, is noone in todays culture needs pyramids.
A typical ISP will get allocated a much larger allocation like a /20, which allows them to allocate a /56 for each of their customers while still having a few bits to play with. But all starting with the same <isp_network> prefix.
With IPv4 you will have many separate fragmented networks that have no numbers in common. And this will only get worse over time.
The most recent anonymous editor to the IPv6 address article on Wikipedia has address "2602:FBF6:0:0:30C6:7069:6DF0:FD24". An IPv4-like notation of that would be "9730.64502.0.0.12486.28777.28144.64804".
There are some technical advantages to doing things that way of course, but they are arguably rather outweighed by the administrative disadvantages. The protocol could have been designed so that typical layer 3 addresses were not much longer, nor harder to type or remember than IPv4 addresses are.
Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6.
Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas.
There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay.
It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.
What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two?
T-Mobile was gave a presentation on going IPv6-only in 2017:
> For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64.
* https://www.youtube.com/watch?v=nNMNglk_CvE
So they started in 2007.
Whatever ISP you're with has probably had at least 2-3 tech refreshes in which IPv6 hardware has been available.
For the CPE, Free in France had IPv6 in 2007:
This is probably because the idealized world of "only network engineers" is leaky. Programmers, sysadmins, people trying to get their network printer to work, non-specialists have to interface with network addresses constantly.
Saying they shouldn't is not a description of reality. Not everyone who needs to set up or diagnose a network do so as a career path.
Almost all hardware and software has supported ipv6 for many many years. The humans using it are the ones that shut it off or disable it. Unless you address the human behavior of why that is, this problem will not be addressed.
I claim there needs to be a friendlier, casual interface that makes people's lives easier. It can be a crude kneecapped sheen so long as it addresses the needs of the general user. Then they'll use ipv6, not for ideology or virtue reasons about the commons but because it makes their lives easier
I don't really understand the use case for typing up addresses either, copy pasting is going to be more precise, and if one can't read 8 quartet of letters one shouldn't be near networking equipment either.
Heck ibans are about as complex and the general population is coping just fine
I have an IPv6 address but haven't bothered memorizing it or giving it out because it would just be more hassle.
game.latticeanimal.net. 3600 IN A 1.2.3.4
PS: As a developer, I often read logs and go ”oh yeah, that’s just our satellite office IP”. 192.168.1.110 is the network printer, etc. There’s no hope of recognizing IPv6 addresses at a glance the same way.
There's different "rules" from IPv4, but as a developer those mostly don't matter and if your network engineer wants you pattern matching your network's machines, then you can just as easily pattern match your network's machines as with IPv4. (That said, there's privacy reasons your network engineers might not want that, security through obscurity and all that. That can be just as true in IPv4, but fewer companies have enough IPv4 address space to truly obfuscate the network patterns. Life is harder for network engineers in IPv6 not entirely because it "has to be" but because "privacy and security is 'easier' if we use a more complicated approach to IPv6 than we did with IPv4 where we would just sequentially number machines within our allotted space".)
I'm not complaining as if to say "yeah guys, let's stop the ipv6 rollout and do ipv10" or whatever. But I think it is useful to see why the problems of ipv6 came about. A great comment from one of the linked HN threads said "ipv6 was a product of it's time", a time (I put it at mid 90s to mid 00s) when there were a ton of over-complicated, over-engineered specs that were designed by committee. Some examples:
1. XML, and all its complexities and incompatible versions (I still have some PTSD from some Java XML version incompatibilities), vs. what the industry discovered to be the much simpler and now much more widely used JSON.
2. The insanity of SOAP vs. something like REST.
3. The original Enterprise Java Beans spec. Feel like "'nuff said" is good enough here, what a nightmarish shit show that was.
Thankfully I think the industry has largely learned its lesson when it comes to valuing simple even if imperfect specs. But I still totally disagree that "ipv6 is the best we could have done".
You can criticize IPsec and mobile IP which was tacked on to the spec. But starting from scratch, a core IP v6 stack is easier to implement than a v4. The TCP parts is downright nasty in comparison.
Most importantly, IPv6 was developed in the open. IETF is the counter example to design-by-committee. That's true today, and that was doubly true twenty years ago.
Every discussion since them mostly concerns resurrecting old ideas about either impractical extensions (misusing port numbers and flags to extend addressing, none of these schemes have been proven practical), more efficient address space allocations (which would have bought us a couple of years, at most) or various ways to tunnel traffic in backwards compatible ways (which is what we did back when 6bone was a thing, but which is not useful anymore).
The mailing lists are completely open. You can join any one of them today, and people did. You can still follow how the discussions went in the archives. Hopefully no one has suggested that IPv6 is the best we can do, but that the process still works and that anyone capable and interested is welcome to attend.
As to whether the industry's obsession with complexity has faded, I bring you Kubernetes.
I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes.
That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago.
All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net.
Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything.
There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly.
And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.
The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware.
Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth.
And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay.
The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.
Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.
The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem.
The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number.
And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.
Other changes were made in the early days, like the introduction of dialing, then long distance dialing.
SLACC, interface-specific link-local address both look good in paper but cause lots real life headache.
When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.
Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim.
Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server)
My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6.
How can this work? Well, there are two scenarios:
1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa.
2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.)
Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range.
This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space.
Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).
The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6.
The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).
How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.
That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.
> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients
I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.
I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/
It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server?
One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.
https://www.google.com/intl/en/ipv6/statistics.html
Yes, the IPv6 migration has taken much longer than anyone expected. But this argument would have made more sense in 2015 when we were looking at 5% IPv6 deployment and very erratic growth. But it's not, we've been looking at 10% of the market gaining IPv6 support for the last 3 years and are now at 45%. Now granted, this is likely to be largely "new" devices, e.g. in mobile networks and in countries like India where these were hidden behind CGNAT before. But these are exactly the type of devices that an IPv4 extension header couldn't have reached either.
It's a dumb post, to the point I think it must be a deliberate troll. The parts that are possible don't solve any relevant problems ("my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is not a point in favour of your new protocol), and the parts that solve relevant problems aren't possible.
Lol, I'd like to send this to DJ Bernstein, let him know that random Internet commenter thinks that one of his most well-known essays "must be a deliberate troll." Glad HN doesn't support emojis, not enough facepalms it the world for this one.
For example his Qmail was conceptually a very well designed email server but the email standards kept evolving and I'm fairly sure at some point he just said "Qmail is feature complete and secure, no more new features and patches". Like, what? It's networked software, that's not how any of this works.
Who's rejecting the good enough in favor of the perfect, now? This thread is full of "IPv6 is not perfect, so we must reject it".
That's so much simpler than simple src-natting your clients at the edge of your control and routing your outgoing traffic based on a policy at your natting device /s
You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6.
> You could instead move this "port" directly into IP header in backward-compatible way
If you're changing the meaning of the headers, it is by definition not backwards compatible.
This is a fundamental and unresolvable problem with "making it backwards compatible"
Of course, we could extend the address space by further breaking the layering of routes, and baking in support for higher layer protocols into routers. We can certainly stuff more address information in HTTP headers, so the web could be extended to essentially arbitrary size by simply requiring routers to look not just at source and destination IPs and source/dest TCP/UDP port numbers, but also client and server HTTP headers. SIP looks a lot like HTTP, so the same solution could work there. TLS already has support for additional headers, so we could also do extra NAT at that layer.
Hell, AWS could then use a single IPv4, and just rely on HTTP/SIP headers or TLS extension headers to know the actual destination! Of course, if you want to run another L7 protocol, tough luck - tunneling it is for you.
>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet
This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.
The problem is hard because despite everyone's wishes, it's got nothing to do with technology. All migrations are about economics and incentives, IPv6's qualities as a design (it's a long, long way from perfect, but I'd argue that it's good enough) are irrelevant.
For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.
Two decades ago I was a member of a ISP consumer group, and we discussed it with a couple ISPs back then. They all were working on a planning for it (one smaller ISP even already implemented it back then!). Apparently in other countries ISPs were allowed to behave irresponsibly.
Really, the only way to force such incompetent ISPs out is if governments get involved, or if all/most backbone providers and IX operators set a date where IPv4 will become very expensive, and then one where it will be switched off...
MAP-T shoves the source and destination IPv4 addresses and ports into IPv6 address. This makes IPv4-IPv6-IPv4 NAT possible. Which means it is possible to run IPv6-only network with IPv4 at on the customer network and edges.
If I had to guess the futur, the industry will most likely go towards something like few expensive IPv4 owned by major cloud and internet providers and crazy recursive NAT setups everywhere. Because that works without breaking stuff.
At the time it provided a real simple desktop tool that you would install, sign in to your account name, and it would auto-update a (very) short TTL DNS A record for you. (Generally in the form of username.dyndns.org, but as I recall donators could also bring their own top level domain.)
We've got mDNS today to fill some of that gap, but I still wonder if it would also still be nice to have a "no click" desktop tool in 2023 that could quickly update very short TTL DNS AAAA records for you on a subdomain of your choice, and sort of lament Dyn's many pivots (and eventual Oracle buy out) because that original idea still has legs even if it didn't survive the 90s. (Though maybe this time as a true non-profit internet service or operating system feature.)
It was extremely common with Teamspeak.
And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
It's human and behavior driven and addressing that is a matter of packaging, process, promotion, product, presentation... all those marketing ps.
Also it's increasing at ~5% a year, so in 12 years it'll be at ~104%.
China is a laggard again here. I earlier saw that they were the largest windows xp holdout left. Sure it's only. 0.5% but many places are down to 0.1.
However, SLAAC demands that each device is given a 64-bit prefix that it then chooses many random 64-bit host addresses from, without any other rhyme or reason. So, if you want to know the IP of a host you want to connect to, you have to remember at least a 64-bit number that changes every day by design. Add to that some extra bits for the particular part of the network you are in.
So your IPv6 is more like <isp-assigned-prefix, 32-56 bits>:<internal-net-prefix, 8-32 bits>:<random-host-address, 64 bits>. Human friendly this is not.
A machine using IPv6 privacy extensions would have two addresses; one that changes, and one typically based on the MAC address that remains constant.
If you are in the local network with that machine or otherwise are supposed to be in-the-know, you'd know it's fixed address and connect to that.
Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?
There's something that works even better as an ultra simple firewall: An ultra simple firewall!
> why give an IP to something you don’t want accessible by the outside world?
- You might change your mind about it needing to be accessible by the outside world, and if it already has a global address you don't need to renumber everything.
- Addressing and routing aren't the same thing; it can be useful to have globally unique addressing even without global reachability.
Thus proving that ipv6 failed in it's mission to get rid of nat
Not being able to route directly doesn’t seem to be a major issue to me. It for sure require more computing power in routers but also adds some safety and privacy by design.
Look at the bigger world around you.
I am, right now, involved in a major cloud migration. Having overlapping, constrained RFC1918 space and also having to NAT everything is presenting an enormous set of constraints and risks. It adds literally zero benefit.
Life would be infinitely easier, and we could provide so many more capabilities if everything could just have a routable IP address. Unfortunately, I'm not in charge of our addressing policy.
NAT is an awful, short-sighted hack that causes many more problems than it solves.
I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.
I'm not sure this is true. There's a lot of warts in the way IPv4 was put together (ARP is a tire-fire of badness for example), and the opportunity was taken to implement those in a better way. Lots of network engineers are very happy about that.
I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain.
I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.
If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere.
Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.
But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?
> What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses."
He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address."
You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses.
> maybe I should reread the article a bit more generously and less literally
No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.
Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.
All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.
So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).
Funny, because the reality is that the software has for the most part been written and the hard part is acquiring v6 addresses. The problem is it isn't just a matter of acquiring a v6 address, it's also supporting the software that the v6 address runs on, and having it work the exact same way as v4.
The answer is that I'm actually talking about a huge number of IPv4 sites. There's nothing special about my site. When the same situation is repeated at N sites, the code is written only once, while the trivial requests and the trivial configuration changes are repeated N times.
.
.
.
Well, I'm looking at a much larger group of users, and most of them aren't putting even five seconds into IPv6. They have better things to do. If the IPv6 configuration isn't automatic, it won't happen.
I'm unfamiliar with SIIT, but I bet it doesn't get us closer to the "magic moment" or we would be flocking to IPv6 addresses:
The magic moment for IPv6 will be the moment when people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. That's the moment when the Internet will no longer be threatened by the IPv4 address crunch.You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying.
> even if you magically could keep using the IPv4 address in IPv6 (however that would work)
It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].)
> Adding the address to the server is the easiest part of the whole process.
The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2].
In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway).