Obvious disclaimer: This is a sample size of 1, and an anecdote is not data, yada yada. I'm not involved in academia, and have no insight into the adoption of IPv6 in CompSci networking curricula on a broader level.
As of 2024, IPv6 deployment in France was >97% mobile and >98% residential due to not being required for obtaining a 5G radio license (and then v6 simply carried downward to being available on 4G) + every ISP that provides FTTH also providing v6.
https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...
Over here IPv6 JustWorks to the point of absolute boredom.
Many of the big benefits are things that don’t deliver anything that folks are lacking. You also need to understand how you fit in the overall universe more.
It's almost a self-inflicted tragedy of the commons or reverse network-effect.
Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.
1. Use IPv6 which works and goes directly to the virtual machine because each virtual machine grabs its own address from one of my 18446744073709551616 addresses.
2. Use IPv4 and either have to do a jumphost or do port forwarding, giving each virtual machine its own port which forwards to port 22 on the virtual machine.
3. Use a VPN.
Also being able to generate unique ULA subnets is super nice.
Tell that to everyone who is behind CG-NAT and has issues with (e.g.) video games. Or all the (small(er)) ISPs that have to layout CapEx for translation boxes.
Tech finds a way…
That just reminded me of a peer protocol I worked on a long time ago that used other hosts to try to figure out which hosts were getting translated. Kind of like a reverse TOR. If that was detected, the better peering hosts would send them each other's local and public addresses so they could start sending UDP packets to each other, because the NAT devices wouldn't expect the TCP handshake first and so while the first few rounds didn't make it through, it caused the NAT device(s) to create the table entries for itself.
Was it Hamachi that was the old IPX-over-IP tunneling? I'm fairly sure it used similar tricks. IPX-over-IP is also done on DOSBOX, which incidentally made it possible to play Master of Orion 2 with friends in other continents.
IPv6 has arguably done more to counteract market forces related to IPv4 address exhaustion.
When your washing machine, fridge, etc all come with ipv6 5g modems is when your house becomes part of the future IT battlescape between lots of different entities that do not wish you well.
They get better network management.
* The internet
* Linux servers
* Automation
I get your point, but it falls on deaf ears to me since most people don’t feel the benefits until some passionate nerd makes something that scratches an itch.
For a practical example: peer-to-peer sharing like Airdrop is much easier to implement in a world with ipv6.
Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
People complain about dual stacks and all that but with a modicum of planning it is minimal extra effort. Anything made in the last decade has V4/V6 support and unless you're messing with low level network code, it's often difficult to even know which way you're being routed. Network devices pretty much all support using groups of names or addresses and not hard coded dotted-quad config statements now, and have for a while. And that was good practice on V4 networks too.
Part of it is probably that remembering various V4 magic is easy enough to do but feels complicated enough to be an accomplishment. In V6, there is no point in doing most of that because the protocol has so much more automation of addressing schemes. But if you like those addressing schemes, V6 can do them even better. You can do all sorts of crazy address translation on either the network or host id portion, like giving an internal network a ULA that is magically translated to a public network prefix without any stateful tracking unless that is desirable.
I feel there is some analog to DNS in that regard, people who have gotten used to DNS don't give a damn about host IP addresses but some people seem to really like the idea of a fixed address statement. People also seem to be stuck on the idea that NAT creates some kind of security when that's really the stateful tracking that is required for many-to-few translations (thus making firewalls a common place to implement it), not the translation itself. Similar to certificates/pki versus shared keys, yes, one is more upfront effort but that's because it's solving the problem of the Sisyphean task that is the other.
edit: This all reminded me that we lived with dual stacks before, in the IP and IPX days, or DECnet, and that GE Ether-whatever, and those had less in common. IPX mostly died with Netware but it had a number of advantages that wouldn't be bolted on top of IP for years, some of which are present in IPv6. I rather liked IPX and had history gone differently that it used 48-bit addressing would be causing us to discuss whether or not EUID was a mistake or not :)
A successor to ipv4 wasnt a technical issue. duh, use longer addresses. The problem was social.
It's a miracle it was used at all
What's annoying about ipv6 discussions is that the ipv6 people are incredibly condescending when the problems of its adoption were engineered by them.
This is just further proof that university educations are still not job training. The sooner we disabuse ourselves of that perception the better off society will be.
Higher education is about creating a breadth of knowledge, not specific marketable skills. CompSci is a research field, not job training.
If your friend wanted to learn specific job skills a technical college would be the appropriate setting.
I realize this misperception is perpetuated by the job market but I’m still not surprised at the education provided by UCI and don’t fault them for providing it.
Programs will teach Docker only years after it is adopted.
Same with AWS, JavaScript, etc.
If it’s not adopted by industry, it won’t be taught about.
I am not doubting you, but I feel this story is too hard to believe without adding further nuances...
MIT 6.829 teaches IPv6 since 2002: https://ocw.mit.edu/courses/6-829-computer-networks-fall-200...
In Portugal and other countries, there are subjects on Computer Science before College or University, and they teach it on High School...
Then there is usually a chapter on IPv6 that just briefly covers the differences.
I.e. the exercises all tend to use IPv4 as the foundation so people don’t practice v6
IPv4 is, for all intents and purposes, still the default transport. It’s also simpler than IPv6 in some regards. When teaching layer 3, it makes sense to teach both, and teach IPv4 first. Though I fully agree that they should be taught with equal emphasis. I don’t doubt there’s a good number of programs out there that don’t into sufficient detail on IPv6.
--Sent from my IPv6
My ISP has finally mastered providing me with reliable albeit slow DSL. Fiber would change my life, there just isn't any point in asking for IPv6.
Also note those bloated packets are death for many modern applications like VoIP.
I went from being pumped to learn more to realizing I’m going to invest a lot of time and I could not identify and tangible benefit.
(The flip side is having a network-level firewall is more important than ever.)
You also don't have to worry about running a DHCP server anymore, at least on small networks. The simplicity of SLAAC is a breath of fresh air, and removes DHCP as a single point of failure for a network.
For example, two IPv6 peers can often trivially reach each other even behind firewalls (using UDP hole punching). For NAT, having too restrictive a NAT gateway on either side can easily prevent reachability.
Huh? The packet sizes aren’t that much different and VOIP is hardly a taxing application at this point anyway. VOIP needs barely over dial-up level bandwidth.
https://www.nojitter.com/telecommunication-technology/ipv6-i...
In particular, just off the top of my head...
- T-Mobile US doesn't even assign clients an IPv4 address anymore. Their entire network is IPv6 native.
- Many cloud providers charge extra for IPv4 addresses, but give IPv6 addresses out for free.
Isn’t it what all the cell phones networks use these days? And most ISP’s?
They may hand the end user device a IPv4 address but don’t they actually use IPv6?
IPv6 only ISPs will never leave the mobile space.
I would say its more "Wireless only ISPs are the only ones using it"
So… the largest ISPs.
Recent number show about 94% of Americans have cell phones and 92% of American households have Internet connections. In raw numbers, that’s about 300M cell phones and 111M households.
If zero fixed ISPs support IPv6, that’d still be about 75% of total Internet connections that do.
Personal anecdote, but once you have IPv6 setup properly (meaning your devices prefer IPv6 over IPv4) 70-80% of your internet traffic will be IPv6.
The NAT64 is really just there for the holdouts.
I'm sure that DC customers used their Edison DC equipment for decades after the grid went AC only; but in the long run the newer, flexible, lower overhead system became the default for new equipment and the compatibility cludges were abandoned.
- You have to pay money to get a static IPv4 address for cloud machines on eg AWS. Anything needing a static IPv4 will cost more and more as demand increases. NAT doesn’t exactly fix that.
- Mainstream IoT protocols have a hard dependency on IPv6 (eg Matter/Thread). Not to mention plenty of 5g deployments.
- Many modern networks quietly use IPv6 internally. I mean routing is simpler without NAT.
So it almost definitely won’t die. It’s more likely it’ll slowly and quietly continue growing behind the scenes, even if consumers are still seeing IPv4 on their home networks.
More IPv6 deployments may (ironically?) help reduce IPv4 prices as you can get IPv6 'for free' and have Internet connectivity (and not have to worry about exhaustion in any practical way). Doing CG-NAT could reduce the number IPv4 addresses you need to acquire.
This graph is mainly due to the fact that telcos use IPv6 for mobile devices, nothing more. Over time you will see that graph flatline and peter out as mobile device uage reaches critical mass.
afaik every single major US fixed line ISP is rolling out ipv6.
...what? The majority of people access the Internet from their phone, and not only since yesterday either. Are you arguing that this is temporary fad somehow?
Hell, chances are if you got a new router (like any new client) for your ISP, you’d be on v6 too.
Pretty much all ISPs hand out both IPv6 and IPv4 addresses to their clients, this is nothing new. When they start only issueing IPv6 IPs is when it would start truly taking off, but it will never get to that point and it will never happen.
Those are the only two countries that could plausibly have billions of mobile devices and they appear to have reached 50%.
India: https://stats.labs.apnic.net/ipv6/CN?c=IN&x=1&v=1&p=1&r=1&w=...
China: https://stats.labs.apnic.net/ipv6/CN?c=CN&x=1&v=1&p=1&r=1&w=...
[https://www.google.com/intl/en/ipv6/statistics.html]
What exactly are you going on about? 5-10 years for the old devices to be EOL’d, and we’ll likely be at 95%.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
Ultimately, an address system that replaces “1.1.1.1” with “JEDBSO:7372B6D6A:727:8:72829:762927” or whatever just isn’t viable.
Even AWS doesn’t let you use IPv6 with anything… and they charge you for using IPv4 now.
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
"Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses.
And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain?
Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.
Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland.
Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!
No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous.
The edge router has an IPv4+ subnet (either a classic v4 address, or part of a v4+ address). It maintains an L2 routing table with ARP+, and routes IPv4+ packets to the endpoint without translation. Private subnetting and NAT is only needed to support legacy IPv4 clients.
CGNAT pools IPv4 public addresses and has an expanded key for each connection, and translates either 4 to 6 or into a private IPv4 subnet. My proposal needs no pooling and only requires translation if the remote host is IPv4 classic and the edge router is not assigned a full IPv4+/24.
And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address.
And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.
So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
How is IPv6 "so different" than IPv4 when looking at Layer 3 and above?
(Certainly ARP vs ND is different.)
“most what they know from IPv6” is just NAT.
> A less ambitious IPv4 is exactly what we need in order to make any progress
but we’re already making very good progress with IPv6? Global traffic to Google is >50% IPv6 already.
Therefore if I'm on an IPv6 phone, odds are very good that my traffic winds up going over IPv4 internet at some point.
We're 30 years into the transition. We are still decades away from it being viable for servers to run IPv6 first. You pretty much have to do IPv4 on a server. IPv6 is an afterthought.
Just put Cloudflare in front of it. You don’t need to use IPv4 on servers AT ALL. Only on the edge. You can easily run IPv6-only internally. It’s definitely not an afterthought for any new deployments. In fact there’s even a US gov’t mandate to go IPv6-first.
It’s the eyeballs that need IPv4. It’s a complete non-issue for servers.
NAT is RFC 1631.
IPv6 is RFC 1883.
Admitted, that was very basic NAT.
Actually, my bad. NAT was NEVER standardized. Not only NAT was never standardized, it’s never even been on standards track. RFC 3022 is also just “Informational”
Plus, RFC 1918 doesn’t even mention NAT
So yes, NAT is a bug in history that has no right to exist. The people who invented it clearly never stopped to think on whether they should, so here we are 30 years later.
The protocols involving NAT are what end up on the standards track like FTP extensions for NAT (RFC 2428), STUN (RFC 3489), etc.
201.20.188.24.6
And most of what they know about how it works clicks in their mind. It just has an extra octet.
I also think hardware would have been upgraded faster.
Something like aaff:a.b.c.d
Leaving off the prefix: could just mean strictly IPv4.
Just like for an apartment you append something like 5B. And for a house you don't need that.
Oh and btw, your address is now 9245593924 Oak St.
The ISPs aren't gonna do it on their own.
I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason.
In my experience it’s much easier and much more pleasant do deal with. Every VLAN is a /64 exactly. Subnetting? Just increment on a nibble boundary. Every character can be split 16 ways. It’s trivial.
You don’t even need to use a subnet calculator for v6, because you can literally do that in your head.
Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets.
Network of 10.254.158.58/27? Your cheapest shotgun and one shell please.
I DO think using 64 bits for hosts was stupid but oh well.
But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles.
[1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is.
Honestly it's a huge success due to this fact alone.
IPv6 is failure only if you measure success by replacing IPv4 or if you called "time" on it before the big mobile providers rolled it out. The fact that all mobile phones support it and many mobile networks exclusively deploy it tells you what you really need to know.
IPv6 is a backbone of the modern Internet for clients, even if your servers don't have to care about it due to nat64.
Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.
IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.
They're not building products, and they're not supporting, visiting or even talking to their customers. Design-by-committee is a full time job that people actually building things for a living tend to not have time for.
Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.
BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.
If you do the easy and obvious thing of setting up two routers to advertise their prefix with your preferred priority when they're available (and advertise it as unavailable when they're not), your devices are likely to configure themselves for addresses on both prefixes, which is great.
Then when you open a new tcp connection (for example), they'll pick a source address more or less randomly... There's a RFC suggestion to select the source address with the largest matching prefix with the destination address, which is useful if the prefix is pretty long, but not so useful when the prefix is 2001:: vs 2602::
Anyway, once the source address is selected, the machine will send the packet to whichever router most recently sent an announcement. Priorities only count among prefixes in the same announcement. If you manage to get a connection established, future packets will use the same source address, but will be sent as appropriate for the most recently received advertisement.
This is pretty much useless, if you want it to work well, you're better off with NAT66 and a smart NAT box.
Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway.
But with multi-homing you would need to actively test which of your uplinks has Internet access anyway, won't you? And you would have to react somehow when one of your uplinks goes down.
It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
I still assume that you don't want the internals of your office network directly accessible via the public Internet, even when you easily can; VPNs exist for a reason.
> It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously.
And IPv6 has the benefit of a significantly simpler 1:1 NAT.
So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.
Switched to OpenWRT which respected my ULA.
That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days.
> and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead.
That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.
Ultimately I want the rout g to be handled by the network, not by the client.
IPv4 and nat makes that a breeze.
edit Less flippantly, what are you wanting to base the routing rule on? What's your ipv4 routing rule?
DSCP is allowed in ipv6.
https://www.juniper.net/documentation/us/en/software/junos/c...
In the case of pfSense this is a recent change. It was not supported when I migrated away from it less than five years ago.
People like you talking about IPv6 have the same vibe as someone bewildered by the fact that 99.9% of people can’t explain even the most basic equation of differential or integral calculus. That bewilderment is ignorance.
"Easy" is meant in that context. The people acting like the IPv4 version is easy.
So your second paragraph doesn't fit the situation at all.
I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4".
Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is.
The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it.
IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately.
[0] Let's say we add a 32-bit extension header onto IPv4
Mobile carriers have done that between consumer devices and network towers. That forced a lot of innovation (including tools like better DNS64 and "happy eyeballs" protocols) and network stack hardening.
The roll out of out CGNAT in some cases is "let's drop IPv4 traffic randomly" and "happy eyeballs" in consumer devices is transparently driving a lot of consumer traffic to IPv6.
This is why mobile and consumer devices are leading the pack on IPv6 adoption.
It's maybe not all of Google that next needs to say "we're going to stop accepting IPv4 traffic", it's maybe more specifically GCP (and AWS and Azure) that need to do that to drive the non-consumer IPv6 push we need. The next best thing would be for all the cloud providers to at least start raising IPv4 address prices until their clients start to feel them.
One of the giant CDNs translates all IPv4 traffic to IPv6 at the edge (stateless NAT46) and is IPv6-only in its core network (for one of its primary product networks; like everybody they have multiple networks.)
But that baggage is a huge part of the problem. Almost nothing you know about IPv4 applies when you switch to IPv6, and most of us found that out the hard way when we tried to make the switch. Leaves a pretty bad taste in your mouth.
The things I need to think about are precisely the things that changed radically. Firewall rules aren't the same due to prefix changes and no NAT. DHCP isn't the same, DNS isn't quite the same, distributing NTP servers isn't the same.
Almost nothing of what I knew about configuring my home router for IPv4 has transferred to IPv6 configuration.
This is exactly what I'm talking about. When you have problems with your IP network, that's the first thing you try and figure out, "what's my address? Why is that my address? Did it change? If so, why? Are other devices able to get packets? What are their addresses? Why can those addresses get packets but this address can't?"
Also a nitpick: switching is irrelevant here, that’s L2. L2 doesn’t even know what’s an IP address :)
There was some dude on YouTube that resurrected the first Ethernet bridge (which was built for thicknet) - I recall even that worked with IPv6.
The end game will be a cryptographically large address space allocated based on some cryptographic operation, rather than a committee carving up the space arbitrarily.
Tor already does this, addresses allocation is not a problem. I think they used to use hashes, but now use Ed25519 public keys. Obviously, Tor is not suitable for most tasks. No one should have to pay for the extra latency if they don't need the anonymity.
The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
Maybe not in the strict sense, but it kind of has.
In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6. In my discussions with other engineers managing large networks, they seem to be seeing more or less that same figure.
The problem is that virtually nobody knows IPv6. I regularly bring up IPv6 in engineers' circles and I'm often the only one who knows much about it. And so, I have doubts about it's long-term future, except for edge cases. I figure some clever scheme utilizing IPv4 and probably NAT will come around at some point.
>Have an IPv4 assignment from ARIN or one of its predecessors
>Intend to immediately be IPv6 multi-homed
>Have 13 end sites (offices, data centers, etc.) within one year
>Use 2,000 IPv6 addresses within one year
>Use 200 /64 subnets within one year
Seems like they discourage individuals from getting allocations for their own personal use.
Does me renting a server in a DC count as multi homing? Bridging my network to my friend's place over wireguard? Doubtful tbh
I only know anything about RIPE policies but I gather the PI address processes and fees are very similar between RIPE and ARIN. RIPE has many members that are willing to handle address allocations for the RIPE fee plus 20% (so 60€ per year) and without bundling any other services.
Ultimately, as a regular person requesting IPv6 space you'd just ask your ISP, which can get practically as much as they want for free by submitting these kinds of requests. Meanwhile, for IPv4 space they're going to have a harder and harder time getting you additional space and chances are be unwilling to give it free/cheap.
In real life these requests don't lead to IPv6 allocation, no matter how they're asked or how often. Here are a few of the responses I've received just this year.
"At this time we are not able to provide a IPv6 unfortunately."
"We regret to inform you that, at this time, we do not offer IPv6 support."
"I wanted to inform you that IPv6 is currently not available"
Past that: Over 15yrs of asking various ISPs (large and small) to make allocations available, none of us ever budged the IPv6 needle.
https://auctions.ipv4.global/prior-sales
Prices have been going down in nonimal terms for years, let alone real terms. In terms of investment they're a terrible asset.
That doesn't seem terrible.
I challenge you to find:
1. A hotel in the US that provides IPv6. I have NEVER been in one, and I once stayed in a hotel (in Mountain View, CA) that was giving out public IPv4 addresses.
2. An easier task: a SIP provider that has IPv6 (in the US). You know, for the VoIP that is supposed to be a poster child of end-to-end connectivity.
What about those without IPv6 running?
Anyway, in the enterprises I've worked in the past decade - of course, another anecdote - not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
If you deploy IPv6 correctly, you shouldn't have to disclose IPv6 addresses to users inside or out -- DNS keeps the address literals abstract, hidden from users.
everything fit's nicely in the 10.0.0.0/8 range
in my many decades of enterprise infrastructure, no-one has ever mentioned IP6 either.
why would they, whats the business case?
Except during a merger/acquisition and both companies have 10.0.0.0/24 in their OSPF or IS-IS topology.
Except for when it doesn't.
If you just use that space as a flat range, it is almost certainly more than enough. But if you split it up in multiple levels of subnets, you can run into difficulties balancing having enough subnets and having enough space in each subnet.
I don't claim IPv6 isn't used anywhere, or even that it's not used a lot.
With subnetting needs, possibly dealing with VPNs to other networks that might use 10./8, ISPs that might use 10./8 instead of CGNAT space (100.64./10), even the total incompetence of some contractors was not reducing how IPv4 was a problem.
And that's before you hit the part where Microsoft products have been IPv6 First since ~2008 and there are entire feature sets that are very interesting to bigger companies (like well integrated always-on vpn for laptops) that require working v6
if you've never run in to this, then sorry, you've not been in an enterprise, you're in a mom 'n pop shop cosplaying as enterprise.
>In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6.
Nobody cares about those. What matters is if my device has an IPv6 address assigned.
> Nobody cares about [that]. What matters is if my device has an IPv6 address assigned.
This seems to be the weird dichotomy in these comments. Some people are arguing from the position that is absolutely everywhere and is doing great.
Others are saying since their machine doesn’t show it it’s dead and no one cares.
Is there a term for this? A successful failure? A failed success?
Kind of odd.
The other thing I have seen is that engineers make things complicated. Normal person has IPv6 enabled by default or enables it in router, and it just works and they never notice. Engineers want to configure things manually, but IPv6 is hard if fight against the dynamic defaults.
Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
If we become a galactic empire, we will have to replace the Web anyway because every interaction will have to be a standalone app or edge networking that doesn’t need to hear back from the central office for minutes, hours, days anyway. We could NAT every planet and go on forever.
But because you have two independent unique parts, you need twice as many bits, so 64+64=128 bits. It simplifies routing and address allocation, at the cost of 16 bytes per packet compared to 64 bit addresses.
That we could use IPv6 on galactic empires is an added bonus, but not really the reason.
My ISP router supports IPv6 but blocks all incoming connections by default, which is kind of like what NAT does as a side effect.
It sounds like insanity because we tend to assume that no NAT means no firewall, because NAT has some firewall-like properties, and on the most basic networks, that's the only "firewall" there is. But none of the security features of "NAT as a firewall" are exclusive to IPv4, in fact, IPv6 has an advantage because the much larger address space makes a full scan practically impossible.
This hasn’t been the case for 20 years. Privacy Extensions solved that, and every SLAAC implementation supports them.
128 bit is like the least of adoption issues and basically meaningless difference vs 64.
But it shows weird priorities when they decided 128 then immediately wasted half of it on host part just to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
non-routed prefixes are a limitation imposed by the ISP the the user can't address.
That's the essential part of self-configured addresses in IPv6 that does away with DHCP in most cases. DHCP is a stateful system that has to track every device's addresses individually. You don't need that with IPv6 thanks to this.
Need I remind you that option to push DNS server (which is pretty fucking important option!) was added to IPv6 standard only in 2007 ?
Like, someone decided "yeah have that magical stateless autoconfig thing" and didn't figure out that basic options like DNS, or less common but still VERY useful like the PXE stuff, or NTP server, routes and dozen others DHCP does? (there are security implications too but DHCP wasn't great here too)
IPv6 in its original format was a joke and stateless configuration is more or less pointless excercise aside from link-local adresses but those could be only exception where stateless runs
v6 restores the end-to-end principle and reduces network complexity once you go v6 only. Not more NAT traversal problems, no need to deal with STUN/TURN, small networks get even simpler with no need for a statefull DHCP server.
Sticking with only v4 space also artificially increases the cost of starting new networks and services because you have to buy space from the entrench IP save owners (unless we change the rules are start charging fees to legacy networks and reclaiming unused or poorly utilized space). Those higher barriers to entry hurt innovation and competition.
So v6 solves several technical and policies issues with the Internet, and maybe that's why we haven't seen speedy adoption. Because people have networks that exist today, some have paid a lot of money for IPv4 space and they want to make the most of that investment.
They don't really have an incentive to implement V6 unless things start to break without it.
I don't think v6 has been a failure half of all internet traffic runs on it! It powers the major cell phone networks, and large tech companies like meta have even gone v6 only in their data centers.
What networks are v6 only today?
> So v6 solves several technical and policies issues with the Internet,
If it's not used it doesn't solve anything
> They don't really have an incentive to implement V6 unless things start to break without it
Exactly my point
Mostly mobile networks.
> If it's not used it doesn't solve anything
It's used by literally billions of devices.
I use hyperoptic in the UK, if you replace the original router (which reserves the external 443 port for itself, i.e. no one sophisticated would keep it), there seems to be no way to get a v6 address. This is pure incompetence and carelessness. Like ISPs allowing their network to send packets spoofing IPs from outside their network. Add to that foreign ISPs (which means that even if your own network supports v6, you need v4 support when you are on holidays/travelling), and you have a situation where v4 cannot simply be switched off.
So for a website, what is the point of supporting v6 if v4 is never going away?
the goal being to support a model where one could support multiple prefixes to handle the common case of multiple internet connections. more importantly to allow providers to shuffle the address space around without having to coordinate with the end organization. this was perceived to be necessary to prevent the v6 address space from accruing segmentation.
Keep in mind that SLAAC isn't. Modern IPv6 stacks use privacy addresses, so they still need to run the address collision detection.
There's also a proposal to have SLAAC with longer prefixes, because otherwise you need to use DHCP-PD if you want to have subnetting in IPv6.
It's hard to disagree with your point since 64 would definitely have been better than the 32 we have. I'm not convinced the choice of going for 128 bits posed any real challenge to adoption though.
By raising the barrier to entry so high we guaranteed the features would likely never be needed.
A large number of my devices and websites I visit use IPv6. Its success has highlighted the fact that I don't want it. Just today I disabled IPv6 on my router because I suspect it as a vector for tracking.
IPv6 offers nothing of value to the user. It might as well be shelved forever.
In Asia they've implemented v6 everywhere pretty much because their v4 allocation is woefully insufficient. APNIC has like 4 billion people in it but less IP space than ARIN, with a population of less than 500 million.
If the ISP is IPv6-first, you bet that their customers are using it in their home WiFi.
In my experience it's actually the large enterprises that are having issues.
I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
I had mentioned some of that in my post: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.
> "In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
Apparently it turns out IPv6 wasn't for me any way!
I find it useful, mine does change periodically, but I just have a script that Updates DNS when it changes:
nsupdate -v -y "${KEY_ALGO}:${KEY_NAME}:${KEY_SECRET}" <<EOF
server $DNS_SERVER
zone $ZONE
update delete $RECORD AAAA
update add $RECORD 300 AAAA $CURRENT_IP
show
send
EOF
I also have a dynamic IPv6 prefix. That one changes at least once a week, regardless.
The huge difference from the IPv4 world is that the procedure for generating your /48 ULA prefix ensures that it's very, very unlikely that you will get the same prefix as anyone else. So, if everyone follows the procedure, pretty much noone has to worry about colliding with anyone else's network.
Following the procedure has benefits. For example, VPN providers who want to use IPv6 NAT can do that without interfering with the LAN addressing of the host they're deployed to... companies that merge their networking infrastructure together can spend far less (or even zero) time on internal network renumbering... [1] etc, etc, etc.
[0] And link-local addresses are the equivalent of 169.254.0.0/16 space.
[1] Seriously, like a year after one BigCo merger I was subject to, IT had still not fully merged together the two company's networks, and was still in the process of relocating or decommissioning internal systems in order to deal with IPv4 address space constraints. Had they both used ULA everywhere it was possible to do so, they could have immediately gotten into the infosec compliance and cost-cutting part of the network merging, rather than still being mired in the technical and political headaches forced upon them by grossly insufficient address space.
https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...
Nope, it works just fine. I use it for stable local addressing and LAN host AAAA records and let my ISP-delegated global prefix drift as my ISP wishes it to.
And -as it happens- the prose in that article about source address selection is incorrect.
On Linux, source address preference appears to be application-specific. For example, curl prefers IPv6 addresses, and falls back to IPv4 if the v6 connection fails. I checked just now by removing my globally-assigned IPv6 address, and capturing the traffic created by executing 'curl https://www.google.com'. I know for a fact that BIND 9 prefers non-link-local IPv6 source addresses over IPv4 addresses because until I set up my home-built router to reject Internet-bound traffic coming from my ULA, a sufficiently-long failure of the DHCPv6 server run by my ISP would cause name resolution to get very, very, very slow when the global prefix expired and BIND started using its host's ULA as a source address and my router dutifully relayed that traffic into my ISP's black hole. I'm certain that very many applications unconditionally prefer non-link-local IPv6 addresses over IPv4 ones. You might also care to pay attention to this comment and its publication date: [0]
OTOH, Firefox prefers IPv4 connections in that scenario and doesn't even attempt a v6 connection. I assume Chrome is the same way.
And, that article suggests GUA space as a replacement for ULA space:
> All of these are serious pitfalls that arise when attempting to use ULA. The simple and more elegant answer is to simply leverage GUAs.
Which... uh... no. I'd have to go through my local RIR to get an allocation, and then negotiate with my ISP to get it routed. Given that I'd have to go through ARIN because I'm in the US, and I have a boring residential account with my ISP, neither of those things will ever happen. The entire point of ULA is that no coordination with external entities is required to do network-local addressing.
Also, the documentation that that article links to to discourage people from deploying NAT66 is almost literally "It's exactly as complicated as NAT44. Why do it when you can get global IPv6 addresses?!?", which isn't a useful complaint when your intent is to exactly replicate what you get from IPv4 NAT in an IPv6 world. I agree that globally-routable addresses are better, but if your site admin demands (for whatever reason) that you not have them, then -because of the collision-avoidance property of the ULA prefix generation procedure- you're better off than with IPv4 NAT.
[0] <https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...>
Sadly, this happened despite me specifically requesting the same address as always. That caused me some grief. But it's not common.
My prefix is tied to the mac address of the device that's connected to the PON.
https://www.spectrum.net/support/internet/ipv6-faq
> IPv6 is available today with an IPv6 capable modem in the majority of Spectrum’s footprint.
For home internet service I would prefer to pay extra for a better service, it's too important to try to penny-pinch 0.1% of my income on it.
But then I live in a capitalist country where there's competition, I believe some countries you don't get a choice.
The more practical thing to look for is that they aim to upgrade it based on need, instead of arbitrarily throttling the users.
Next year that chart will finally cross 50%. It was a mere 30% in 2030. Developing country mobile phone networks will continue to push it higher.
All we need to do is start having rich governments mandate IPv6, and also mandate IPv4 downtime as a punishment for those that don't comply / chaos engineering for the system as a whole. Then we can quickly finish the job.
consumer networks have significantly higher adoption rates compared to corporate/edu, and people are on vacations during summer
Well, to the extent the rich country laggards are institutional, then regulation should be more effective!
Only half joking, some UK MPs might actually consider this a reasonable thing considering how many ipv6s there are.
Not that it matters, really. As far as I'm aware, there were never any substantial deployments of this protocol.
What makes an ipv6 useful is that you can route to it. Since you will never be connected to the network. The network will never be able to route packets to you, making the whole thing a little pointless.
I'm thinking the gov issuing you an ipv6 address that you must use to connect to the internet. But it's also you're id too, since nearly all services are either online or getting pushed that way.
Don’t know about Matter though. If it requires the user to turn on IPv6 then it’s a user experience downgrade. It should just use IPv6 internally as an implementation detail.
Some routers can work as _relays_ between the Thread network and WiFi, but this is entirely optional.
(a while ago I needed to contact support to get an IPv6 allocation at home, but that was a very quick interaction at the time)
What makes them a pain to block? Angry users or some central database that lists these addresses as "do not block"?
Not wanting to cut off access to your users from, for example, every AT&T device (and their MVNOs).
Apparently it's "not how it's done" and we're "doing it wrong".
My SOHO equipment doesn't really support it either, so it's just as well, staying on IPv4 which does DHCP and solves that problem.
Not if you're on Android. https://issuetracker.google.com/issues/36949085
Windows in powershell:
SetNetIPv6Protocol -UseTemporaryAddresses Disabled
SetNetIPv6Protocol -RandomizeIdentifiers Disabled
sysctl net.ipv6.conf.all.use_tempaddr=0
ip6-privacy=0
ifconfig em0 inet6 -temporaryThe only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.
I turn it off because it's a risk having one of either stacks malconfigured.
IPv6 should've been a superset of IPv4, as in addresses are shared, not that you have a separate IPv4 and IPv6 address for your server.
>It was doomed the moment you had to maintain two separate stacks
Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?
Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.
It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!
What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.
It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.
Yeah,172.12.10.98.12.4.24.31 will never get its reply back.
Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
::ffff:192.168.1.1 == 192.168.1.1 (as far as the linux kernel is concerned, in most contexts)
At what point will we be allowed to say IPv6 hasn't failed? When the IPv4 internet finally switches off for good? It feels like no achievement is high enough for those who don't like IPv6 to change their minds. I would've thought making up 50% of internet traffic and 50% of end devices being on IPv6-only networks would be good Schelling points, but evidently they're not!
"IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
Noone who has successfully extracted their head from their ass says that IPv6 has failed. It's widely deployed on the Internet, and on who knows how many corporate intranets and SOHO/home LANs.
IMO, it's stupid to ever consider turning off IPv4. There surely exist useful systems out there that will never be updated to work with IPv6.
I see IPv6 as an "IPv4 address pressure relief system". In the future, SOHO/home LANs can run servers on IPv6, datacenters can run servers mostly on IPv6 but also v4 if they really want, and SOHO/home networks can be behind an IPv4 CGN because all of their unsolicited inbound traffic will come over IPv6.
It's incredibly likely that the GP was referring to comments in this thread, which were indeed claiming that IPv6 has failed, despite the fact that its deployment has been steadily climbing up worldwide.
By the way...
>In the future, SOHO/home LANs can run servers on IPv6
The future is now. My web server is IPv6 only precisely due to the same reason you mentioned: my ISP has put me under a CGNAT. People can still connect to my website through the Cloudflare reverse proxy though (which I have only enabled for IPv4, IPv6 users get to enjoy direct connection).
One part of it is for some-to-many folks, yes, and the third is here for a distressingly large number of people (without the solid support of the second part). Do note that the future I outlined has three parts. ;)
In my case, I administrate a small server at home, where I self host many services that are made available to myself, friends and families, over the internet.
In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.
Some programs do not handle IPv6 at all. Game servers for instance, do not support it, the one that I think about is: Arma 3. But there are many others
In 2025 (and 2026 too?), 4G (5G?) operators do not all route over IPv6 -> which means that if your domain only has a AAAA record, some people using 4G will not be able to access ANY of your services. This issue forced me to beg my ISP to obtain an IPv4 "fullstack" as they call it.
Without that IPv4 you have to go through some kind of tunneling (like Cloudflare) -> and guess what? Cloudflare sometimes crashes (it happened super recently remember?) and in that situation -> ALL your services accessible through the tunnel are "down" for your users. Plus, it is EXTREMELY unsatisfying to rely on an external private-owned service for a selfhosting project.
In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default. NEVER. Which means: more configuration, possibly more struggle.
Not all.
I operate site with IPv6 only origins behind cloudflare.
During the outage I manged to login to the dashboard after some time and remove cloudflare for nearly 2 hours, and traffic level stayed close to 50% during the IPv6 only period.
Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
> Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
You described a situation where the outage resulted in 50% of your customers were unable to reach you and you were unable to do anything about it. I don’t think this story is a win for IPv6, regardless of whether your customers blame CloudFlare or not.
50% is a very substantial retention rate.
The story here is not “ipv6 made my site resilient to CloudFlare outage”. It’s “50% of my customers can’t reach my site even when I turn off CloudFlare”.
And it's becoming difficult for people to do so precisely because of IPv4 addresses running out...
idk if arma3 does server discovery, but in case of manual ip input there some kind of OS-networking-level adapter should help. Usecase seems too obvious for something like that not to exist
I would love for IPv6 to actually take off but somehow it feels like we are still a decade away from ubiquitous adoption.
Weird. The past two ISPs I've had (Comcast and Monkeybrains) both had IPv6 enabled by default. I've looked at a bunch of SOHO networking gear and IPv6 is on by default. On every Linux and Windows system I've touched in the past ten, fifteen years you have to go significantly out of your way to disable IPv6.
> Some programs do not handle IPv6 at all. Game servers for instance, do not support it...
Depends on the game server. Many I run absolutely do.
Your complaints smell like you tried to run an IPv6-only client network, which would be an absolute nightmare. That's just a stupid thing for a SOHO network (and the networks that serve most corporate client hosts) to do. IPv4-only Internet hosts exist, so it's a no-brainer to provide IPv4 connectivity to clients.
On the other hand, running IPv6-only infrastructure networks can make a ton of sense. One very large such operator is Comcast, a US ISP.
> but IPv6 is better
It doesn't solve any life-changing problem.
And it is consumer devices (and IoT devices) which are the most numerous and also the most price sensitive, and this is where IPv4 is disappearing first.
Even more than IPv4, not knowing enough about IPv6 can introduce a lot of unintended issue, consequence and even security gaps in your assumptions.
Maybe there was an IPv7 or 8 that will be more palatable.
IPv4 really only had 3 problems that anybody cared about:
1. Address space size;
2. Roaming; and
3. Reliable connectionless delivery; and
4. The problems created by the at most once delivery under TCP when what we really needed was at least once delivery in many, many cases.
Even the address space size problem is less of an issue than originally predicted because of improvements in NAT, up to and including cgNAT for cellular network providers (which also somewhat addressed (2) in a limited way).
Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.
By "roaming" I mean maintaining a consistent connection while moving between networks.
(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.
You could also say that TCP congestion control is pretty outdated. It's not surprising. It was designed at a time before megabit (let alone gigabit) networks. And, more importantly, latency kills throughput. Some efforts have been made on this, such as Google's BBR [2], but other problems remain like MTU windows being too small for modern networks.
So what did IPv6 do? It only solved one problem, address space, and it did it in a way that kinda created new problems. First, the address space is too large (128 bits) and the last 64 bits are kinda reserved for the job that a 16 port used to do. And why was that? Originally, it was intended that the lower 64 bits were derived from a 48 bit MAC address (as used by Ethernet and later Wifi) but they realized this was a huge privacy problem so it never happened.
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://github.com/google/bbr
[2]: https://community.cisco.com/t5/networking-knowledge-base/und...
Similarly, we have 30 years of experience that vendors will happily break optional headers or flags.
I'm no expert on IPv4 or IPv6, but if they had designed IPv6 to be able to route fine to IPv4, we'd be OK.
It would at least give people an upgrade path where their old stuff that couldn't be patched / updated and were stuck on IPv4 could be slowly killed off in the path of least resistance down the dependency line.
This 'dual stack' approach doubled up on everything up front and meant we all had to do both during the transition (which has taken 30 years).
https://en.wikipedia.org/wiki/IPv4#Header https://en.wikipedia.org/wiki/Internet_Protocol_Options https://en.wikipedia.org/wiki/IPv4#/media/File:IPv4_Packet-e...
Vs. real meat is in the comments on the Register's site.
but if you need maximum AI slop, that's everywhere
Then it's failure is by design. I should not want to multiplex/bridge different versions of the network-layer protocol; and certainly not to avoid using the new protocol because the old one seems more usable and approachable.
But attempts at providing replacement were stymied - IETF went not-invented-here finally getting v6, while USGOV went with CLNS, and meanwhile vendors hemmed and hewed to avoid spending any money on actually implementing changes and then allowed NAT availability to crush arguments and mandates.
IPv4 "works" and ISPs are incredibly resistant to changing things that "work".
Because support is needed basically end to end, it's going to take an ungodly amount of time for ISPs to figure this stuff out.
It's pretty frustrating having all my hardware support v6 with the only barrier being my ISP who refuses to support it in my location (they support it in other locations).
Except for people. Specifically, wireline end users. Triply so if they're on Fiber.
ex: T-Mobile fiber rollout is IPv4-only and CGNAT.
Half. The. Internet.
What a failure. /s
Most other large eyeball networks have as well.
Most mobile devices are only issued an IPv6 address and therefore when the masses do google searches it uses IPv6 and makes it look like there is huge adoption.
So that measures everybody who has working IPv6. https://www.google.com/intl/en/ipv6/statistics.html
You seem to be asserting that dual-stack machines use IPv4 by default, but that's not really true. If your machine has both IPv4 and IPv6 connectivity, browsers will in fact use IPv6 to connect to sites that support it, like Google. They prefer IPv6 by default and fall back to IPv4 if IPv6 is slower (Happy Eyeballs algorithm).
Of course, random software can mostly use whichever it wants, so I'm not claiming every process on such a machine will use IPv6, but most common stuff does.
ipv4 accidentally provides "casual anonymity" and "one ip does not identify device", which is incredibly important in this age of overbearing surveillance by government and private companies. ipv6, even with the "privacy extensions", is one subpoena away form directly identifying your individual device. ("ISP X: who did you assign this block of ips to on Y date?")
ipv4 has a boatload of issues (the worst of it is probably the unused and 'dangerous' flags), and ipv6 offers a boatload of cool features (The most beautiful is probably the flow state tracking).
However ipv6 was designed in a naive vacuum where no one possibly imagined the internet being abused to destroy an individual's inherit right to anonymity.
Oddly enough, the people most hellbent on spying on you: Facebook, Google, etc are the ones screaming for ipv6 the loudest.
There’s no way in which IPv6 is less private than IPv4. An ISP issues your house an IPv4 address and an IPv6 /48 network. Both of those can be subpoenaed equally. The privacy extensions work as advertised.
And in reality land, the big companies are the ones pushing for the upgrade because they’re the ones hardest hit by IPv4’s inherent limitations and increasing costs. Same rando in Tampa isn’t leading the charge because it doesn’t affect them much either way.
With IPv4 behind CGNAT you share an address with hundreds of other users. This won't protect you against a targeted subpoena, but tracking companies typically don't have this kind of power, so they have to resort to other fingerprinting options.
On the other hand, an IPv6 address is effectively a unique, and somewhat persistent, tracking ID, 48/56/64-bit long (ISP dependent), concatenated with some random garbage. And of course every advertiser, every tracking company and their dog know which part is random garbage; you are not going to fool anyone by rotating it with privacy extensions.
For tracking purposes, an IPv6 address is 48 bits long. That’s what identifies a customer premise router, exactly like a IPv4 /32 identifies one. The remaining 80 random bits might as well be treated like longer source port numbers: they identify one particular connection but aren’t persistent and can’t map back to a particular device behind that router afterward.
For some reason, "CGNAT == privacy" is a very common sentiment on Hacker News. Yeah, Hacker News. It's bewildering, and after my last comment [0] talking about it, I have kinda already given up trying to convince people that CGNAT is devilish and not at all a privacy protector.
Perhaps this is the difference, some people are concerned with being anonymous from companies like google, amazon, etc. Some don't mind that, as long as they are anonymous from a government.
Your mention of subpoena suggests you don't care about google tracking you.
Some public evidence: https://www.alphabetworkersunion.org/press/google-lays-off-c...
The people I want to protect my privacy from are google, facebook, amazon, they can't subpoena my IP, they can track me just fine though.
The tracking is a moot point. You can be tracked using the same technologies whether you connect though v4 or v6, and neither stack has the advantage there.
I’m aka unsure if IPv4 really gets you the privacy advantages you think it does. Your IP address is a data point, but the contents of your TCP/HTTP traffic, your browser JS runtime, and your ISP are typically the more reliable ways to identify you individually.
The downvotes are because you’re needlessly combative, preemptively complaining about downvotes.
Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.
CG-NAT gives more privacy benefits as you have more devices behind the same IP, but the other means of tracking still tend to work.
For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface. Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work. I still don't see any benefit to me, the user.
Yes, browser fingerprinting is a big issue, but it can be mitigated. The first thing everyone should do is to use a network-wide DNS blacklist against all known trackers (e.g. https://github.com/hagezi/dns-blocklists) and run uBlock Origin in the browser.
You can go further and restrict third party scripts in uBlock, or even all scripts. This will break at lot of websites, but it is a surefire way to prevent fingerprinting.
Then of course there is Tor.
This one was particularly scary: https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.ht...
Sigh...
Yep. For the OP, IPv6 "Privacy" addresses do what he's looking for. You can change how long they're valid for on Linux, so you can churn through them very frequently if you wish.
> Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work.
Odd. I've been using IPv6 for like fifteen, twenty years now with no trouble at all. If you've been using a "single stack" IPv6-only network, well, there's your problem.
> For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface.
The attack surface with IPv6 is exactly as large as if each of your LAN hosts had a globally-routable IPv4 address. Thinking otherwise is as smart as thinking that the attack surface on a host increases linearly with the number of autoconfigured IPv6 addresses assigned to that host from the same subnet.
If you don't want the IPv6 hosts on your LAN to be reachable by unsolicited traffic, set the default policy for your router's ip6tables FORWARD chain to DROP, and ACCEPT forwarded packets for ESTABLISHED or RELATED connections. If you're not using ip6tables, do whatever is the equivalent in the firewall software you're using. If you know that you have rules in your FORWARD chain that this change would break, then you already knew that you could simply drop unsolicited traffic in the FORWARD chain.
Unrelated to that, I see no reason to get rid of IPv4.
I expect that the future will be that nearly all "residental" [0] and non-datacenter business connections provide globally-routable IPv6 service and provide IPv4 via CGNAT, as IPv6 will be used for servers deployed at these sorts of sites. [1] I expect that the future will be that all datacenters and "clouds" will provide globally-routable IPv6 to servers and VMs, and globally-routable IPv4 to the same by way of load balancers.
So, home servers [1] will use IPv6, datacenter and "cloud" servers will use IPv4 and IPv6, and "legacy" devices that work fine but will never have their IP software updated will use IPv4.
I see IPv6 as a "reduce the pressure on the IPv4 address pool" mechanism, rather than a "replace IPv4" system. Again, I see no reason to get rid of "short" IP addresses. Default to using "long" ones, and keep the "short" ones around just in case.
[0] I'm including people's personal mobile computers in this definition of "residential".
[1] "Servers" here include things like "listen" video game servers or short-lived servers for file transfers and stuff like that.
"IPv6 just turned 30" - literally the first part of the post title.
The rest of the post is equally baffling, you are just clinging to a legacy bottleneck (NAT) that was never designed to be a security feature
It's virtually always used with some firewall rules, so it sort of is? It's just dogma to insist that there are no security benefits to having a single choke point for traffic.
Take a look at the IPv6 Google graph that everyone loves so much:
https://www.google.com/intl/en/ipv6/statistics.html
You can clearly see an initial steep spike to the curve where mobile adoption was new and fierce, and then the curve starts slowly becoming less steep over the last 10 years. It will peter out and remain steady when mobile device adoption reaches critical mass.
to protect your privacy
