Dagger2
(Oh, and fix their stupid "on-link /56 but we lie to you and claim it's your /64" setup while they're at it.)
Rust doesn't guarantee that code in `unsafe {}` blocks is safe. This is also covered in the manual.
v4 routers don't understand and can't route v6 packets, so you can't use the same route for both of them. v6 packets have to go to a router that understands v6, and v4 packets have to go to a router that understands v4.
I have no idea what "or a superset in the later stages (shared down to /32, v6-only in deeper subnets)." is trying to say.
It's perfectly possible to turn v6 on without changing anything at all about your networking. When e.g. Windows Vista came out, hundreds of millions of people did exactly that.
Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
The people designing v6 knew from the start that interoperability with v4 was a requirement. It's written right into the list of requirements for v6[1], right in the same place that they say that a flag day is never going to happen.
Why do you believe otherwise? The RFC is right there for anybody, including you, to read.
[1] https://datatracker.ietf.org/doc/html/rfc1726#section-5.5
It has "IPv4-compatible IPv6 address"es: https://datatracker.ietf.org/doc/html/rfc2373#section-2.5.4, and then a way to get them over networks where not every hop supports v6: https://datatracker.ietf.org/doc/html/rfc2893#section-5. You don't need new DNS or DHCP to use these, or SLAAC. There's no anycast relay. They can go over v4 hops.
Why spend all this energy complaining about v6 not doing something that it did do?
> The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then
It seems your only real problem is that you completely missed the early part of the transition. We've been in what you're calling the later stage for twenty or so years now.
But in general, it's mostly because v4 and v6 can end up taking different routes. If an ISP has any BGP peers that are v4-only or v6-only then they can end up sending packets for the same host to different peers. In the worst cases, one of them can go to another country and back again. It's usually harder to get ISPs to fix this on v6 than it is on v4, because the problem is visible to fewer people (in part due to happy eyeballs itself).
For smaller websites, DNS caching can play a role. If there are fewer clients requesting AAAA records than there are clients requesting A records, there's a chance that a client requesting both will get a cached A record back quickly but have to wait for full resolution of the AAAA record. This is unlikely to happen for the most popular sites (because another client will probably have triggered the caching) or for the least popular sites (because the A record will also fall out of cache for those), but there'll be a band somewhere in the middle that's affected by this. There's enough v6-capable clients around these days that I doubt this has a major impact now, but it's interesting that caches can cause unfairness like this.
[1] https://www.google.co.uk/intl/en/ipv6/statistics.html#tab=pe...
The spec minimum is more like /56, so maybe you're forced to use slightly more than 48, but not all 128 bits.
The problem in this thread stems entirely from v4: they're being moved onto CGNAT (which is NATed v4), because the v4 address space is exhausted, and this is only a problem because the hospital relies completely on v4. None of these problems were created by "IPv6 people". The IPv6 people created the thing that solves these problems.
This hospital has had twenty years to gradually move things over to v6 which would have rendered the CGNAT a non-issue, but instead they've done zero work towards that and are completely unprepared to deal with the realities of v4 running out. Had they been forced to use v6, they would've be fine.
> when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.
Another opposite. What usually happens is that IPv6 gets blamed for any network problems, even on networks that don't use it.
I've seen people run software that failed to connect to a server's v4 address over a v4-only network due to broken v4, that have then blamed v6 for the problem. The error message from the software was somewhat misleading (it only prints the last connection failure instead of all of them), but even so.
It's usually the people not doing v6 that are delusional about it. Even on HN there's a steady stream of people complaining that v6 didn't do <thing that v6 did do> or that it's impossible to do <thing that's possible to do in v6>.
I do realize that you're likely to hit bugs or lacking support or something somewhere or another, but that's what the past twenty years of gradual transition were for. We've all put a ton of effort into buying you more time to figure this stuff out in. If you squandered all that time and then need to deal with everything after it becomes a big emergency, that's not v6's fault.
> get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.
If you wanted a nice orderly transition, you needed to start doing it earlier. Instead everybody is fighting to be the last person to transition, and you probably won't be able to beat Walmart on that fight.
I've more or less come to the conclusion that the people who think v6 is bad don't know what they're talking about. If none of these people can come up with a better approach than v6, that suggests that v6 really is more or less the best approach available.
> after almost 3 decades and so much the adoption at 50%
I think we all wish it had been faster, but the v4->v6 transition is the first time humanity has ever done a transition like this, on this scale, involving so many disparate networks controlled by so many people in so many countries. How do you know that 50% at 3 decades is slow? Maybe this is just the par time for this kind of thing.
And you already don't have to use all 128 bits in v6. You're forced to use about 48 of them, but the rest is your choice. You can just... not use some of them. It's fine.
(On home Internet you'll probably need your ISP to handle the announcements, like they already do for your v4 address.)
My experience is more the opposite. I keep seeing people say things like "I don't do v6 at home because I don't need it". These people are outright telling us that they're not going to start using v6 unless we make them need it.
Note that I didn't say "migrate to" v6. They're not even willing to do the first step of that ("start using v6"), even with no pressure to do the last step ("stop using v4").
I read an anecdote from Facebook that they had huge trouble getting their developers to stop writing v4-only code. Eventually they ended up removing v4 from their developer machines, who all of a sudden were able to write v6-capable code -- and it didn't take long for them to start asking when they could drop support for v4.
People will moan and moan and moan about v6 until you make them use it, at which point they discover that it was never as bad as they imagined it being.
Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.
You have 2002:47b1:11ab::/48. If your ISP supports it, packets sent to that /48 will be delivered to you as native v6 packets, otherwise they'll be stuffed into a v4 packet which will be sent to 71.177.17.171. Or there's ::ffff:71.177.17.171 which will reach you using unmodified v4 packets.
That's two different ways your v4 address is present in v6.
Being an IETF draft means nothing at all, as covered in this IETF draft: https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/
(This behavior is a deliberate choice from Wireguard. They claim it's not broken, but... it's broken.)
They thought about these things and put features into the protocol to support them. This is, once again, the opposite of your belief that they didn't.
Android does now support IA_PD, so the people who need to track IP use via DHCPv6 requests should now be happy. (We'll just put aside the question of whether doing that even makes sense in a world where devices can be told to use any IP.)
What more do you want from it?
What could they have possibly done differently to make you happy with it?
> people who either worked for the likes of Google who were aching for a globally unique identifier per device
v6 doesn't give you globally unique device identifiers. Devices get IPs from the network in v6, just like they do in v4. You're either thinking of MAC addresses or perhaps things like HIP (https://datatracker.ietf.org/doc/html/rfc7401). I guess there is Mobile IPv6 which allows you to take your address to another network, but then there's also privacy extensions which prevent your machine from using the same IP for very long, so it's still not a unique identifier for your device.
How else would you do it? Forcing every packet to reserve space for every possible option (including all future ones) seems obviously worse.
With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.
None of it does anything particularly amazing, but that's kind of the point -- the programs that people are generating are for the use cases that are too personal, trivial or specific for anyone to have bothered making a software package for.
There are a number of big ISPs in Europe that that have a "new" native v6+CGNATed v4 platform, and an "old" native v4+no v6 one. That's where a lot of the "I had to ask the ISP to disable v6 to get inbound connections" comes from -- the actual relevant part was getting out from behind CGNAT, and the loss of v6 was just a side-effect caused by the ISP moving you to their old platform.
Inbound v6 should generally work on those ISPs. If it didn't... I'd be tempted (perhaps unfairly) to blame the user for not configuring things properly, or their software for not supporting v6. A lot of people will give up and blame a problem on v6 when they would have found and fixed it instead on v4.