> During this period, I was instructed to delete her contact and the text messages between me and her from my phone. I complied, as I was scared to lose my job.
This is so unbelievably naive, I'm flabbergasted. Well, great lesson for OP: Never burn anything that could help you, and if instructed to do so, make backups or lie that you did so.
Yeah and this distinction explains the fact that because China's Great Firewall blocks Google, this website shows 4.66% adoption as a reflection of that. I think China's IPv6 support rate is actually much higher than that, maybe a little over 50% because of its central initiative to increase IPv6 adoption?
Outside of hobbyist niche uses, sites won't start being hosted IPv6-only. The financialization of IPv4 addresses will simply get worse and be even more pay-to-play than it is now. Amazon raises the price of IPv4 and everyone goes along as a cost of doing business.
My prediction is that sites will be half-IPv6 only; backends will be IPv6 and IPv4 traffic will get proxied to IPv6 by CDNs / edge LBs. I think CloudFront for example supports that scenario, avoiding IPv4 costs (in theory).
that may be true, but not being able to access hobbyist sites still feels like "being locked out" of something. My ISP provides /48 IPv6 addresses for free, and I already run a couple sites only on IPv6 - because an IPv4 would cost 20 bucks a month - it's not important enough to me personally to pay that.
It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it. I thought I would see IPv6 take over in my lifetime as the default for platforms to build on but I can see I was wrong. Enterprise and commercial companies are literally going to hold back internet progress around 60 to 75 years because it's in their best interest to ensure users can't host services without them. Maybe even 75 years might be too optimistic? They are literally going to do everything in their power to avoid the transition, either being dragged out kicking and screaming or throwing their hands up and saying they can't support IPv6 because it costs too much.
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
Nearly all ISPs these days are deploying IPv6 for their mobile networks and core service networks, especially in less developed markets^1. The reason is simple, a cost justification. What doesn't exist is a cost justification for Enterprises to deploy IPv6, and for ISPs to deploy Residential / Corporate Internet IPv6.
IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example, most cloud providers are now charging for IPv4 addresses when IPv6 is free. Small changes like that push in the right direction.
I don't even know why clouds offer public IP addresses. In my opinion all clouds should only have a gateway that routes via host header for millions of customers. IPv4 should be a special priv for special situations at a higher price. Then these clouds could own maybe 20 IPs total instead of millions.
> In my opinion all clouds should only have a gateway that routes via host header for millions of customers.
This is incompatible with TCP/IP networking. In TCP connections, (sender_address, sender_port, receiver_address, receiver_port) is a unique combination. Those numbers together uniquely identify the sender talking to the receiver. For a public webserver:
* sender_address is the client machine's IP address
* sender_port is a random number from 0..65535 (not quite, but let's pretend)
* receiver_address is the webserver's IP address
* receiver_port is 443
That means it'd be impossible for one client IP to be connected to one server IP more than 65535 times. Sounds like a lot, right?
* sender_address is the outbound NAT at an office with 10,000 employees
Now each user can have at most 6.5 connections on average to the same webserver. That's probably not an issue, as long as the site isn't a major news org and nothing critical is happening. Now given your scheme:
* receiver_address is the gateway shared by 10000 websites
Now each user can have at most 6.5 connections to all of those 10000 websites combined, at once, total, period. Or put another way, 100,000,000 client/website combos would have to fit into the same 65535 possible sender_ports. Hope you don't plan on checking your webmail and buying airline tickets at the same time.
This is actually a good point. I guess 20 IPs per cloud infra company is probably too few. But maybe these cloud companies can have 20k IPs instead of 2 million?
I find the whole OVH web control panel atrocious. It's so buggy I couldn't even have my account deleted, not even after contacting their customer support (they just told me to fix it myself using their APIs...).
Imagine if one day someone came up with a "better" way to chew food, but you had to learn how to do a super complex jaw movement and it wouldn't work in restaurants. It has no obvious benefit to you. The only motivation is that a small group of obsessively passionate (but not in a good way) people say at some unknown point in the future food won't be edible anymore.
IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
It is nothing short of a miracle that devices can even get IPv6 addresses. SLAAC was supposed to replace DHCP, but it couldn't provide DNS server addresses. DHCPv6 was introduced to replace SLAAC, but this time they forgot to add a way to communicate a default route. This lead to Cisco, Microsoft, and Google all taking completely different approaches, and the IETF helpfully blocking any efforts at cross vendor standardization because of v6 zealots.
Meanwhile, everybody else is using a plastic skull that they carry around with them to pre-chew the inedible food, which is the majority of the food you can get these days.
"It's not inedible," they say. "Just let me get my skull out."
> IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
People said the same sort of thing about v4: that it was hard to configure because you needed to know four separate addresses (IP, netmask, default route AND the DNS server) and if you mix up any of these it doesn't work.
As it turns out, in both cases it's just a lack of familiarity, not actual difficulty. The super complex jaw movement is just a regular bite, but you puff your cheeks out a bit. Or er, something.
> This lead to Cisco, Microsoft, and Google all taking completely different approaches [...] but this time they forgot to add a way to communicate a default route
"There should only be one way to do things... wait, no, not like that."
Apple/iOS is probably one of the biggest individual drivers of IPv6 adoption. They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now
And the higher level libraries mostly do it for you, too, even if you directly specify IPv4 addresses in your code (due to NAT64 [1]). I think it only even requires special work from you as a developer if you're using low-level or non-standard libraries.
The problematic low-level libraries are standard, and effectively impossible to fully deprecate since they're decades old and part of the socket API.
I think currently Apple still helps you with these via "bump in the stack" (i.e. they can translate internal v4 structures and addresses into NAT64-prefixed v6 at the kernel level), but they probably don't want to commit to doing that forever.
I’m guessing the app works but their prod servers don’t? If they can point the app during review at a “self hosted” GitHub Enterprise server on a test domain with AAAA that would pass the requirement as stated by gp , without requiring GitHub.com actually support ipv6.
The prod servers work. The app does a DNS lookup, receives something like 64:ff9b::140.82.112.5 and 140.82.112.5 from the ISP's DNS servers, and then connects to 64:ff9b::140.82.112.5. Some part of the ISP network translates the connection into a v4 connection to 140.82.112.5.
The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the server does v6 natively or if the ISP is covering for a v4-only server via backwards compatibility. (Native v6 will probably perform better, but any site that wants to give up that advantage is free to do so.)
That’s DNS64, which is pretty annoying in practice. (For one thing, you can’t use your own DNS server anymore, but more importantly, anything using v4 literals will 100% break.)
What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.
> It has barely hit 50% and it's already plateauing.
Is it plateauing? From the chart it doesn't look that way at all to me.
You could say it's flat between August 2025 and now, but it also was from Jun 2024-Feb 2025, or August 2023-March 2024. There's just a lot of noise to it -- lots of short plateaus or even dips followed by lots of sudden jumps. Indeed, it seems to have a bit of a yearly cycle to it, suggesting we're at the inflection point of another jump upwards.
So it still seems to be growing strongly to me. The rate of growth has slowed maybe the tiniest bit 2024-2026 compared 2018-2023, but I don't see it anywhere close to plateauing yet.
> It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it
It's fine. IPv4 and IPv6 can be used at the same time. There's no hurry. Network interfaces support anything as long as both sides agree (nothing stopping you from building your own IPX network over MPLS).
People can move to IPv6 when the IPv4-as-real-estate speculators get out of control, and if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
I saw a news article that said something about India considering moving to IPv6-only? That's going to be interesting if the rest of the world moves to IPv6 and the U.S. doesn't.
> End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Exactly. To this point I went to a Comcast store to cancel my internet and the person asked me if I meant I wanted to cancel my “Wi-Fi”. I was very confused for a couple seconds.
v6 adoption is often an all or nothing, because if you run both stacks, you have to ensure they are consistent. While you can reasonably do it on your home LAN, doing it across an entire infrastructure is the worst.
Now you have to make sure all your subnets, routing, VLANs, firewall rules, etc work exactly the same in two protocols that have very little in common.
It is the equivalent of shipping two programs in different languages and maintaining exact feature parity between both at all times.
v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network.
I dont care about what your LAN adress space look like when I'm in my LAN, because we are not in the same v4 network. I am sovereign in my network.
With v6, everyone is effectively in the same network. I have to ask my ISP for a prefix that he will rent me for money even for my LAN. If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Also if I want any kind of privacy, I will have to manage privacy extensions and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface. How lucky am I to use such a great new technology.
Seriously v6 was created by nerds in a lab with no practical experience of what people wanted.
> v4 was built around the idea of multiple free standing networks linked by gateways
It was absolutely not. This is why early companies like Apple and Ford got massive IP allocations - each computer was expected to have a unique IP address.
NAT didn't exist until 14 years after IPv4 was created, in response to the shortage of IPv4 addresses, and in the RFC it is described as a "short-term solution", very clearly stated that his not how the internet is designed to work and it should only be used as a stopgap until we get longer addresses.
v4 and v6 were build around the exact same use cases.
> With v6, everyone is effectively in the same network.
Just like IPv4.
> I have to ask my ISP for a prefix that he will rent me for money even for my LAN.
Just like IPv4, if you need a static address.
> If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Compared with IPv4, where if you want some freedom from said ISP subnet, you are mercifully granted the honor of managing RFC-1918 addresses/NAT (granted you paid for a router that doesn't screw it up).
> Also if I want any kind of privacy, I will have to manage privacy extensions
...which are enabled by default nearly universally
> and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface.
Make up your mind. Are rotating, privacy-preserving addresses good or bad? The way it works in real life, not in the strawman version, is that you (automatically!) use the random addresses for outgoing connections and the fixed addresses for incoming.
This is exactly why I decided not to enable IPv6 on my colo. When money is involved, the benefits of IPv6 simply do not outweigh the risk, in my estimation. If my side gig eventually pays enough to pay a contractor to handle networking then sure, that'll be one of the first tasks. But when it's just me managing the entire stack, my number one priority is security, and for now that means keeping things simple as possible.
I switched my home ISP from cable (which supported IPv6) to fiber (which doesn't) and I've had a nagging disappointment ever since. But I guess consumers aren't really demanding it enough.
I think we'll hit a tipping point soon, just like with Python3 - for years and years it seemed almost stalled, then it became easier to start with python3 than python2 and suddenly everyone migrated.
> End users shouldn't need to set up 6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Which is what ISP are doing with 464XLAT deployments. IPv6-mostly networking and IPv4-as-a-service are things that are happening in real world right now.
Yeah in Japan my ISP even lets me choose which IPv4 provider I want to use, as the fiber network is IPv6-native and IPv4 is "just another service" like IPTV.
IPv4 is provided using DS-Lite or MAP-E depending on the provider.
I'm using OpenWRT and paid for a static IP so I had to manually configure all the details for the MAP-E tunnel in OpenWRT myself, I think typically the routers sold to consumers pick up the configuration automatically somehow.
Which provider are you using? I'm curious about this since there are not many OpenWrt guides for getting connected in Japan. Is your config similar to this write-up? https://github.com/fakemanhk/openwrt-jp-ipoe
I didn't need to do any configuration for DS-Lite or MAP-E, as DHCPv6 with a configured prefix got IPv6 working, although DNS is still broken when turning off IPv4 entirely.
edit: looking this all up again to refresh my memory, it looks like with my static IP the provider switches from using their default MAP-E to using RFC2473 directly instead, the configuration matches "IPIP" in this guide https://qiita.com/kouhei-ioroi/items/cf0c6228c5c1faef415a
I'm re-learning this right now since I kind of just set it and forgot it 2 years ago but while my provider typically uses MAP-E it looks like when you use a static IP it switches to using RFC2473 (IPIP6) directly without the extra port mapping that MAP-E adds ontop
> It has barely hit 50% and it's already plateauing.
That makes sense. The majority of IPv6 deployment is mobile.
The next wave of adoption requires ISPs start offering residential IPv6. Once this happens, router manufacturers will innovate around the IPv6 offering as a differentiator, making it easy to deploy by end-users. IPv6 wifi APs will then become ubiqutious and so forth across other services. Has to start with ISPs.
Mine does and it works so well that I actually have to turn it off when working from home as a bunch of the third party servers at work doesn't have any support for it.
That sounds more like broken support then. Not having any support at all (i.e. A records or v4 literals only) should just send you to whatever v4 transition technology your ISP offers, no?
My German ISP supports it now, which was the limiting factor for me, and a new VPS I just bought also does, so finally I was able to create my first personal AAAA record. I am hoping that we're seeing a tipping point. Again.
Is there a reason why adoption has been so abysmally slow? Like surely all the big players have updated their networking equipment by now, and surely every piece of enterprise-grade kit sold in the last 20 years has supported v6.
The only arguments I've ever heard against ipv6 that made any sense are that:
1: it's hard to remember addresses, which is mayyyyybe valid for homelab enthusiast types, but for medium scale and up you ought to have a service that hands out per-machine hostnames, so the v6 address becomes merely an implementation detail that you can more or less ignore unless you're grepping logs. I have this on my home network with a whopping 15 devices, and it's easy.
and 2: with v6 you can't rely on NAT as an ersatz firewall because suddenly your printer that used to be fat dumb and happy listening on 192.168.1.42 is now accidentally globally-routable and North Korean haxors are printing black and white Kim Il Sung propaganda in your home office and using up all your toner. And while this example was clearly in jest there's a nugget of truth that if your IOT devices don't have globally-routable addresses they're a bit harder to attack, even though NAT isn't a substitute for a proper firewall.
But both of these are really only valid for DIY homelab enthusiast types. I honestly have no idea why other people resist ipv6.
The big reason is that domestic ISPs don't want to switch (not just in the US, but everywhere really.)
Data centers and most physical devices made the jump pretty early (I don't recall a time where the VPS providers I used didn't allow for IPv6 and every device I've used has allowed IPv6 in the last 2 decades besides some retro handhelds), but domestic ISPs have been lagging behind. Mobile networks are switching en masse because of them just running into internal limits of IPv4.
Domestic ISPs don't have that pressure; unlike mobile networks (where 1 connection needing an IP = 1 device), they have an extra layer in place (1 connection needing an IP = 1 router and intranet), which significantly reduces that pressure.
The lifespan of domestic ISP provided hardware is also completely unbound by anything resembling a security patch cycle, cost amortization or value depreciation. If an ISP supplies a device, unless it fundamentally breaks to a point where it quite literally doesn't work anymore (basically hardware failure), it's going to be in place forever. It took over 10 years to kill WEP in favor of WPA on consumer grade hardware. To support IPv6, domestic ISP providers need to do a mass product recall for all their ancient tech and they don't want to do that, because there's no real pressure to do it.
IPv6 exists concurrently with IPv4, so it's easier for ISPs to make anyone wanting to host things pay extra for an IPv4 address (externalizing an ever increasing cost on sysadmins as the IP space runs out of addresses) rather than upgrade the underlying tech. The internet default for user facing stuff is still IPv4, not IPv6.
If you want to force IPv6 adoption, major sites basically need to stop routing over IPv4. Let's say Google becomes inaccessible over IPv4 - I guarantee you that within a year, ISPs will suddenly see a much greater shift towards IPv6.
It's frustrating that even brand new Unifi devices that claim to support IPv6 are actually pretty broken when you try to use it. So 10 years from right now even, unless they can software patch it upwards.
Prefix delegation is completely broken for example
I had to switch to OpenWRT on my Ubiquity gear to have something that works (which on the other hand is also easier to configure, so I'm probably going to stay there).
Except that is completely wrong. Consumer/residential networks have significantly higher ipv6 adoption rates that corporate/enterprise networks. That is why you see such clear patterns (weekend vs weekday) in the adoption graphs.
Has it been abysmally slow? What's the par time for migrating millions of independent networks, managed by as many independent uncoordinated administrators, to a new layer 3 protocol?
We've never done this before at this scale. Maybe this is just how long it takes?
Sure, the data plane supports it - but what about the management plane?
I wouldn't be surprised if ISPs did all the management tasks through a 30-year-old homebrew pile of technical debt, with lots of things relying on basic assumptions like "every connection has exactly one ip address, which is 32 bits long".
Porting all of that to support ipv6 can easily be a multi-year project.
This is true, I worked for an old ISP/mobile carrier that started in the 80s about 10-15 years ago. They had basically any system you could think of still running, from decently modern vmware with windows and linux to hp-ux, openvms, sunos, AIX, etc. Could walk around and see hardware 30 years old still going, I think one console router had an uptime of 14 years or so. One time I opened a cabinet and found a pentium 1 desktop pc on the floor still running and connected, served some webpage. The old SMSC from the 80s on DEC hardware was still in its racks though not operational, they didn't need the space as the room couldn't provide enough power or cooling for more than a few modern racks. The planning program for fiber, transmission, racks, etc, required such an old java that new security bugs didn't apply to it, and looked and worked like an old mainframe program.
The core team supported ipv6 for a long time, but its rather easy to do that part. The hard part is the customer edge and CPE and the stack to manage it, it may have a lifetime of 2 decades.
> Porting all of that to support ipv6 can easily be a multi-year project.
FWIW, as someone who has done exactly this in a megacorp (sloshing through homebrew technical debt with 32-bit assumptions baked in), the initial wave to get the most important systems working was measured in person-months. The long tail was a slog, of course, but it's not an all-or-nothing proposition.
Comcast actually implemented IPv6 10-15 years ago so that they could unify the management of all of their cable modems. Prior to that they had many regional networks using with modems assigned management IPs in overlapping private IPv4 ranges.
No idea, but people do it. Every time this comes up on HN there are dozens of comments about how they like hiding their devices behind a NAT, for security
Just because people regularly bring up a non sequitur doesn't mean there actually is a problem.
"I have a device acting as both a NAT and a stateful firewall, why are you making me switch to IPv6 and in the process drop both the NAT and the stateful firewall?" is a non sequitur.
I think we're talking about two different things, or maybe I just don't understand your reply.
What I'm saying is this: There exist people in the hobbyist space who believe that when their devices only have private IPv4 addresses such as 192.168.0.0/16 that this meaningfully increases their network security, and that if their raspberry pi has a globally-routable v6 address that this weakens their network security, even though this is bogus because NAT is orthogonal to network security considerations, and that this belief contributes to IPv6 hesitancy.
I set up NAT66 recently with DHCPv6. The IPv4 and IPv6 addresses are practically the same, except IPv6 has a prefix and a double colon as the last separator.
This really should be how SOHO routers do IPv6 out of the box.
Most people don't want 1:1 addressing for their entire home or office.
Are you using ULA prefix for the nat66/dhcp6, are you also allowing GUA address assignment via slaac?
Im wondering how it works out with source-selection
IPv6 is a recursive WTF. It might _look_ like a conservative expansion of IPv4, but it's really not. A lot of operational experience and practices from IPv4 don't apply to IPv6.
For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses. ULA was invented to solve this, but the source selection rules are STILL being debated: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...
Then there's DHCP. With IPv4 the almost-universal DHCP serves as an easy way to do network inspection. With IPv6 there's literally _nothing_ similar. Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6). And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
Then there's IP fragmentation and PMTU that are a burning trash fire. Or the IPv6 extension headers. Or....
In short, there are VERY good reasons why IPv6 has been floundering.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
No, that’s not the IPv4 design. That’s an incredibly ugly hack to cope with IPv4 address shortage. It was never meant to work this way. IPv6 fixes this to again work like the original, simpler design, without ”local” addresses or NAT.
> In IPv6 each host has multiple global addresses.
Not necessarily. You can quite easily give each host one, and only one, static IPv6 address, just like with old-style IPv4.
The problem here is the IPv6 design. It has multiple ways of configuration, and ALL of them suck.
Manual address input is clumsy because of IPv6 address length, stateless RA is limited and doesn't allow network introspection, stateless DHCP is pointless, stateful DHCP is not supported by the most widely deployed OS. There's also prefix delegation that needs stateful DHCP.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
This is a troll right? NAT is a lot of things, but "simple and clean" is definitely not one of them. It causes complications at every step of the process.
Pure IPv6 is so much cleaner.
I will say that DHCP6 is probably misnamed. It does not fill the same niche has IPv4 DHCP, and this causes a lot of confusion with people who are new to IPv6. It should probably be called DPDP (Dynamic Prefix Distribution Protocol) or something like that. It's for routers not hosts.
In theory you should be using anycast DNS to find local hostnames, but in practice the tooling around this is somewhat underbaked.
> This is a troll right? NAT is a lot of things, but "simple and clean" is definitely not one of them. It causes complications at every step of the process.
This is something that can be done with consumer-grade routers in _minutes_ with zero configuration from endpoints apart from the usual WiFi password.
NAT is a _superior_ design in practice. It can be chained transparently, it moves all the stateful routing complexity to the border router, it enforces network isolation. And most importantly, IT ACTUALLY WORKS.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
I assume you mean "interface", not "host". Because it's absolutely not true that a host can only have one "local net address".
EDIT: a brief Google also confirms that a single interface isn't restricted to one address either: sudo ip address add <ip-address>/<prefix-length> dev <interface>
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
If you think NAT is "simple and clean", you may wish to investigate STUN/TURN/ICE. An entire stack of protocols (and accompanying infrastructure) had to be invented to deal with NAT.
> Then there's IP fragmentation and PMTU that are a burning trash fire.
It's not significantly worse on v6 compared to v4. Yes, in theory, you can send v4 packets without DF and helpful routers will fragment for you. In practice, nobody wants that: end points don't like reassembling and may drop fragments; routers have limited cpu budget off the fast path and segment too big is off the fast path, so too big may be dropped rather than be fragmented and with DF, an ICMP may not always be sent, and some routers are configured in ways where they can't ever send an ICMP.
PMTUd blackholes suck just as much on v4 and v6. 6rd tunnels maybe make it a bit easier to hit if you advertise mtu 1500 and are really mtu 1480 because of a tunnel, but there's plenty of derpy networks out there for v4 as well.
IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.
The IPv6 failing was not taking advantage of the new protocol to properly engineer fragmentation handling. But wait, there's more! IPv6 also has braindead extension headers that require routers to do expensive pointer chasing, so packets with them are just dropped in the public Net. So we are stuck with the current mess without any way to fix it.
> IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.
In theory yes; but actual packets are 99%+ flagged DF. Reassembly is costly, so many servers drop fragmented packets, or have tiny reassembly buffers. Back when I ran a 10G download server, I would see about 2 fragmented packets per minute, unless I was getting DDoSed with chargen reflection, so I would use a very small reassembly buffer and that avoided me burning excessive cpu on garbage, while still trying to handle people with terrible networks.
Router fragmentation is also expensive and not fast path, so there's pretty limited capacity for in path fragmentation.
I think I agree with you, that RFC you linked seems awfully hopeful... unlikely to actually happen. Better endpoint probing is probably where we're going to end up. Or things like QUIC where if you don't have the required minimum MTU, too bad so sad.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
> In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses.
Only a problem for home users with frequently changing dialup networks from a stupid ISP. And even then: Your host can still have ULA and link-local addresses (fe80::<mangled-mac-address>).
RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.
> Then there's DHCP.
DHCPv6 is an abomination. But not for the reasons you are enumerating.
> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.
IPv4 DHCP isn't a sensible means to do network inspection. Any rougue client can steal any IP and MAC address combination by sniffing a little ARP broadcast traffic. Any rogue client can issue themselves any IPv4 address, and even well-behaved clients will sometimes use 169.254.0.0/16 (APIPA) if they somehow didn't see a DHCP answer. If you want something sensible, you need 802.1x with some strong cryptographic identity for host authentication.
> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).
Yes, that is grade-A-stupid stubborness. On the other hand, see below for the privacy hostname thingy in IPv4 and the randomized privacy mac addresses that mobile devices use nowadays. So even if Android implemented stateful IPv6, you will never be reliably able to track mobile devices on your network. Because all those identifiers in there will be randomized, and any "state" will only last for a short time. If you want reliable state, you need secure authentication like 802.1x on Ethernet or WPA-Enterprise on Wifi, and then bind that identity to the addresses assigned/observed on that port.
> With IPv6 there's literally _nothing_ similar.
Of course there is. DHCPv6 can do everything that IPv4 DHCP can do (by now, took some time until they e.g. included MAC addresses as an option field). But in case of clients like Android that don't do DHCPv6 properly, you still have better odds in IPv6: IPv6 nodes are required to implement multicast (unlike in IPv4 where multicast was optional). So you can just find all your nodes in some network scope by just issuing an all-nodes link-local multicast ping on an interface, like:
(The interface ID (like eth0, eno1, "Wired Network", ...) is necessary here because your machine usually has multiple interfaces and all of those will support those multicast ranges, so the kernel cannot automatically choose for you.)
> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
DHCP option 12 ("hostname") is an option in IPv4. Clients can leave it out if they like. There is also such a thing as "privacy hostname" which is a thing mobile devices do to get around networks that really want option 12 to be set, but don't want to be trackable. So the hostname field will be something like "mobile-<daily_random>".
What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests. DHCPv6 forwarders may add that option, but in lots of equipment this is a very recent addition still (though the RFC is 10 years old by now). So if you unbox some new hardware, it will identify by some nonsensical hostname (useless), an interface identifier (IAID, useless, because it may be derived from the MAC address, but it may also be totally random for each request) and a host identifier (DUID, useless, because it may be derived from the mac address, but it may also be totally random for each request). Whats even more stupid, the interface identifier (IAID) can be derived from a MAC address that belongs to another interface than the one that the request is issued on. So in the big-company usecase of unboxing 282938 new laptops with a MAC address sticker, you've got no chance whatsoever to find out which is which, because neither IAID nor DUID are in any way predictable. You'll have to boot the installer, grab the laptop's serial number somewhere in DMI and correlate with that sticker, so tons of extra hassle and fragility because the DHCPv6 people thought that nobody should use MAC addresses anymore...
> That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
Look, I've been doing IPv6 for 20 years, starting with a 6to4 tunnel and then moving to HE.net before getting native connectivity. I'm probably one of the first people who started using Asterisk for SIP on an actual IPv6-enabled segmented network.
I _know_ all the pitfalls of IPv6 and IPv4. And at this point, I'm 100% convinced that NAT+IPv4 is not just an accidental artifact but a better solution for most practical purposes.
> What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests.
Yes. DUIDs were another stupid idea. As I said, IPv6 is a cascade of recursive WTFs at every step of the way.
And let me re-iterate, I'm not interested in academic "but acshually" reasons. I know that you can run IPv4 with DHCP giving out publically routable IPv4 addresses to every host in the internal network without NAT. Or that you can do NAT on IPv6 or laboriously type static IPv6 addresses in your config.
What matters is the actual operational practice. Do you want a challenge? Try to do this:
1. An IPv6 network for a small office with printers, TVs, and perhaps a bunch of smart lightbulbs.
2. With two Internet uplinks. One of them a cellular modem and another one a fiber connection.
3. You want failover support, ideally in a way that does not interrupt Zoom meetings or at least not for more than a couple of seconds.
4. No NAT (because otherwise why bother with IPv6?).
Go on, try that. This is something that I can do in 10 minutes using an off-the-shelf consumer/prosumer router and IPv4. With zero configuration for the clients, apart from typing the WiFi password.
Well, I can do that with OpenWRT, no idea which prosumer devices already implement this, but it isn't rocket science: Announce the Prefix of the currently active connection, invalidate the other one. Will interrupt all your TCP connections, but they are toast anyways, most software should handle this just fine. It's quite the same as a Wifi-to-Cellular handover.
> Announce the Prefix of the currently active connection, invalidate the other one
And this doesn't actually work. Prefix deprecation is a best-effort feature that is not implemented correctly in tons of devices, including such rarely used niche operating systems as macOS. It even technically violates RFC4862 (section 5.5.3).
I highly recommend actually trying what I proposed. Not in a theoretical hand-wavy way, but actually setting it all up and verifying that it works. I did not pose this challenge in a "gotcha" way. I really was not able to make it work cleanly with either Mikrotik or OpenWRT routers.
How so? The same working group published e.g. https://www.rfc-editor.org/rfc/rfc1933, and it's hard to see how v6 could have been designed for backwards compatibility in ways that it wasn't already.
I've asked lots of people to describe a more backwards-compatible design, and generally the best they can manage is to copy the way v6 does things, ending up with the same problems v6 has. This has happened so often that the only reasonable conclusion is that it can't really be done any better than it was.
fd::1 is somewhere in the reserved ::/8 space where various stuff like old ipv4 mapped addresses and localhost reside. What you probably mean is something like fd00::1, but that is something you shouldn't use, because 'fd00::/8' is a probabilistically unique local address (ULA) block. You are supposed to create a /48 net by appending 40 random bits to fd00::/8. Of course, if your fair dice roll lands on all zeroes, and you are ok with probable collisions in case of a network merge, you are fine ;)
In home networks, the idea of merging with someone else's network is... most certainly not worth worrying about. Maybe you marry someone or become roommates with someone who also picked fd00::/8? And you still want two separate subnets? Other than that I don't see a scenario where it matters.
Granted, if you're doing this in a corporate setting (where merging with someone else's address space is a lot more realistic), then yes definitely pick a random 40 bits. But at home? Who cares. Same as using 192.168.1.0/24 instead of a random 10.0.0.0/24 subnet... it's not worth worrying about.
I'm having my own and my girlfriend's router (in different flats) connect to each other with a wireguard tunnel, so I can print on her printer. Non-colliding addresses make this a lot easier.
Those are designed to have static asymmetrical bandwidth though, *dm split gives ISP side more of possible shared bandwidth. Wifi bandwidth is shared and dynamic so client can use all of it.
That was always the plan for "the future". That is get everyone to IPv6 and then get rid of IPv4. IPv4's days are numbered - but the number looks really big.
Of course there's an incredibly long tail here, but in the big picture, "nobody except some people maintaining a few legacy systems ever need to learn to work with this protocol anymore" is practically the same thing.
Comcast, one of the largest residential ISPs in the USA, has almost full IPv6 deployment by default. The majority Verizon Wireless is IPv6 by default. Residential customers in the USA have great access if they just enable the stack.
There is nothing about IPv6 that prevents ISPs from filtering ports for all customers. They almost all actively filter at least port 25, 139 and 445 regardless of the actual transport. So I'm not sure "blocking service hosting" is the actual goal here.
The problem seems to be that all of the large and wealthy nations of the world have made the necessary huge investments into IPv6 while many of their smaller neighbors and outlying countries and islands have struggled to get any appreciable deployment.
It should be a UN and IMF priority to get IPv6 networks deployed in the rest of the world so we can finally start thinking about a global cutover.
In many developing countries IPv6 adoption is far and sometimes networks are IPv6-only, because IPv4 is expensive and they have relatively little addresses compared to users...
You can see southeast Asia is pretty green on the map of the post.
How far below is the question. It could level out at 60% - that is believable. However it can't level out at 99% - Somewhere around 95% major sites will decide IPv4 isn't worth supporting and they will just ignore that final 5% of customers, which will force them to upgrade - which in turn will give others confidence to remove their final 4% of customers - until IPv4 dies.
There are also still Telex and X.25 networks around there, not to forget the whole public telephone network!
But at some point, getting a native connection to all of these started becoming increasingly rare, and now these are largely emulated/tunneled on top of IP. The same can happen for IPv4.
Can you share details on how one trivially connects via IPv6 only? I see no option in iOS Wi-Fi settings to do this, and I think it's reasonable to expect not to have to turn off IPv4 on my access point to test IPv6-only networking.
I’m going to guess no one responding to me has actually tried connecting to an IPv6 only network because it works without incident. Will your apps? Who knows - apple hasn’t always been great at enforcing that.
NAT64 doesn't make sense for consumers. There are too many apps that hardcoded IPv4 in their code. People are going to complain that their old Xbox games don't work.
For most people, dual stack works fine. For mobile, the solution is 464XLAT that translates locally. There is MAP-E that does translation on gateway with IPv4 on local network.
For businesses, NAT64 makes more sense cause they can control what software is running. Even there, usually have to make IPv4 subnet for the old printers.
In parts of the world with fewer IP addresses they already are. My ISP _only_ offers MAP-E access to the IPv4 internet for anyone not grandfathered into an older plan.
“Privacy addresses” are named because in the beginning, your auto-generated IPv6 would incorporate your hardware MAC address verbatim, and many people consider the MAC address to be PII.
On the last 64 bits, yes. On mobile phones, the first 64 bits may be fixed. This was something I argued against when I was at Vodafone Group, but didn't get any traction. That was a while back, but I'd assume that this is still the case, and that mobile phone addresses can be used for tracking.
No, not just like IPv4. My IP address is 192.168.0.23 right now, as are millions of others. Add in CG-NAT from my ISP and I do not have a globally unique identifier.
> Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache. Every service a device requires is delivered in a single DHCP8 lease response.
I'm not going to pretend I know all about IP routing and networking. I understand enough of it to have a home server all appropriately set up with IPv4.
But what makes this quote a problem? I mean, it seems a bit excessive, but I don't understand why...
hell, before we get and send the token how do we get a list of authorized users and systems over?
and if we're going to use IPv4 / 6 to get set up, why switch to IPv8? we're already talking, and it's working so use certs and tokens over those protocols
It's a collection of words that don't actually say anything. What's being protected by these tokens and how? How is trust established? How do you bootstrap L3 authentication when you first need to reach a remote server over the internet?
Like most AI slop it might sound reasonable at first glance but there's no substance behind it. Usually there's some (deeply flawed) substance but here it's just completely absent.
The featured video does not explain how it uses signals to produce which outcomes and they basically just say "we use machine learning while outputting a dance". At 07:10 it looks like the person chooses between two binary options of "sad" and "relieved". Unfortunately I doubt the person has anywhere near the real-time input to the performance as much as it is implied. Dentsu is also an advertisng agency in Japan, so it seems like this is more marketing than it is technical.
Dances by physical humans are always choreographed beforehand but live performances always show physical motion that can interrupt or change to unchoreographed movement at any time. I have a hard time believing that this person's brainwaves are mapping and producing the hologram in a specific 3D space, other than instructing it which mood preset to use at a given time.
Excluding the marketing of the ALS story, I guess I'm wondering how it's different from a Michael Jackson hologram performance where someone could adjust the sliders for mathematical functions live?
I am pretty sure you’re right, they are probably recording alpha waves, possibly combined with heart rate.
Decoding limb joint movements from EEG scalp recordings is basically an unsolved problem (we can barely do it in lab with implants), I doubt an advertising company has cracked it.
Alpha waves refer to the measurable 8-12Hz waves in the electromagnetic field coming out of the human head. They are the clearest "signal" we can read out with eeg ("electro" "encephalo" (brain) "graphy") and usually peak in power over the back of your head.
They are also by far the biggest (measurable) eeg signal change you can manipulate intentionally (other than motion artifacts). Closing your eyes or focusing your attention inwards reduce the power of those oscillations so much it's visible right away just looking with your eyes at the signal trace.
It would be very straightforward to program in decision points to the light show where someone can select an option by tuning their attention inwards or outwards.
TLDR: It's the "press X to doubt" of human-computer interfaces.
Japan is a bureacracy-driven credentialist Confucian scholar-boner societal nightmare, so pushes for more credentialism are never a surprise. Recently this month laws and fines for bicyclists have gotten stricter. Yes, a human-powered vehicle that almost anyone can ride without a license is deemed necessary to enforce. This is what the government thinks is worthy of its time, and it thinks making immigration harder to do with more bureaucratic entry barriers is necessary when the foreigner population is barely 3%. The process to getting a driver's license is insane. If you want to avoid the Kafkaesque procedures at the license center, you have to go to a school that costs around $2000 and takes several weeks so you can have forced participation in the bureacracy. The United States fails to prioritize anything whereas Japan prioritizes all the wrong places and thinks such misprioritization is good because it considers any centralized action at all to be inherently good. Wheels spinning in place.
I have been in Tokyo a week ago and that they want to do "something" to affect the behavior of cyclists is absolutely unsurprising to me. Cyclists are definitely a problem in Tokyo. They ride like maniacs, always on sidewalks, even if there are bicycle paths on the road. The actually surprising thing was that the otherwise very ordered and rule-abiding tokyoites are so chaotic when it comes to bicycles.
Now where I am from every school kid gets to take part during a days long bicycle safety introduction and after that most citizens will be relatively ok to ride practically for the rest of their lifes. In Tokyo it seemed to me that tokyoites seemed to have declared bicycling a rule-free space for themselves. I have been there two weeks and witnessed 3 near accidents on the sidewalk.
I am not a fan of bureaucrats, but we can't assume people are able to create a good outcome just by themselves without education, guidance, rules and enforcement. The best way is to educate your population early on on how move in a public space using bicycles. But if you have a problem to solve right now the next best thing is the law.
Cyclist in Tokyo here. Maybe I wouldn't need to go on the sidewalk so much if they didn't let cars treat the bicycle lane like roadside parking. Enforce that before enforcing some stupid green ticket. We need dedicated bicycle lanes partitioned from the car lanes like I've seen in Australia.
Yeah, I am a cyclist myself. The bicycle lanes in Tokyo were woefully inadequate, so many cyclists using the pedestrian areas is not really a big surprise. But what was a surprise (mirrored in one of your silbling comments) was the way in which they did it.
I am living in Germany and there are also cyclists on sidewalks here. But I don't think I ever had the feeling when walking here that I needed to move when a cyclist approached. Cyclists are aware they are not supposed to be there so they will have to wait to pass. That was different in Tokyo, hence also my lack of surprise that there needs to be some regulation, since this was clearly dangerous and with a city that size this has to end up in hospitals on a daily basis.
Yeah, I gained a habit of constantly checking over my shoulders because of the people who will speed past you on e-bikes with very little room. Even parents with their kid in the back ride like mad.
This was something I really reacted to in Japan. Cyclists had absolutely no manners at all. I know it is popular to complain about cyclists everywhere, but Japan really stood out to me)
All of that stuff you listed sounds great, actually. I sure wish my government would enforce traffic laws, raise the barrier of knowledge to drive, and reduce immigration. Alas.
Well, I mean Japan has almost half the GDP per capita than Germany and the mentioned fee is the minimum in a rural area (a place where driving becomes essential), not Tokyo where it's considered the ultimate privilege bestowed upon from the heavens and costs more.
yes but maybe it’s still cheaper in DE than the time cost of learning JP
it’s cray cray that in non Schengen foreigners can drive 90 days im Germany with their foreign issued driving license, but natives are subject to insane whims of the driving Schule…
They traded my Canadian license for a German one. No tests required. I didn’t even now about the priority signs. I learned most of it when I did my motorcycle license later.
That loophole has been closed years ago by requiring classes and tests in your country of residence. I believe that’s the case since almost a decade, but I could be wrong.
reply