That's because most of the people got online via mobile phone. It only grew significantly faster due to Covid and Indian market flooded with cheap smartphones made locally as well as from China.
About half the mobile phones sold in India in the last decade or so were either assembled, or even substantially manufactured (i.e., including the semiconductors) in India. It's becoming one of their larger industries. More than a billion units in 2021, most very cheap models you won't encounter in the West. Certainly enough to satisfy the domestic market, and then some.
Include the semiconductors? Hope they soon flood the world with their RISC-V performant mobile chips... ok I wish that, because I know this is one of the only ways to rid the world for some ISA toxic IPs...
I have AT&T Fiber at home and have IPv6 turned off at the router because I don't believe consumer grade firewalls are as good as plain ol' NAT traversal for basic security. IPv6 seems to want everything directly connected to the Internet which I find crazy.
Update me - am I crazy? Is this old info or a bad take?
Yes. With IPv6 there are still stateful firewalls on routers. An app/service still generally needs to do firewall hole punching via UPnP or PCP. The main thing that goes away is the rigamarole of figuring out the public IP address:
The only difference between NAT traversal and zone based state firewalling is whether you translate the address before you put it in the state table. The security functionality is roughly identical, NAT itself is not actually the security layer it just forces having the concept of tracking what is outbound initiated to work.
In pure academic sense you can have NAT without disallowing inbound initiated sessions to internal addresses but that's insecure because it's just hiding the routing information not actually blocking inbound sessions.
The only thing to worry about with the gateway they give you for AT&T fiber is if you have the crap model that has an extremely limited session table (4k) and if so you should ask for the new one (16k). This applies regardless of IP version preference.
> The only difference between NAT traversal and zone based state firewalling is whether you translate the address before you put it in the state table. The security functionality is roughly identical
Except that not translating your IP address means allowing certain types of tracking that NAT prevented. One unique IP address per device means that with nothing more than a list of IP addresses and timestamps servers can identify the number of devices you used on your network to connect to them, and can track which device was in use at which time. NAT prevents that scenario very well.
IPv6 has some features around this, most commonly implemented on devices (even more than just grabbing an assignment and sticking with it) is using temporary address assignments which change over time.
Neither NAT or IPv6 randomization really do much for tracking prevention though. Servers get to see a lot more than just source port (~2 bytes of fingerprinting info) and source node (~0-2 bytes depending on the number of devices in the network) e.g. even just a TCP handshake has a larger fingerprinting signature and that's before you've even gotten to the application level protocol you're talking to the server with or the data in the connection itself.
With enough effort you probably could enumerate the devices on a remote network using NAT, but the amount of effort matters too. NAT is easy for most end user's needs, works with a huge number of devices/gateways and somehow does a decent enough job at keeping the internet from passively learning about each of the devices on your network and tracking them over time that it's foiled the plans of many site operators and nosy organizations looking to do just that.
Granted, there are other ways to track devices and as long as an application can be installed on a device and communicate to the outside world it can share whatever data it wants, but the last time I looked into it IPv6 made the situation worse not better, and there were multiple flaws found in its privacy extensions. It's admittedly been a few years and so maybe things have changed and it's time to give it another look.
> passively learning about each of the devices on your network and tracking them over time that it's foiled the plans of many site operators and nosy organizations looking to do just that.
Again passive learning (i.e. your device just existing and getting scanned) never happens in either scenario as inbound scanning is not possible in home or office in either IPv4 setups or IPv6 and it has nothing to do with where NAT is at play inbound initiated sessions aren't allowed in either case. I.e. just because you send a packet to <IP> does not mean a home or corporate router is going to allow it in, it's going to check if that conversation exists and if not it's going to check if the conversation started from the inside or the outside. If the latter it gets dropped, routability be damned, as it'd be insecure to allow anyone to connect to anything internal just because they sent a packet to that IP. This tracking is done at the L4 level, i.e. just because you opened a TCP session to a server using some high range outbound port doesn't mean that server will be allowed to send a packet back to you on e.g. 22 SSH it only means that specific tuple (ip:port:ip:port) is allowed bidirectionally until the session is closed by either side or times out from inactivity.
I'm not exactly sure which ways IPv6 makes it worse, as mentioned pretty much all devices (Windows, Linux, Mac, Android, iOS) use temporary IPs and have for well over a decade. Nobody is tracking individual user clients by IP address alone, be it v4 or v6, they are doing it with the troves of data in the higher layer protocol information where they can identify each device uniquely.
You can dislike IPv6 if you like but you shouldn't just make fear mongering claims of why it's bad for privacy if you don't have enough experience with it to know how it is designed to avoid these very issues.
On any modern Windows, MacOS, BSD, or Linux install, your system maintains multiple* public-routeable IPv6 addresses at once. New connections are opened on the newest address, and the old addresses are retired as legacy connections are closed. SLAAC (stateless autoconfiguration) allows the system to automatically configure new addresses at-will. Two web pages that you open within seconds may not see the same IP address when you use v6.
For example, the computer I'm typing this on currently has 9 public-routeable IPv6 addresses (plus additional link-local and private addresses), on one NIC. That's the normal state of IPv6, not some exotic configuration. It "just happens" when you have SLAAC set up.
You could, if you wanted (though I don't know of any OS that supports it) open literally every new connection from a new address.
IPv6 also has better multi-homing support, so you can distribute your connections among multiple ISPs (and, again, with SLAAC, configuring IPv6 addresses from multiple routers on a single NIC is trivial).
I actually do kind of like the idea of a new IP for every connection...
I haven't had much time to look into it recently, so maybe the situation has changed, but I do recall seeing multiple issues with SLAAC and other privacy features (not just involving EUI-64) still leaving devices trackable in common situations, and even that's only where it's supported.
Hopefully there are workarounds and patches for the issues that have been identified so far, and I should probably take another hard look at the current state of things but the impression I got just a couple of years ago is that if IPv4 can be made to protect privacy it'd still be way too complicated for most end users where NAT pretty much just works, and works with most devices and gateways.
Interesting. You're right - I just found a reddit thread from a few months ago and ATT fiber seems to still have horrible IPv6 support, for that reason and others. I think I'll leave it off.
The conntrack table on the BG320 is 8k regardless if it's doing NAT with v4 or plain session tracking with IPv6. You just want to make sure you don't have the older model with the 2k limit as that'll cause problems for even light usage households.
The way the IPv6 rollout is broken on ATT is the same as their IPv4 rollout is broken, they don't support bridge mode. Passthrough IP doesn't quite work the same as traditional bridge mode and still hits the conntrack limits. DHCPv6 and PD work fine though, I have it configured right now.
> Update me - am I crazy? Is this old info or a bad take?
1. NAT does nothing to prevent network egress. NAT is not a firewall--it monitors outgoing connection to remember how to re-write incoming packets. Any IoT shit or malware that wants to call home to a control server is free to do so.
2. Most consumer-NAT implementation have a facility for "inside" hosts to map "outside" ports to "inside" IP address-port combinations (for games). The facility has no authentication, other than (usually) ignoring packets from "outside". So a single infected device on your network can poke arbitrary holes in your "firewall".
3. Most modern IPv6 stacks create new auto-configured addresses and rotate them on a regular basis (the address space is big enough to do that). So "your address" is constantly in flux. Obscurity isn't good security, but at least it makes it harder for the bad guys to know where to send the packets.
4. The IPv6 packet structure is simpler, so, in theory, you might expect fewer vulnerabilities in your IP stack.
NAT is not a security feature, nor is everything publicly exposed to the internet on IPv6. With most routers you would have to explicitly forward a port in the router to expose that to the client anyways.
> What are the practical implications for internet users and infrastructure maintainers?
For users: the widespread deployment of NAT has eliminated global end-to-end connectivity of the internet. That drives further centralization of the internet, as offering services requires expensive purchases of IPv4 space, big central NAT gateways and makes p2p applications difficult to impossible.
For infrastructure maintainers: the increased address space makes it possible again to allocate addresses as you wish. There's no need to architect your network around IP address scarcity. You can allocate pretty much as many networks as you want, for whatever you want, without worrying it's going to be too small.
Can you convince me that end-to-end connectivity is desirable in most cases? I certainly don't want ingress from the public Internet to devices on my home network in the general case, and I think it's kind of nice that the Internet only knows the address of my router rather than that of my physical machine (of course, there are other ways to fingerprint devices, but let's not make it easier than necessary). You definitely want a gateway to implement firewall rules, and I'm not sure whether I care if that gateway is doing NAT as well or not? What can I do with a non-NAT-ing gateway? The only thing I can think of is that cloud IP addresses aren't as carefully guarded (I don't get up-charged for an un-associated elastic IP address).
Being able to talk directly between peers has advantages. Most services today basically require some kind of arbiter who has a public IP address.
While there are ways to poke holes in NAT, it’s not really scalable. Also, you might be behind more than one level of NAT and not even realize it today. eg: When I ask a website for my IP, it shows something different than what my hotspot is assigned… and my hotspot is not reporting an RFC1918 address. This means I am already sharing ports with someone else on the public IPv4 address that the world sees. Also, no http proxy in the middle here.
As for obscurity of addresses, NAT is pretty easily guessed in most scenarios today. IPv6 has far more address space per network making it really hard to scan. That combined with privacy addresses that change constantly is a pretty compelling reason to use IPv6 over IPv4+NAT if what you care about is people not being able to guess your IP.
> Being able to talk directly between peers has advantages. Most services today basically require some kind of arbiter who has a public IP address.
Right, but you can't do this without punching holes in your firewall, and I assert that's not a desirable tradeoff, at least for consumer use cases. As far as I can tell, you still need an arbiter with a public IP address.
> While there are ways to poke holes in NAT, it’s not really scalable.
Agreed, but this is a relatively infrequent problem. It seems like there is some belief that IPv6 is going to make p2p stuff painless, but for most use case it's still going to require poking holes in something; however, for a few use cases (e.g., 2 game consoles in the same network) it will be significantly better. I definitely agree that there's some benefit to foregoing NAT, but it doesn't seem like it will improve most use cases and it certainly doesn't seem like it will deliver the painless p2p experience that many people expect.
> As for obscurity of addresses, NAT is pretty easily guessed in most scenarios today. IPv6 has far more address space per network making it really hard to scan. That combined with privacy addresses that change constantly is a pretty compelling reason to use IPv6 over IPv4+NAT if what you care about is people not being able to guess your IP.
My concern about obscuring addresses was more about making fingerprinting more difficult (some website can't just see my IP address and associate it with my identity), albeit this isn't a well-founded concern, and it could be mitigated by rotating IP addresses.
> Right, but you can't do this without punching holes in your firewall, and I assert that's not a desirable tradeoff, at least for consumer use cases. As far as I can tell, you still need an arbiter with a public IP address.
That's true, but setting up these firewall rules dynamically is way easier than setting up NAT mappings (for example, UPnP through two different NATs never works properly).
And even for consumer use cases, gateways could provide a way to allow all traffic to a specific destination, as most operating systems should provide a proper firewall. Of course, there is still work to be done, the UI for these firewalls should be made better (for example, allowing an application to request to accept incoming packets, and letting the user choose if it should only for the LAN, or for the whole Internet, etc).
Indeed IPv6 by itself will not make p2p stuff painless, but it's still a better basis than IPv4.
I certainly don't want ingress from the public Internet to devices on my home network in the general case
This is ultimately an operating system issue. For most of the history of the web, we've used NAT routers and firewalls as a fig leaf over the operating system issue. What is it? Operating systems are extremely promiscuous about listening for traffic on a multitude of ports. Operating systems are promiscuous about including a vast number of daemons running in the background handling a variety of tasks. Operating systems are promiscuous about running a bunch of daemons that phone home all the time.
All of this stuff is completely opaque to the user. All of it occurs on a default opt-out basis. All of it requires an extraordinary amount of knowledge for the user to feasibly withdraw consent. This is the operating system problem.
In another world, I can envision computers running operating systems which are totally transparent and easily understood by their users. All running services would be opt-in and users would be fully aware of exactly what's happening on their machines. That would be the world where end-to-end internet connectivity is highly desirable.
I don't think it's just an OS issue, because people often want promiscuity within their home network, but want a moat and drawbridge keeping the rest of the world from that network. There's too much value in home / office situations where you want discoverability enabled, but only to other devices behind your gateway to the internet at large.
Not only that, but you don't need your OS handling and selectively allowing or dropping every random packet thrown at your IP either. You don't want to even have to worry about an OS inadvertently revealing info about your devices because of how they're accepting/dropping packets or screwing that up and letting in things it shouldn't. You can offload all that work to your gateway and free up your devices to only handle the traffic that they actually care about.
You can still have a DMZ, servers, and devices directly connected to the internet, but a gateway with a stateful firewall is a wonderful thing and your typical gateway with NAT helps makes things dead simple solving far more problems than it causes.
Personally, I’d prefer not to have this isolation. I’d rather be able to access my home computer, printer, and other devices from anywhere in the world, not just when I’m at home. Moats and drawbridges are an anachronism from the Middle Ages.
Right, but you don't want anyone in the world to have access to your home computer and printer, right?
You're talking about a different problem: How can I extend the concept of my "home network" to the devices that I use and trust regardless of where I am? I'd argue that this is something that suggests that VPN functionality should get built into gateway devices.
Regardless, I don't want scammers in Malaysia port-scanning my 10 year old printer that's never going to get a security update.
I want anyone in the world to have access to my home computer and printer when I authorize it. Right now, to do that I have to configure my router as well as my operating system to allow it. But what if I'm not at home? I might be on someone else's network. Now I am at their mercy to configure the router so that my computer is accessible. In all likelihood, they will refuse to help me.
You're talking about widening your attack surface as wide as physically possible (no virtual devices yet). Now you need to ensure every device that can see the internet is perfectly impenetrable. How feasible you think that is?
Think doors and keys then. Or "smart locks" and "biometric scanners" if that's still not modern enough for you. There's a cost to convenience. Yeah, it'd be really convenient if your house didn't have any walls, you could just walk into any room from anywhere else. But so could any untrusted party.
Bugs and therefore vulnerabilities are inevitable. The larger your attack surface, the more likely some rando is to find a vulnerability and exploit it. No walls is real convenient up until someone unexpected walks right in and trashes the place.
It's ultimately an issue at every layer, hence "defense in depth". Every layer does its part for security, we don't punt because some other layer ought to handle it.
I realize the OP is about IPv6 but my comment puts the blame on operating systems. Between the operating system running on the server, through the routers of the internet and a user’s home router, through the consumer operating system running on the user’s laptop, and all of the firmware and
microcode along the way, there are many, many more layers involved what is specified in the OSI model.
And so many of these layers exist for legacy reasons, business expedience, and market failure. They don’t actually make things better.
> In another world, I can envision computers running operating systems which are totally transparent and easily understood by their users. All running services would be opt-in and users would be fully aware of exactly what's happening on their machines. That would be the world where end-to-end internet connectivity is highly desirable.
Even then, you have the issue of bugs - not just in the programs themselves, but also in the kernel-mode stack and even in the hardware. As long as something is reachable from the Internet, it will get scanned and assaulted from the Internet - and the lower your attack surface is, the better.
operating systems which are totally transparent and easily understood by their users
I sort of glossed over this part so now I have a chance to elaborate. Alan Kay has put a ton of thought into this issue [1]. He firmly believes that we can build an operating system and application software with an extremely small footprint (LOC's) so that a single person can understand the whole thing.
Since he gave that talk, we've moved further and further away from Kay's vision. We've made things more and more complex, opaque, centralized, and difficult to change. We've given away our future to big tech companies. Heck, we've even given away the past. We've lost much of the freedom we had back in the 90's, let alone the 70's and 80's when Kay did so much of his work. We're going to have to work incredibly hard just to regain what we've lost.
Why would I opt for a network topology that restricts what devices/operating systems I can safely use on my network? Especially when I already have a solution that doesn't restrict me in this way?
It's like saying, if a person walking around at night gets mugged, it's a "them" problem for not carrying a weapon to defend themselves. Uh, no, let's create an environment where even a completely unprotected child is safe. Oh wait, we already have.
> Can you convince me that end-to-end connectivity is desirable in most cases? I certainly don't want ingress from the public Internet to devices on my home network in the general case […]
In the IPv4 case you have NAT and a firewall. If you have some software that you want others to connect to (communication, gaming, etc) you have to punch a whole through the firewall (via UPnP, PCP) and then the software has to use a bunch of protocols to figure out what the public IP address of your router is: see STUN, TURN, etc.
With IPv6 you just have a firewall, which you punch a hole through when needed (UPnP, PCP) and you're done (because there's no futzing about with determining the network address). When the P2P session is done the whole is closed and you're protected again.
So if you have a 'home network', it cannot be reached from the Internet by default.
Note: you already have a device that's always on the Internet: your mobile phone. Lots of telcos are IPv6-only and you there's not NAT or firewall between it and the Internet.
In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy.
The two biggest use cases for direct p2p connections are multiplayer games and video calling. Latency is unavoidable if your traffic has to bounce around a third-party
> In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy.
Not at all--end-to-end encryption is still a very desirable property. I certainly don't want a consumer router decrypting my browser traffic even if it is re-encrypting it to send to my device. I'll tolerate HTTP proxies on the server side when I'm administering the proxy and I need layer 7 routing, but I want to avoid it wherever possible.
> The two biggest use cases for direct p2p connections are multiplayer games and video calling.
You still have to punch a hole in your firewall either way. The only advantage ipv6 has is that you can have two hosts listening on the same port (whereas port-forwarding in a NAT context only works for 1-host-per-port).
Tangentially, I was never a big fan of player-hosted games anyway because they tended to be more vulnerable to cheating and the host always had an unfair advantage (or else a dramatic penalty in the case of lag compensation). Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit (although a poorly written game server might still do just that).
>Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit
What prevents you from putting the same validation logic into the client, thus rejecting malicious packets at the destination?
I mean, correct validation logic is always ideal, but I'm positing a world in which software doesn't always get intentional validation logic. In particular, an intermediate server might prevent packets from flowing to the target client for any number of reasons which aren't intended as "validation". It's just harder to hack through an intermediary.
Ok, but I still don't see why you can't move that intermediary to the client. Spin up a docker container and run the game server there. Ta-da! You have the same security as with a remote server.
My point is that IPv6 restoring the end-to-end principle need not jeopardise the - real or perceived - security of multiplayer games.
It’s not clear to me who “you” is meant to refer to in this scenario.
If “you” refers to the user, then because the game isn’t architected to have a server running next to each client if the server binary is even distributed to users at all.
If “you” refers to the game publisher, then because they aren’t architecting it that way to begin with, because they aren’t thinking about running the server as a security feature.
Moreover, a game developer has incentives to protect its own servers; it has much less incentive to protect its end users. You might argue that it’s end users being hacked is bad for business, but most end users wouldn’t be able to attribute a hack to a particular piece of software or infrastructure if they even know they’re hacked in the first place (consider the rampant insecurity in the consumer router and iot spaces).
I love player hosted gaming. But the people I game with are looking for "fun experiences" (kinda like going to a movie as a group, but more interactive) rather than competitively climbing a leaderboard.
> Can you convince me that end-to-end connectivity is desirable in most cases?
p2p communications can be nice for latency sensitive communications. Sometimes it's faster to communicate from user A to user B directly instead of going from user A to server Z to user B (although, sometimes it's not faster... if latency is important, you really have to try all the accessible paths and use the best one, keeping in mind that paths may have asymmetric latency, so maybe you want A to send to B directly, but B should send to A through an intermediary; and path latency isn't static, so for a long session, if it's important, you need to probe throughout and change thigns around)
But, maybe you don't want your connection to be a full peer capable of receiving as well as initiating connections, you can run a stateful firewall on your end and drop incoming initiations. You'll still benefit from having end-to-end connectivity because it means your ISP can process your packets with basically no state, so there shouldn't be problems with connection state timing out and your connections being dropped without warning. If you run your own stateful firewall, you may still have that problem, but you might have less state required for a stateful firewall instead of a NAT, so maybe you can manage more connections.
> I certainly don't want ingress from the public Internet to devices on my home network in the general case
This is a job for a firewall. NAT is not a firewall. You can easily filter incoming connections to untrusted devices when using IPv6, with the advantage that when you want to allow a certain kind of traffic in you can do so without messing around with port forwarding or dealing with multiple devices competing for access to standard port numbers on a single public IP address. That's assuming you actually get a public IP address; if you're behind CGNAT then port forwarding isn't even an option, since it would need to be configured on the ISP's side and not just in your router.
If you enable UPnP for automatic port forwarding, as most do, then NAT isn't blocking much of anything. The only difference between NAT with UPnP and IPv6 with no filter preventing incoming connections is in whether devices which open ports but don't set up forwarding can assume that incoming connections probably came from the same local network. However, it's considered poor practice to treat access to the local network as a means of authentication. (Note that with NAT alone if your router receives a packet addressed to your local network's private IP range, and not the routers public IP address, it will forward it unmodified; preventing that is a firewall function, not a NAT function.)
> and I think it's kind of nice that the Internet only knows the address of my router rather than that of my physical machine
If you use IPv6 with privacy extensions enabled then the Internet will only know your /64 network prefix, which is basically the same thing (unique per subscriber and subnet). The rest of the address will be randomly generated and short-lived, unless you choose to assign an additional long-lived address e.g. for a server.
> I'm not sure whether I care if that gateway is doing NAT as well or not? What can I do with a non-NAT-ing gateway?
Doing NAT isn't the problem, requiring NAT is. When the architecture requires NAT devices can't receive incoming connections without port forwarding even when you want them to. We've gotten rather good at working around NAT's limitations (not without cost), but with IPv6 those workarounds are unnecessary. For example, any peer-to-peer multiplayer game, video chat, or file transfer app where both sides are behind NAT depends on third-party servers for NAT traversal. (Note that the fact that this works at all without actually forwarding all data through the third-party servers shows that NAT is not a reliable system for preventing incoming UDP connections: it can be tricked into thinking a connection is already established.) With IPv6 you don't need the third-party servers as the peers can connect to each other directly.
> With IPv6 you don't need the third-party servers as the peers can connect to each other directly.
This will never happen. NAT gets replaced with a stateful gateway still doing conntrack (look at OpenWRT...) and p2p works exactly the same. UPNP, port forwarding, STUN are still relevant and work the same... Except IPv6 hexadecimal addresses are a usability disaster and dual stack will forever be a security disaster. Worst technology ever.
> NAT gets replaced with a stateful gateway still doing conntrack…
Yeah, blocking incoming connections by default is a bad habit and needs to stop. It's fine for untrusted devices or private VLANs which shouldn't be accepting direct incoming connections in the first place (like cheap IoT gadgets), and should probably be additionally filtered to prevent inter-device connections and access to arbitrary Internet sites, but a laptop, phone, or tablet is perfectly capable of deciding on its own whether to accept or reject an incoming connection, and moreover as a mobile device must assume the network could be hostile anyway.
> Except IPv6 hexadecimal addresses are a usability disaster…
How are IPv6 addresses "a usability disaster" when you never see them? Just use DNS like a sane person.
> …and dual stack will forever be a security disaster.
That's a new one to me. How is dual-stack (IPv4+IPv6) any worse security-wise than any other situation where you have multiple "upstream" Internet connections, e.g. for failover or load balancing?
Blocking incoming connections by default is what I like about the current scenario.
You don't trust "cheap IoT gadgets". I would like to be able to trust any/all my devices. But I don't.
I don't trust M$/Apple/Linux - AND any associated applications people might want to use at home(kodi, plex, screencast, NAS for example) - to be 100% perfect when it comes to "deciding on its own whether to accept or reject an incoming connection".
I see "block by default" as being a layer of security - one bit of defence in depth.
Happy to drop NAT (with it's IP<->port mapping complications) for a straight IPv6 firewall though.
If you really want to block all incoming connections by default on your own network you can. Personally I think if a reasonably capable (i.e. non-IoT) host opens up a port to accept incoming connections, and there isn't a specific rule set by the local admin to block that port or host, then incoming connections should be allowed. NAT certainly doesn't stop all incoming traffic given that UPnP is enabled by default on most routers, not to mention all the methods available for UDP NAT traversal. It just makes it more complicated.
If you've ever connected your phone or laptop to a public WiFi network (or for that matter, the cellular data network) then it's been exposed to an environment were there is no extra layer of protection from incoming connections beyond that implemented by the host itself. We generally expect that to work without major security issues. Non-mobile, "appliance"-type devices might need stronger filtering if they weren't designed to be connected directly to the Internet, but that assumption is becoming less common as more devices require authenticated connections rather than trusting the local network.
And that's the thing. With a firewall and IPv6 we can each configure for what we want without the NAT hassle/expectation.
I would aim for a default block with allowList and agree with you that a non-IoT host using a UPnP-like mechanism (does UPnP cover IPv6 firewall like scenario?) is probably ok.
Ideally I'd like some kind of notification system where I can click "allow" for the firewall. (Maybe the firewall notifies my phone?) I think UPnP as it currently stands is a bit too hands off but can understand not every user wants to deal with this.
And we agree regards mobiles being in a default hostile environment and expecting it to work. But I see that as a matter of fit-for-purpose. I don't trust every computer I have to that level.
The miniupnpd UPnP daemon (used e.g. by OpenWRT) includes code[0] to handle IPv6 "pinhole" requests—not port forwarding, which isn't required for IPv6, but rather just opening a port in the firewall to permit incoming connections to a certain host.
You get to use 16 bits of the address to chop up hierarchically for your site.
You get a /48 and each of your networks gets a /64, with hosts picking random 128 bit addresses in each.
The 16 bits in between the two subnets mean you have room to breathe for doing whatever you like. Maybe 64k VLANs, or maybe a hierarchy with semantic meaning. You don’t need an IPAM tool if the addresses have meaning.
My favourite: you can route a /56 to a Docker host and have 256 separate bridged networks, all globally routeable. You never need anything like that, but the open space is refreshing. Like I said: room to breathe.
Also in this line of thinking: hosts can be assigned an entire subnet, and applications can get individual /128s. This way, a single host can provide a bunch of independent services, which can be broken out into real machines as the system grows without renumbering.
I think the more important use case is tempaddrs. You don’t have to use the same address all the time, or even at the same time. You can just make up random addresses for each connection if you like, though in practice the rotation is much slower.
The biggest benefit is that there are more public IP addresses. The original solution for public IP addresses running out was NAT/PAT which allows a network to have it's own private IP addresses, but hide all internet traffic behind one public IP address. Think if you have 10 devices connected to your wifi/router, but you're only paying for standard internet connection. By hiding behind one address, it provided a huge layer of protection between individual devices and the internet, but also made some types of traffic a huge pain in the ass (see ICE/STUN/TURN).
With IPV6 we can give every device it's own public address, but one major concern is that it could lead to an explosion of insecure devices accessible directly from the internet. Right now if your printer or refrigerator is insecure, it doesn't really matter because it is inaccessible from the internet. The business answer for this is properly configured firewalls and proxy servers, but that's too much for the average home user.
The biggest downside is systems that assume all addresses are IPv4. These could be legacy hardware thats been sitting in a closet chugging along for 20 years, or brand new software where the developer didn't consider v6 as a possibility.
EDIT:
Some specific benefits:
Cheaply hosting stuff from my house.
Easy Direct secure communication without a middle-man.
The home side is basically the same as the business side: a good router has needed to be a good firewall regardless of NAT anyway, because the router can't just assume NAT (even if it is de facto everywhere). NATs as first-pass filter of a firewall was always an accidental feature at best.
Obviously we start to see which routers are "good" home routers shake out as IPv6 adoption picks up, but given current statistics homes are leading IPv6 adoption and it is businesses (with their complex surveillance proxies and IPv4 micro-management practices) that are greatly lagging in adoption curves. (Typical IPv6 graphs show a "bathtub" effect where IPv6 goes up in evenings and weekends as people switch from work devices and networks/VPNs to home devices and home networks.)
Homes are more ready for IPv6 than people want to give credit to. Claiming NATs to be one of the best features of Home IPv4 seems sometimes to just be FUD designed to be anti-IPv6 as much as it is a legitimate concern.
> Obviously we start to see which routers are "good" home routers shake out as IPv6 adoption picks up
Experts might, but most security isn't a visible property to most users, or at least they won't readily or reliably attribute router vulnerabilities to the router. This in turn means that security will get worse but the market probably won't correct itself, or at least the correction won't manifest as markedly better routers (the consumer router space sucks as it is because the customers aren't usually experts). I don't think this is a compelling reason to avoid an ipv6 transition, but I don't agree with the implication that ipv6 will have positive security benefits.
> With IPV6 we can give every device it's own public address, but one major concern is that it could lead to an explosion of insecure devices accessible directly from the internet.
This gets repeated, but we've already got lots of home IPv6 routers and none of them allow direct access by default. You need to jump through some hoops to enable external access. Nobody wants public access by default and anyone who does it will get noticed and called out very quickly.
> What are the practical implications for internet users and infrastructure maintainers?
If you want to talk to Indian web users, you'll probably want to upgrade your servers from Irix version 5.3 to at least 6.2 (but preferably 6.5.22, as it has some security fixes).
Now, you might be saying to yourself "Self, Silicon Graphics went bankrupt in 2006. Where the hell am I going to find install media for Irix 6.5 in the middle of 2022?" The answer to that, my friend, is eBay.
Or maybe you're thinking, "But labcomputer, I don't trust these modern computers with their instruction re-ordering mumbo-jumbo! I want them to interpret the binary as ~~god~~ the compiler intended! And besides, my VAX doubles as a space heater. What am I going to do?"
Well, good news! You're still in luck because you can upgrade your VAX to OpenVMS 5.7 and take advantage of all 128 bits of IPv6 goodness as you gently fall asleep to the roar of your VAXCluster's fans.
Windows users don't need to feel left out, either. Ole Billy-boy's got you covered. You can upgrade to Windows XP (on that powerful new Pentium II you just picked up) to access glorious <blink> tags on IPv6-hosted websites in 256 colors!
You no longer need services like tailscale or zerotier or VPN like wireguard just to connect to your home network. You also do not need static IP.
I host my own task manager, calendar, media center, document server, google drive alternative, google photos alternative on my home network and can reach it from anywhere. It is all possible with IPv6 without paying a whole lot to other services.
In future, I think IPv6 is going to play a crucial role in next generation of hardware devices and software applications that will bring people back from walled gardens to real Internet. We might finally have something where people host their own data like photos, stories at home securely and then they choose who should access or who should not. I know I am being way too optimistic but a man can dream.
> You no longer need services like tailscale or zerotier or VPN like wireguard just to connect to your home network. You also do not need static IP.
I disagree. Technologies like Tailscale, zerotier and Wireguard mostly exist to secure your private, distributed network. Tailscale has all kinds of measures to circumvent NATs, sure, but the main point is access control, encryption by default and presenting as little an attack surface as possible (by routing everything through Wireguard).
IPv6 doesn't give you that: IPv6 addresses can still easily be spoofed, and ports can still be scanned. And vulternabilities in applications listening on public ports will always exist. VPNs provide you with an additional layer of security.
How is an ISP supposed to know whether the "sender" on an IP packet is legitimate?
> That's not related to IPv6.
I didn't claim it was. It is, of course, already an issue in IPv4 networks.
OP was claiming that, once everyone uses IPv6, VPN solutions like Tailscale or WireGuard would no longer be needed. I disagreed because one of main features these solutions provide is access control, i.e. which device gets to connect to which device (and which application) in your private network. Not only is this much more cumbersome to achieve with IPv6 alone (as you need to set up appropriate firewall rules manually on each device), the security guarantees afforded by such firewall rules also won't be as strong as 1) IP spoofing cannot be prevented, 2) encryption is not the default, 3) the attack surface is much larger.
> If your ISP allows spoofing addresses
This has nothing to do with one's ISP. The ISP cannot possibly know whether the sender IP address on an IP packet is legitimate or not.
You have your home router firewall, you punch a hole in it (UPnP, PCP) on an as-needed basis, do your P2P thing. When you're done, the firewall hole is closed.
No magic/fancy protocols trying to figure out what your "real" address is.
Instead of having to chat or talk your some provider's central server, the software on your device can talk directly to the software on the other person's.
IPv6 simplifies networking by freeing us of the hacks surrounding IPv4. These hacks were made to stop us from running out of addresses.
Every device will have a unique IPv6 address. This solves a lot of pain regarding port forwarding and NAT — an issue I felt often when trying to play video games or host a Minecraft server when I was younger. It’ll be easier for regular people to access their local networks which could help make it a more mainstream option for people who want to home host services like file syncing or media servers.
You get a unique IP with NAT too, it's just not globally routable which is actually really nice since most people don't want the entire planet to see their internet network and folks running servers and P2P applications are generally capable enough at networking to configure their router to allow communication even with NAT in place.
If IPv6 wants to do away with NAT, what solution does IPv6 offer for preventing device enumeration and tracking?
Your ISP won't give you permission to mess with their CGNAT setup. Your best bet is to get a cheap server with an IPv4 address and do the forwarding yourself.
It is really amazing how people on the internet will call you stupid back when you were a kid when it is completelybout of your control.
And no, some services services are a serious pita to configure with NAT even if you know what you're doing. That's also assuming you're not NATed by your ISP and can bind external ports in the first place and that's not a given.
Yeah, I've seen a few other options too like proxies and NPTv6 but all of it just confirms that IPv6 isn't the NAT killer people make it out to be. In the end, there are uses for NAT that remain useful and desirable.
I know we'll all have to move to from IPv4 eventually, but I can't help hoping that by the time that comes we'll have moved on to IPv7 or at least IPv6SE or something that addresses all the issues that have hurt IPv6 adoption.
Something else that isn't often mentioned is that NAT requires keeping track of connection state on the router and anyone that writes code knows that state is the devil. That's state for every connection and for every device on the network. A perfectly implemented NAT router with unlimited memory is just as reliable as an IPv6 router that just forwards packets. In reality, the consumer grade devices have 16MB or so of memory and fall far short of this ideal.
IPv6 router firewalls still should be stateful (Ie allow connections initiated from my LAN to the Internet, but don’t allow connections initiated from the Internet to my LAN).
Sure, if you are speaking about core routers, they don’t care about state. But for homes and offices, traffic direction matters for security.
I'm completely out of the loop, but last time I checked "IPv6 will kill NAT forever" was basically a lie, and there is NAT-hell in IPv6 too. Is that so?
There are a lot of theoretical advantages to IPv6. Every single internet endpoint can have a unique address. You will no longer need any form of NAT. Any two random connected devices can talk to each other with a simple TCP/UDP request.
Practically all of this is still very unlikely, but at least it is a step in the right direction.
> What are the practical implications for internet users and infrastructure maintainers?
There are technical implications on routing and "what is on the internet" vs "connected to the internet" (the difference between having an address vs a NAT gateway for access).
But for India specifically, the difference is more political & specifically for the internal cloud infra land.
IPv4 was "sold & bought" during the era when US and Europe controlled who got how much.
If you are a up&coming cloud provider in India, you definitely have a scarcity of ipv4 addresses you can hand out to your customers - you can hand out ipv6 addresses no problem, but if people's devices are on ipv4, then this is behind the scenes and needs a fair amount of complexity.
You can do several tricks on the hosting side with DNS and SNI (so thousands of domain names can map to a group of 10-15 IP addresses and the loadbalancer can use the SNI to route the connections to the right internal ipv6).
So IPv6 adoption for cellphones for instance is not really important for the clients on phones, but it really matters if you want to build out a cloud infra stack hosted in India by a provider (like Reliance) who doesn't own enough ipv4 ranges to scale up things.
It means that instead of "1.2.3.4" you now have to deal with "f0fd::8a8a:99:::://4::88ff::deca:dead:beef::/16" or something like that, and remember how many colons go where and you now have to remember hex numbers instead of decimal.
What's the Google IPv4 DNS? 8.8.8.8. It's beautiful enough to be a decoration to frame and hang above a fireplace.
What's the Google IPv6 DNS? Heck if I can remember, it has some 4's, 6's, 8's, 0's, 2's, and some colons and double-colons liberally sprinkled like a salt shaker that had its cap fall off as you were shaking it.
I'm basically a walking DNS server of the company I work at, I know all the IPv4 addresses of pretty much every machine, and I couldn't do that with IPv6. I also know all the IPv4 addresses of every single IOT device in my home.
It's really no wonder that the world is very slow to transition to IPv6.
My isp don't offer ipv6 either but I've worked around the issue using tunnelbroker.com from hurricane electric (free) to get a /64, it works really great. Route48 is another such free service.
Hurricane Electric is great. These days my ISP offers IPv6 via 6rd, but since it's a dynamic prefix (tied to the dynamic IPv4 address) I still maintain the HE tunnel for a static IPv6 prefix while routing most traffic over 6rd. The routing tables get a bit complicated since I can't send packets with the HE source address through the ISP's 6rd tunnel or vice-versa, so I have to route based the source and not just the destination, but overall it works fairly well.
I'm still hoping my ISP eventually offers native IPv6 with a static prefix but it doesn't seem to be a priority for them. On the other hand they haven't gone to CGNAT yet for IPv4—which would break the HE tunnel—so it's not as bad as it could be.
Depending on what you're actually running at your IP, consider if dynv6.com will work for your dynamic IP. I switched and I've never noticed a difference really. Only one machine on the /64 (or /60 or whatever you have) has to actually ping dynv6 service; it automatically updates the prefix for all other AAAA records. Moreover I've got it set up with a dead simple shell script using curl, no service-specific binaries needed.
Indeed, at this point my only problem is my ISP router will not route the WAN ipv4 address to the appropriate host when the source is on the LAN, meaning I have to use ipv6 to access my public facing server while at home.
I have a custom system in place for IPv4 to update AWS Route53 based on this script[0] which I could easily extend to update my AAAA records at the same time, but I prefer a stable IP address. Dynamic DNS (v4 or v6) has a tendency to break down for a time whenever the IP address changes until the old records have expired from resolvers' caches.
I used to run a HE tunnel, but certain IPv6-enabled sites like Netflix would complain loudly. I guess from Netflix's perspective, it appeared I was using a VPN to get around region locks, maybe. But since I've recently canceled Netflix, maybe it's time to revisit that HE tunnel...
Used to use the same, killed it when my wife's Google things worked better without IPv6. Everything Google worked better on her phone the second I turned it off.
It's good will, technical education and marketing of complementary services. HE sells Internet connectivity and datacenter colocation, B2B. Increasing the number of technically sophisticated people who like and appreciate HE produces more opportunities for sales.
Also, it doesn't cost them much in exchange for lots of good will.
I believe hurricane electric's IPv6 tunnel program was a strong factor in them becoming the de facto connectivity hub for IPv6, helping them establish peering relationships with other large carriers for v6 at least and sometimes they get v4 peering as well, but at least they get a relationship. You're not really on the v6 internet unless you have connectivity with he.net, so most carriers will connect with them for that.
That connectivity makes it easier to sell their transit services, etc. If you're a BGP speaking network and connect with them for v6 transit because it's good, you may as well try their v4 transit too, because you already established a relationship, right?
They're focusing on the enterprise segment (in general, the company running this is a known tier-1 corporation), which will pay $$$ for a reliable and uncongested connections.
> The Internet Stream Protocol (ST) is a family of experimental protocols first defined in Internet Experiment Note IEN-119 in 1979, and later substantially revised in RFC 1190 (ST-II) and RFC 1819 (ST2+). The protocol uses the version number 5 in the version field of the Internet Protocol header, but was never known as IPv5. The successor to IPv4 was thus named IPv6 to eliminate any possible confusion about the actual protocol in use.
IPv5 was an experiment (by Apple, NeXT, and Sun) never intended for wide deployment. Known as "Internet Stream Protocol" or "ST" it was focused on a video/voice streaming network.
There's been some push from the other side: cell phones move too much in physical space to make IPv4 routing efficient (especially with today's scarcity) so today most cellular networks are IPv6 "native" and rely on IPv4-over-IPv6 router proxies for IPv4-only traffic.
Smartphones have been among the biggest leading adopters of IPv6 out of necessity to the network topology.
Wired very few and unlikely to change quickly, mobile a good number and often changing without people knowing it happened.
Mobile has a lot of NAT464 where the middle layer is the carrier and all v4 gets translated over v6 which is all that's assigned to the user and then out a gateway service. In wired you'd need to insure everyone had a device which understand to do that (CLAT in 464XLAT jargon) so carriers have been doing NAT444 where there are 2 layers of v4 NAT (home users then carriers) before the carrier's core does the final translation to a real v4. NAT444 is clunky and doesn't even help make sure users get to v6 but it's attractive to carriers because it works without having to have anything change from the customers perspective (beyond their external NAT IP being a 100.64.0.0/10 address instead of a public IP). Because of this the tail end of those who truly do not have any v4 on wired is going to be quite high.
They got IPs but they missed out on the "Hi, I'd like 16.7 million IPs please" era and mostly on the "Hi, I'd like yet another 65k please" era as well.
With NAT444 carriers can use a 1 public IP to serve all of the connections for somewhere between 100-1000 customers depending on the usage pattern of those customers. Right now an IPv4 address sells for about $40 so even on the low scale if they had 0 IP addresses that's a one time cost of less than 50 cents per customer. Without NAT444 it would have been 100-1000 times more expensive for newer ISPs to use IPv4 and you would have seen a lot more by now.
I used to be hyped about IPv6 but now that it's actually (slowly) getting adopted I'm going to miss the clunky old ways. No more sitting behind three badly configured NATs. No more scanning the entire internet in 5 minutes T__T
Even then, hole punching should get significantly easier, as you know the IPs and ports of both parties. Multi-layer NAT with port guessing is usually a nightmare when establishing a direct connection.
Internet standards are not created by a single organization or person (well, not anymore). Everybody can help design the standards.
I'm greatly simplifying, but roughly it goes like this:
1. Someone proposes a change.
2. If there is enough interest in the proposed change, an RFC (Request for Comments) is created, in draft stage.
3. Stakeholders can comment, if agreed upon the changes are placed in the RFC. Rinse and repeat.
4. Once enough stakeholders are happy, the RFC is accepted and it becomes an internet standard.
An RFC in step 3 may already be mature enough to be used in production, though just not yet finalized (step 4).
Before 2017, IPv6 was already being deployed because the RFC was already quite mature. However, with IP being such an important protocol for the internet, it took a long time before the RFC was finalized, though not much was being changed. In 2017, the RFC was finalized and thus it was set in stone (until a new RFC is created) that that is how the protocol must work.
RFC 2460 dates back to 1998 [0].
There was an updated standard published as RFC 8200 [1] in 2017, but it is not uncommon that standards get updated by a new revision - the current standard is just as 'finalized' as the 1998 version was.
the benefits to management, automation and ubiquitous connectivity are well covered.
with that, we get a different security paradigm. let's say i have basic needs - some IPv6 IoT devices on my home network, with a req for SSH and RDP into that network network to various servers. what are the secure-by-design type of recommendations for this new paradigm in which my devices are now default-reachable from the outside world?
> what are the secure-by-design type of recommendations for this new paradigm in which my devices are now default-reachable from the outside world?
And specifically how does that paradigm not only inform the iot device design, but how does a typical consumer insure against insecure iot devices? Do they now need to know how to find the iot manufacturer's address space and whitelist it in their router's firewall rules (and all that for the marginal gain of server-initiated connections)?
I should have provided more detail. I am thinking about basic home users - who often rely on their default modem/router setup from their provider - let's say inbound 443 is open, at the very least (statically or can be opened dynamically) so that an attacker can scan my network and find my IPv6 devices. What would I recommend that person do instead (that is doable by the average person)?
For static inbound 443 should be dropped by the basic home user's default carrier modem setup, only outbound initiated should be allowed. I'm sure there are some bad home implementations that don't do this by default, as there are on IPv4, but as you say for most users it comes down to if the provider's default config is bad or not. For more advanced users they can check and correct the default config if it is bad.
For dynamic it's not really any different than dynamically opening ports on IPv4, it's convenient for things like peer to peer communications and inconvenient for security but a lot more the former than the latter so most actually want it. For the static case then you get what you ask for, if it's static then you specifically put effort into making it reachable so if you don't want it to statically be reachable to everything then just don't statically make it reachable to everything.
Scanning a /64 or even a /56 (which you ought to get from your provider) is infeasible.
Nevertheless, you have the exact same problem already today with ipv4. Just with a NAT inbetween, which is usually replaced with a firewall for ipv6. Also, when a specific device opens up a port via upnp it better does this on purpose.
> who often rely on their default modem/router setup from their provider - let's say inbound 443 is open,
That's not a great assumption to start with.
1. Routers normally come with no inbound possible.
2. Some ISP will require you to opt into accepting 443 at all.
3. It will be open on the router for one specific device - there's no realistic scenario where your home router is configured to allow 443 to any internal address. (Unless you do that explicitly)
Scanning a /64, /56, or /48 isn't really feasible though. A /64 which IIRC is the smallest IPV6 block handed out to home users is 18,446,744,073,709,551,616 address.
So, a IPv6 2^64 subnet is the same as (2^32)x(2^32), which means (4.3B)x(IPv4 Internet). I.e., a single IPv6 subnet can hold the equivalent of four billion (IPv4) Internets.
--
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
So (4x10^11)x(2x10^12)=8x10^23 stars in the universe.
* Size of IPv6 address space: 3.4x10^38
Find the ratio between addresses and stars:
* 3.4x10^38 / 8x10^23
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe.
From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study"
On the surface of the Earth (land+water), there are 8.4 IPv4 addresses per km^2. Not counting the oceans, that would be 28 IPv4 addresses per km^2 land.
IPv6 gives 10^17 addresses per mm^2 (yes, square millimeter).
In terms of volume, 10^8 IPv6 addresses per mm^3 throughout the Earth.
Can you explain why? I'm under the impression they would most certainly would be default reachable. I have limited experience with home routers so maybe someone else can chime in with more insight, but I'm under the impression most relay on NAT and not an actual firewall to limit what can be reached.
Home routers are stateful devices. In IPv4 this means an internal device opens an internet bound session and the home router tracks that session, comes up with a NAT mapping, and allows the session bidirectionally until it is closed or times out. In IPv6 this means an internal devices opens an internet bound session and the home router tracks that session and allows the session bidirectionally until it is closed or times out. The only difference between the two is whether translation occurs, not whether inbound traffic is allowed.
In regards to inbound the differences (again, for home) are simply whether there is a static translation and implied allow to inbound initiate or whether there is just a static inbound allow.
In IPv4 just relying on NAT and not statefulness is incorrect, any packet that hits your router's external address with an internal destination will just route through. This failure scenario is a bit worse in IPv6 though as it's a lot harder to get a private IP destination very far over the IPv4 internet whereas in IPv6 these are all public. On the other hand you pretty much have to know the IPv6 address you're trying to reach beforehand anyways which means you're either physically attacking (i.e. bigger problems) or the client reached out to you already which limits the scope quite a bit. Either way it's still not secure to just rely on NAT.
I believe we should thank Jio[1] for this one. I get IPv6 on my Jio connection, but neither with ActFibernet[2] nor Airtel[3] (another major ISP in India).
Yep, Jio launched their network in 2016ish, and didn't get many IPv4 addresses (probably didn't want to spend the significant amount of money to aquire addresses, maybe couldn't find large enough blocks for sale), as a result they require their branded devices to work with IPv6 and pressure their partners to do IPv6 as well.
I have no stats, but I wouldn't be surprised if it was the largest single action driving v6 adoption ever.
No idea about Mobile (I'm on Airtel). I have all the three connections bonded/balanced for my home connection using a very simple router. I stumbled on Jio being IPv6, so decided to check the others and they weren't.
> I have all the three connections bonded/balanced for my home connection using a very simple router.
Can you give some pointers (to someone who has practically no networking knowledge) on how to set something like this up? I have an ACT connection and am considering an additional Jio one; I'd assumed that the mess of having two routers and two Wifi networks was inevitable, didn't know this was an option.
Hmmm! I had to searched up and read up on "APN settings". I had absolutely no idea prior to this. I looked up in my iOS Preferences, could don't find them and honestly I don't want to touch those.
I am not sure what it is called on iOS but on Android it's called "Access point names". In that there are bunch of access points basically for data, mms. For Airtel you have to go into settings of "airtelgprs.com" APN and change bearer from IPv4 to IPv6 or IPv4/IPv6.
China is an odd case, all ISPs (really there is no choice it's either China Telecom, or Unicom) use IPV6 internally, but often don't give you V6 address depending on the region.
The following operating systems use IPv6 privacy extensions by default:
All versions of Windows after Windows XP
All versions of Mac OS X from 10.7 onward
All versions of iOS since iOS 4.3
All versions of Android since 4.0 (ICS)
Some versions of Linux (and for others it can be easily configured)
Sure you could track such IPs by looking at routing paths/the subnet prefix but that's not different than IPv4. If you posit that a dynamic IPv4 is completely random you might be surprised, it's just drawn from a small pool that at some point has to be routed for packets to reach it, and even then it's not updated that frequently (usually on router reboot). Comparatively, privacy IPv6 addresses get rotated very frequently (can't recall but could very well be 15min)
Use short-lived IPv6 addresses then. IPv6 doesn't force everyone into one or the other. You can operate both short lived, anonymized and permanent IPv6 side-by-side in the same network.
Theoretically, in practice ISPs have been largely been handing out PDs and calling it a day (for consumers at least). This means you get many networks worth of v6 but they won't statically assign those many networks of v6 to you. That said they don't actively try to make them change and they aren't under pressure to use every last IP like IPv4 and for many carriers it's unlikely you'll ever have your v6 PD assignments change after a boot (ATT fiber is a good example). Of course if you do you're usually just shit out of luck as extremely few carriers provide the option to customers on v6 for whatever reasoning.
I was told by someone I met, who is working at my very cool ISP (Fiberby), that I should just as customer service for IPv6.
One day later I had a static /56 prefix routed to me on a /64. I had just assumed that it was not an option, because hardly any ISPs have IPv6 here in Denmark.
This doesn't make any sense. Unless you're paying for a static v4 address you're not getting a static IP on your router either. You generally have to be on a business plan with most ISPs in the US for this type of feature. IPv6 and v4 are no different in that regard.
I have cable at home. I've had the same "dynamic" IPv4 address for 3 years, which is how long I've lived here. It has persisted multiple power-losses, some extended. On the other hand I get a new IPv6 prefix at least once a month, including every power-cycle of the modem and/or router.
I don't know if this is related but I've seen isps that put you behind a cgnat over ipv4 if you have ipv6 connectivity but they give you an ipv4 ip address just for you if you disable ipv6.
What exactly can you do with a static IPv6 address without a static IPv4 address? Most networks don't support v6 yet, so if you wanna host anything you need v4.
The only time I ever have working IPv6 is when I'm using the cell network. No place I've worked, and no place I've lived, has had working IPv6. I'm in Oslo, Norway, so not exactly a technological backwater either.
Most consumer devices today use some variant of the "Happy Eyeballs" protocol that prioritizes v6 to one extent or another, but "races" them (if IPv4 is faster to ping for a given DNS host it switches to IPv4 for that DNS host; otherwise it prefers IPv6). Things like NAT and CGNAT naturally slow down IPv4 so many consumer networks very heavily prioritize v6 in the "Happy Eyeballs" races.
Well, I would say it depends on the use case? Maybe for accessing a couple services I would be okay w dynamic dns, but if I’m trying to host something where I’d prefer less points of failure and prioritize stability and uptime I probably would rather have a static address. (Please correct me if I’m wrong)
Static IPv6 isn't that much harder to memorize. Admittedly I'm often numerically dyslexic, but I even sometimes have a harder time with memorizing IPv4 addresses than IPv6. Particularly with the big trick that you can elide all the zeroes you want with double colon (::). At that point you just have to remember your subnet prefix and then all of your statically addressed devices you can think of as just {subnet}::N. Your web server can be thought of only as "::1" to you and your database server as "::2" and your combination printer and coffee maker can be "::3" to you, and you just have to remember to include your prefix up front (or copy and paste that part). Even a paltry /64 is just 16 hex numbers to memorize in nice 4 groups of 4 in the worst case that your ISP can't give you a bunch of trailing zeroes in your /64 request. (A /56 which is what most ISPs should give you per convention if you request a static subnet is 14 hex numbers in 3 and a half groups of 4.)
The point of having a static IPv6 address would be that you can use regular DNS, not dynamic DNS. With dynamic DNS you have to use a short TTL, increasing the load on the DNS server, and even then it will break occasionally due to caching when the IP address changes.
Ease of memorization is a non-issue since you should be using DNS anyway, whether for IPv4 or IPv6.
The IPv6 prefix I get from my ISP is almost entirely "full", so the :: is only good for the latter 64 bits. I can imagine someone paying to get more zero bits in the prefix, or a more memorable prefix.
For me I've just resigned to the fact that each of my IPv6 servers will require DynDNS.
