I set up IPv6 on all my servers in 2001 and thought we'd all be on IPv6 in just a couple of years :P
What's interesting is how much resistance there is to adding IPv6 which comes from entrenched IT. People who never learned (much) about IPv6 seem to be afraid of it and often respond with some variant or another of "don't fix it if it ain't broke", or "it's extra work for no return", or "we'll have to pay licensing to add IPv6 because we bought crap routers, so let's not", et cetera.
My favorite is, "we have no record of people trying to use IPv6" - yes, that's real :D
It just shows their ignorance. Adding IPv6 has myriad advantages - no need for NAT, proxies or port forwards to share addresses, no need to renumber networks if allocations or upstream change, redundancy, valid security-through-obscurity (imagine port scanning a /64 looking for open ssh ports)...
What's really interesting is how many of these "we fear change" IT people don't realize they're already using IPv6 on their phones every day, with a majority of the sites they visit.
Had I spent the time to dig into it, I'm sure I'd have found the issue. And it probably wouldn't have been directly a true ipv6 problem. But I had more important things to deal with, so it moved to number 11 on my "top 10 list".
I'm guessing I'm not alone in that. So while individual teams and products might be working to support it, end users often see that it doesn't, because of some peripheral thing that's misconfigured, doesn't have support, etc. So they give up, which reduces perceived demand.
Not to mention it's extremely hard to know how to check the statistic you described without becoming aware you don't have the things needed to generate the statistics so this reasoning kind of rules itself out with the exception of AAAA records - you'll actually see those requests even if all you have is A records on an IPv4 only DNS server.
problem is that adding ipv6 gives none of those. Removing ipv4 would do so, but realistically most people are going to run dual-stack of some sort for a while, and as long as that is the case then adding ipv6 is mostly just additive effort.
The number one complaint I hear (and have myself) is that maybe I don’t _want_ all devices on my LAN to have public IP addresses. NAT makes security a lot easier to reason about.
This isn't a goal in itself. The formerly problematic and unwanted side effects of NAT, namely a broken peer to peer relationship of hosts on the internet, are now understood as a feature. Machines were forced by this technology to be clients and the initiators of all connections to the internet. Historically this has interfered greatly with several internet protocols (ftp, IRC DCC, p2p file sharing, ...) all mostly dead now or reworked to operate in a world full of NAT gateways.
IPv6 would reverse this state of affairs. If machines need to be denied the server role, this can be enforced by a firewall. As far as tracking of clients by IP goes, dynamic address assignment via DHCP or IPv6 privacy extension take care of that.
If you wanna block inbound connections, just drop them with your firewall. Most home routers already do this by default and if yours doesn’t, you better enable it for IPv4 too.
With the amount of legacy applications and systems populating the typical internal network that idea won't be going far.
Where IPv6 actually can be used and should be deployed in addition to v4 is in the perimeter networks. Offering or being able to use services on the internet over v6 (via proxy) overcomes the real shortage of ipv4 addresses in the internet at large.
I expect internal networks to be last places to be moved to IPv6 only.
Edge Firewalls -- source natting to allow access to IPv4 networks
Edge Firewalls -- destination natting to allow access from IPv4 to a service hosted on IPv6
Doesn't seem to widely adopted. It's all dual stack stuff, which means more work and more things to go wrong for no benefit.
Of course there's then the renumbering of your entire internal network every time you change ISP because you're using public IPs rather than private ones
For example, did you know that NAT doesn't prevent inbound connections? At least in v6 people are more likely to realize that, yes, they do need a firewall.
When you run dual stack, the v4 is there as backwards compatibility. It's lovely that people will simultaneously complain that v6 doesn't have backwards compatibility, _and_ also use the backwards compatibility it does have as a reason to not deploy it...
Right, you're only suggesting that they change out a fundamental part of the network for no benefit that they can see; why would they possibly object except out of fear and ignorance? After all, their fears are totally unfounded; most, probably all, of the random breakage and slowdowns that happened last time they tried to enable v6 have been fixed now.
I mean, yes, plenty of people don't want to learn new things for bad reasons, but plenty of people have insufficient time and have to make cost/benefit decisions - and you not liking their conclusion doesn't make them wrong - and there are a fair number of people who were all on board with upgrading a decade ago and got bitten by the then very real problems with IPv6 (which mostly boiled down to "not everything supports it properly, and lots of things fail ungracefully and create weird breakage").
Facts are these: IPv6 is a failure; it didn’t provide a way to conexist with IPv4 [1] and it did _not_ have a _compelling_ benefit to most people. The benefits cited makes no difference to most.
v6 provides lots of ways to coexist with v4. There's dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how can you argue it doesn't?
Have you ever worked at a IT department for a medium to large company? It’s usually a total shit show. IT gets blamed (justly or unjustly) for any issue with computers. As a result they become rather thick skinned and incredibly conservative in the projects they undertake.
So it’s not surprising that folks are unwilling to spend time on something they don’t have prior art for, haven’t operated before, and doesn’t offer significant benefits over what they already have.
Right. Our entire network is down and IT has no idea, thanks for the help Karen.
You learn to keep things simple and make as few changes as possible so you can't be blamed for other departments mistakes. "Network is up, haven't made a single change to infra in a month. Find someone else to blame."
So I see the “if it ain’t broke don’t fix it” more of a business problem and not an IT problem. I worked at one organization where for any networking work, you had to bill that time to a business project (which was usually a customer contract). proponents of IPv6 inside a business probably seem to the business like they’ve got excited over pointless science projects with nothing to ‘bill’ their time against
Many think cost of ip4 addresses but that hasn't panned out with solutions like NAT.
It is one of the more frustrating parts of trying to explain why we don't all just jump to do this.
So let's say I'm willing to migrate to IPv6, but I still need IPv4 for some reason (maybe I need to do the migration with multiple independent ISPs and every single of them is traveling at different speed wrt IPv6). This approach makes it impossible for me to switch where it would be possible, I cannot drop IPv4 yet, CGNAT-ed connection is unusable, but also I cannot use IPv6 where I otherwise could.
So I stay with IPv4.
For example see the video "T-Mobile’s path to IPv6 Only":
Regardless of the IPv6 situation, IT departments take this position for a reason. It might be obvious to individual engineers how to safely deploy IPv6 on their home network if they fully understand all the moving parts. But large corporations with deep legacy to maintain don’t have the luxury of running a fully understood system. Isn’t that a big risk? Hell yeah, and of course they’ve all got modernization projects running. But in the meantime, they fear change - legitimately.
And quite honestly the default configurations for IPv6 on consumer routers is "wide the fuck open"--which is not at all what I want. But if they don't make it "wide the fuck open" suddenly you are asking normal people to learn how to punch holes in their firewall.
I have to do all of that in v6 land (perhaps my user interface will allow me to manage the firewall rules together, but I'm still doubling my testing). On top of that, if I change my ISP, I have to renumber my entire internal network rather than just change the public IPs.
It's not even common practice to have a v6 only network and nat from v4 to v6 at the edge, and more crucially it seems from this thread that v6 removed it's v4 compatability layer (so I can't type "ping 1.2.3.4" and have it translate that to "ping -6 ::ffff:1.2.3.4", with my 6:4 gateway handling the nat
Until people start using v6 only, where's the benefit in increasing my workload?
Yeah everyone says this but I can't access any ports on my IPv6 address from outside my home network.
Back to IPv4 + NAT + port forwarding, I guess.
I have bigger problems I need to solve in my life right now. When one day I can just ssh <my-ipv6-address> from the outside I'll do that. Thanks.
Also, there's the DNS problem. I can remember 10.0.0.3, 10.0.0.20, etc. pretty damn easily. I can't remember 8cef::fasd:8000:c00a:::99aa:::::81/42:8fe that easily.
Which is an issue when things like 'foobar.local' don't work half the time. I have the IPv4 addresses of all my internal machines memorized thanks to the the fact that .local just doesn't work, period.
You can't access a service on a server on your local network using your router's global IP. You should use server's global IP address (and open the port for that IP on the firewall).
If your server uses SLAAC, it will always use the same local address (whether using EUI-64 or stable privacy), or you can configure it manually. In either case the address won't change.
NAT made you think in a different way, but if you started with IPv4 before there was NAT, this setup is exactly the same as it was with IPv4 a long time ago.
If I type ifconfig on my machine I only have one 'inet6' address and it isn't reachable from the outside.
The relevant people who want to popularize IPv6 should make that "just work". Until then IPv4 works for me, and a port forward is easy to understand, I don't need to google what SLAAC and EU-64.
They advertise it as "oh you don't need a NAT" but in reality IPv4+NAT is easier to deal with.
Most of us have actual jobs and don't have time to also be devops people.
I realize this sounds like a shitpost, but this UX is exactly why IPv6 isn't popular yet. If you want something to be popular, you need to make it easier not harder than the current thing everyone uses.
fd::1
fd::2
fd::3
You can even do:
fd::10.0.0.1
fd::10.0.0.2
Is that US specific? Because as far as I am aware only 5G "purposed" ( I am not sure if it mandatory ) the use of IPv6. 5G requires the support of IPv6, but not usage.
As the sibling points out, if both site and device support v6 the intermediate translation isn't required.
It means that the phone doesn't have to talk through a network-translation box, which may add latency. For some things (gaming?) this may be important, while for others it may not be.
Further, the price of each IPv4 address is going up, and so having your hosts on IPv6 may allow for the lowering of your costs, which you can pass onto your customers or add to your margin.
About a year ago they were US$ 30/IPv4, and they now seem to be in the $50 range:
Your device's network stack first learns if your mobile ISP supports ipv6 or not, and based on that and DNS reply decides how to connect to a given website.
(Most US carriers have IPv6 enabled and issue IPv6 addresses to their phones.)
Not true on my german mobile carrier O2. They only provide IPv4 behind a CGNAT.
I certainly support it, but I'm not sure we'll see an end to NAT for some time, even with an IPv6 option.
https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...
However the day the issue is solved, and ee can forget IPv4, a myriad issues dissapear - routing, port forwarding, P2P software for torrents and calls, multiplayer games, etc.
IPv4 addresses are a significant competitive moat for incumbent businesses. Existing companies have no interest in making IP addresses a non-scarce resource that aids competitors or alternatives (on-prem hosting, p2p, local ISPs, etc).
The only reason things have begun changing recently is government mandates and that the moat has gotten so big that they've started falling into it themselves.
1. Lack of basis in reality. While of course there are occasional cases of communities mismanaging resources, this was and is far from univeral or usual. In fact the english public land that the thought expermiment gets it's name from and claims can not work had succesfully been in common ownership for to my knowledge all of recorded history until it's relatively recent enclosure (privatization).
2. It supposes the commoners would desire infinite short term growth above and beyond what they needed, could personally tend to or the land could sustain. This is both ahistorical and circular logic. In reality commoners had long known the amount of cattle the commons could sustain and allocated limits among themselves.
3. Where examples of over-grazing do exist, it was as a result of deliberate action by wealthy people to drive commoners off of the land for enclosure. This is not unlike the patterns we do commonly see in the real world today, where resource exhaustion generally takes place when there there are big power differences.
4. Far more than as a prediction of reality, it has been successful as a justification for various unsightly things, from land theft and colonialism past and present, to eugenics and global poverty. It is not a neutral description of human nature and historical tendencies, but a distortion of them that aids the wealthy and poweful.
If you are looking for a better alternative I suggest you look at the power relationships between the people who are using the commons instead, it's usually much more enlightening.
Well, you are gonna have to replace port forwarding with firewall rules instead. At least for me, I really don't excited about my parents or in-laws internal networks being wide open to the internet. Thus their entire subnet would need to sit behind a "default deny" firewall. And if they need to expose some service to the internet, they'd need to punch a hole in the firewall--which is exactly the same dance you'd have to play with port forwarding.
The only thing IPv6 brings to the table for consumers is each device gets a globally routable address. But that doesn't mean each device can or should be be reachable from outside the router. One way or another client software will not get away from having to open ports on the router.
And some kind of UPnP will still be required even if your internal network were using ISP-assigned IPv6 addresses for protocols that want to open multiple connections, like VoIP conferencing, bit torrent etc.
Of course, if you have an internal network where you actually communicate between your various machines, you won't want to use ISP-assigned publicly routable IPs, since those can change at any time, so you'll also need some kind of network address translation at the edge.
The difference being, with IPv4 only one machine in the house can have a port open. You don't just open a port, you choose _which_ single machine gets the port. Sometimes you can't open a port on a machine because the port's already taken.
With IPv6 any/every machine can have the same port open at the same time.
One of these scenarios is obviously just broken.
IPV4 addresses are scarce due to lack of foresight and useful.
NFTs are scarce by design and useless.
What utility do NFTs provide other than entertainment/status?
Until everyone moves to IPv6, if you want people to be able to reach your service, you need an IPv4 address. If you're an ISP or cloud provider, you need those so your customers can still communicate with v4-only peers.
ipv4 addresses are unique in the default free zone. they cost money because without having a prefix that is unique, you cannot route across the internet.
How's that work? It can't be sending actual v4 traffic or it'd work like normal v4.
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.044 ms
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.043 ms
$ ping6 127.0.0.1
ping6: 127.0.0.1: Address family for hostname not supported
[0]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
I haven't heard it called a political issue before though. It just had problems, like being blocked in firewalls and security problems where the encapsulated packet wasn't checked properly, etc.
https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-...
... "Each hexadecimal character in an IPv6 prefix represents one nibble, which is 4 bits. The length of a delegated prefix should therefore always be a multiple of 4.
A single network at a customer site will be a /64. At present, RIR policies permit assignment of a /48 per site, so the possible options when choosing a prefix size to delegate are /48, /52, /56, /60 and /64.
...
The following sections explain why /48 and /56 are the recommended prefix assignment sizes for end customers.
...
It is strongly discouraged to assign prefixes longer than /56 unless there are very strong and unsolvable technical reasons for doing this."
A /64 is the most valid IPv4 prefix there is. Most consumers should be given multiple (usually about 16) and the router starts with the first one.
> And if you get a /128 prefix, good luck that
No kidding, that's a single address subnet!
> NATs are apparently disallowed in IPV6 world.
It's allowed it's just not the right answer in the vast majority of cases.
Also, honestly, using IPv4 on LANs still makes sense no matter what trend the internet goes for.
$ ssh freenas.local
freenas$ ping6 2606:2800:220:1:248:1893:25c8:1946
ping6: UDP connect: No route to host
freenas$ ping6 2606:2800:220:1:248:1893:25c8:1946
PING6(56=40+8+8 bytes) 2600:1700:3d40:6300:6a05:caff:fe58:a370 --> 2606:2800:220:1:248:1893:25c8:1946
16 bytes from 2606:2800:220:1:248:1893:25c8:1946, icmp_seq=0 hlim=54 time=11.408 ms
(AT&T is my ISP and it took a bit of screwing around over a weekend with my router a couple years ago to get IPv6 working properly on my home network. But it's been painless ever since.)
AT&T has transitioned to issuing a combined ONT/Router, where this will no longer be possible, but apparently the newer gear doesn't have any of the performance issues of the Pace 5268AC.
BTW, I was annoyed that AT&T installed the ONT on the southern wall of my home where it was baking in full sun everyday, so I relocated it myself into my network closet. You can just unplug the ONT and extend the existing fiber with an optical coupler and an SC-APC to SC-APC single-mode patch cable.
Have you heard what gear they are using for the new >1G deploys? I haven't kept as up to date with ONT/GPON gear the last couple of years but I'm curious what they have that does 5 gigabit NAT.
It should be a greater proportion by bandwidth, cause several huge sites support IPv6 (Netflix, Youtube, Facebook etc), but I can't find figures.
- IPv6 is basically an abandoned standard. I wouldn't expect them to support gopher either.
- Residential ISP support for ipv6 is spotty, and anyone who does offer ipv6 offers ipv4 as well.
- When it is supported, ipv6 tends to be substantially slower than ipv4 in practice.
- The addresses are a pain to look at and work with.
- You now have twice as many things to fail.
https://www.google.com/intl/en/ipv6/statistics.html
IPv6 is also usually faster than ipv4 these days, because the overhead of fragmented ipv4 routing is large. In the past it was slower because of lack of understanding/support for it from larger ISPs, and consequently poor routes, or really suboptimal tunneling setups.
My ISP firewalls IPV6 addresses on their end, so no ssh to my IPV6 Machines from the outside, not even ping works. I don't know why they do this
Techies like you and I can appreciate the technical arguments, but if we want to convince anybody else who can actually make decisions for large numbers of ordinary people, we're going to need better arguments.
> I’m still not totally sure how this works but it sounds cool.
Naively I would say this is completely impossible without some form of your home router (or ISP?) relaying your traffic, or perhaps telling the sender that I am now actually located in a different subnet somewhere. If anyone can have IP(v6) addresses and keep them and take them with you, then wouldn't that result in an unmanageably large lookup table at routing nodes to know where to route stuff to?
How does that work?
There are a couple of gotchas though. Firstly, there is generally a minimum prefix size of routes that will be accepted into the global routing table. For IPv4 I think it is a /24, and for IPv6 I think it is a /32. You can get a /32 from regional IP registry (for free?) but you will probably need to become a member which – last time I checked - costs 3-4 figures a year. You can use a private-AS number though, as you'll only have one upstream provider.
The other gotcha is cost. Depending where you are in the world, a DIA connection will cost in the very rough region of (EUR/USD/GBP) 1/megabit/month, although it becomes much cheaper when going from 1gb to 10gb.
Now maybe there is some cool facility that some nice ISPs offer to bypass all this, if so then please let me know. I'm personally skeptical it would be worth their while for the 0.001% of residential customers that would want this service though.
Source: I run a small ISP. I have some industry knowledge, but not loads.
Currently there are about a million ipv4 prefixes advertised. And about 150k ipv6 prefixes. Some older ipv4 equipment has a limit of 1024k, or near 1 million advertised prefixes. This equipment is usually 15+ years old, but still is what runs the internet. Generally equipment that supports ipv6 can support many more networks
You can’t upgrade to IPv6 you have to port your code to IPv6. There’s no concept of broadcast domains, IPSec built in for some reason — sorry WireGuard. And because IPv6 is fundamentally different it’s not enough to just be like okay all my shit is IPv6 capable turn it on, you also have to rearchitect your network since everyone builds their network with the concept of public and private addresses and IPv6 is/was openly hostile to it.
TLDR IPv6 made it really god damn hard to just turn it on. Would it have been so bad to just support the way of the IPv4 world for compatibility and then say “hey there’s this cool new thing that’s better” which is an easier sell once you’re already using IPv6.
There is no physical way to increase the address space without requiring code changes. People having making the same complaint for 20 years and it's even more hollow now then it was then.
99% of the time, you will use your OS standard library functions and completely ignore the networking underneath. Literally, all the libraries will transparently handle IPv4 or IPv6 with no problem.
If you're in the 1% of software that has coding in some implicit assumption of field size for IPv4 then you are the 2020 equivalent of the Y2K problem. Grow your field sizes, fix your regexes, and use the platform support as much as possible.
Finally, you can literally just turn on IPv6. Everything will work just fine. IPv6 has private addresses, you can do all the dumb stuff from IPv4 in v6. Unsurprisingly though, most major vendors don't want to spend a lot of energy supporting those hacks.
You don't need to rearchitect your network either, because v6 fundamentally works in exactly the same way v4 does. All you need to do is deploy a v6 /64 everywhere you have a v4 /24 (or /22 or whatever).
There's really not much that's different between them at all... and making v6 64 bits wouldn't have helped either, because that would have the same compatibility issues that v6 does while also not being big enough. It'd be pretty silly to go through all this to deploy a new L3 protocol, only to then have to do it again because we didn't make it big enough the first time.
What would be the best way to get ipv6?
Clearly there’s pain points to rolling out v6 (although I’d question how many of them are still an issue outside the glacial pace of Enterprise IT) and we’d be better trying to address that than re-hash the same old arguments.
Edit: not much more than 2 weeks ago we had this chestnut [1] where Nintendo was telling you to forward thousands of UDP ports to a Switch in order to play online but still we hear “but NAT works fine for me”.
The truth is like most topics in computing after 20 or 30 years of using one protocol/interface the baggage, limitations, or cost of the old keep piling up and eventually the new thing is going to seem like less work/cost/baggage than the old.
The thing that seems to be moving it forward the most nowadays is cost and baggage (= complexity = long way around to more cost). The direct cost is per IPv4 prices going from ~$25/per to ~$45/per in the last year alone. The baggage/complexity cost is particularly on the carrier or large enterprise side where ever growing device counts and ever growing public address costs combine to make NAT needs larger and sometimes multi-staged (e.g. CG-NAT).
I think the breaking point will be when we start to see most hosting providers and carriers continue to either push consumers to more IPv6 to reduce NAT load or cost incentivize hosted services to do the same. There are limited instances of this now, an occasional hosting provider offering IPv6 only for a lower monthly cost or a mobile carrier that migrates all of it's users to IPv6 transparently, but there are still more providers/carriers that don't do anything IPv6 than there are that incentivize IPv6. Definitely moving in that direction these last few years though.
What I don't think we'll see is a sudden "aha" moment where people give up IPv4 and stop being uncertain about v6 just because they read about it more or were told some detail.
Yeah, it doesn't feel like that long ago when consumer routers with tiny translation tables would crash hard when anything opened a load of connections (think games but especially BitTorrent) because they didn't have much RAM.
I think for most people the switching moment will be something they don't even see - their ISP enables it and off they go.
https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-ka...
A fast NAT gateway which is lightly loaded might make little difference, a heavily loaded one can make a big difference.
Google stats also show slight latency improvements for IPv6: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Of course these are generalised stats, there will be some users with tunnels which will impair IPv6 performance, while other users might be behind multiple layers of NAT.
https://datatracker.ietf.org/doc/html/draft-iab-case-for-ipv...
(EDIT: Updated to non-archive link provided by cesarb)
And the way to "resolve" it is IPv6.
Home servers are not quite as easy as the article makes it sound. Home routers block incoming IPv6 packets, the same as they do for IPv4. To make a home server accessible, you need to explicitly allow that incoming IPv6 traffic in your router's firewall. This is analogous to adding a port forward rule in IPv4 NAT. The only benefit IPv6 has here is you can use the same port (e.g. SSH) for multiple home servers.
(Don't judge, it's faster than the last ADSL connection at about 80Mbit/s on a good day, much cheaper, and the office goes through about 40GB/month no problem.)
The phone has an IPv6 address but no IPv4 address.
Ironic, then, that the hotspot only provides IPv4 to all connected devices, not IPv6. As a result, all connected devices in the office can only use IPv4.
My home ISP is a mobile 4G router providing wifi.
The router doesn't get an IPv6 from upstream, just IPv4, so it only provides IPv4 to connected devices at home. I have no idea if it would provide IPv6 service if it got one from upstream. It is a little strange that it doesn't get IPv6 from upstream, because it's exactly the same type of mobile data contract as the office phone-router is using.
It's 2022. I've had IPv6 on my servers since about 2003.
But aside from my actual phone, I've never had IPv6 on any device I'm using, living at numerous homes, using many and varied ISPs, working at numerous offices, or anywhere else. Not even when travelling.
I had to turn off IPv6 on my mail server, because gmail.com was rejecting mail from it when sent over IPv6, but not when sent over IPv4.
I use LXD and Docker on some of my servers for containers, and libvirt/KVM for VMs. In theory they support IPv6 but in practice it's easier to work with IPv4 address or port forwarding with them. That means the containers and VMs are only reachable from the internet over IPv4, even when the host servers have IPv6.
All together, anything I do to support IPv6 ends up poorly tested because it's not really used, and everything has to be done with IPv4 in parallel anyway.
I still have IPv6 on my servers, and DNS configured appropriately. But as it virtually never gets used, it seems a bit pointless. Sometimes I don't set up IPv6 on a new server straight away, and nothing is missed.
Here at least the mobile network uses cgnat for ipv4, but fully routable ipv6 - so the only way i can get inbound connections over the mobile network is to use ipv6.
I kind of assumed that this was true nowadays for most home ISPs.
Now I'm in the Boston MSA (a very rural place, I know /s); the ISP here, Verizon, does not offer IPv6. (They state they are "rolling it out", but this year will be the fifth anniversary of that.)
Shoot, Kubernetes _just_ got support for IPv6 in 1.23 (it was in beta since 1.20). I know that 6to4 exists and many kernels can do it out of the box, but that comes with problems, as Julia rightfully pointed out here, and at that point, you might as well just NAT over IPv4.
I'd recommend diving into the more detailed articles it links on SLAAC (alternative to DHCP, most common way to dynamically assign addresses) and NDP (replaced ARP) for a full understanding. If you want to go all in for v6 only setups with access to the v4 internet NAT64 is worth reading as well.
Obviously it doesn't cover how to configure/implement for your specific scenario but it gives a solid background that lets you better understand what guides for doing it with Linux or prosumer hardware or typical consumer hardware are actually talking about.
v6 is a mechanism like container ships. It will dominate when the incentives and disincentives make sense for the participants.
Of course I'm not implying that IPv6 isn't nice to run inside your infrastructure but I guess it isnt at the top of ones expenses.
It was a huge mess (the autoconfig functionality, naming, routing) that all sort of failed in ways that involved deep hacking to debug. Ultimately I realized that since most sites on the net aren't ipv6, I'd need to NAT or proxy my traffic to them anyway.
Let me know when we're ready to turn off IPv4.