I'm running my home network IPv6-only since some time and it works fine thanks to DNS64/NAT64. I think once more ISPs start offering DNS64/NAT64 internally the transition will be quite unnoticeable for endusers.
Software that still does not work because it uses hardcoded ipv4 addresses or sockets: Steam, WoW (probably many other Games too), node/npm (before version 17), but for the most part it works! The offenders can also mostly be fixed using clatd.
WoW used to work. A bunch of people at my (IPv6 friendly) ISP used to play it and made a big deal about the fact that WoW was actually IPv6-enabled. At some point they broke it
[Edited to clarify: Blizzard broke it, not my ISP]
" It allows an IPv6-only host to have IPv4 connectivity that is translated to IPv6 before being routed to an upstream PLAT (which is typically a Stateful NAT64 operated by the ISP) and there translated back to IPv4 before being routed to the IPv4 internet. "
How did you get your ISP to give you a static IP block or prefix? I can get an IPv4 block, but despite the yelling of the IPv6 fanatics regarding how many IPv6 addresses are available, I can't get anyone to allocate me even 20 or so (much less a prefix!).
Is there something in the spec that makes this hard to do. It's been 20 years.
My old ISP have me a /64, using 6rd. Because of this, I changed ISP's (one of the main reasons I did so was because of the poor IPv6 support) and the new one gave me a /48. This was several years ago though, and hopefully even my old ISP can do proper IPv6 by now.
So apparently it depends very much on the ISP. Some are doing a better job than others.
I am asking, under IPv4 I can trivially get a static block of IPs.
I can then trivially
* put some devices on a VLAN (ie, a VOIP phone) and it will have a public IP, globally routable.
This works well in my experience, latency is super annoying on VoIP and for some reason behind a NAT sometimes it seems to route media through a third party server!
For a small business you can put a PBX on the VLAN and folks can remote register to it trivially (ie, phone.companyZ.com) - with COVID this is great.
You can VPN terminate more easily with a static ip block.
At home I can do a game server on the static IP block or I can host some of the simultaneous music composition stuff (trivially).
My question is simple - how do I get a static IPv6 block so I can do all this if I want to on IPv6.
I get IPv4 is outdated, but how do I do some of this stuff in the fancy IPv6?
You are telling me IPv6 means I don't need any public static IPs and can use some private IPv6 space (10.x was already plenty for that for me in ipv4) with a dynamic public IPv6.
Fine, how does this work. Seriously, what VPN endpoint am I configuring? How does my VOIP / SIP play with this? Do I need to go back to poking weird holes in a NAT? My OWN experience was this all doesn't play well together. Firewalls seem not to play well with dynamic prefixes - and that's just the start. Devices pick up the wrong IP's internally (SIP etc).
In short - 20 years into this, when I try to do something simple -> stick my VoIP phone on a static public IP and VLAN -> its a total pain.
At a small biz, if I try and put a PBX on a static public IPv6 - it's a total pain (and BTW - the SIP IPv6 support in most hardware and softphones is terrible).
This should be the winning use case. Phone calls / person to person audio would benefit TREMENDOUSLY from direct peering connections without any NAT!
But despite an insane number if IPv6 addresses at least in the US they won't assign you a block of even 20.
It's a great question for the thread but probably in response to the wrong comment chain. But since we're here: it'll depend on your provider, just like v4. Some won't offer it at all, some will charge, some will force you to buy the "business" connection instead, some will use a static WAN and route the rest to you, some will use a dynamic WAN and route the rest to you, some will require their modem be used (and some will even 802.1x auth it), some will let you directly put it to your own gear.
The story isn't any different, there is nothing about IPv6 that changes this dynamic other than you have the additional option to use PD. What may be different is what your ISP requires you to do/purchase - by the sounds of it likely trying to push you to a business account which is a revenue tactic not a technology limitation.
As far as NAT with a dynamic IP to private v4 it works the same as NAT with an IPv4 connection with RFC 1918 space internally.
As for your performance issues with NAT you shouldn't see any latency with NAT on a network device, if you're using software routing on a Linux box or something try a standard hardware network device for the edge NAT instead as the data path for hardware devices is the exact same for NAT in those as it is for normal routing, in fact normal routing is normally just implemented a special case of NAT where the inside and outside addresses of the NAT are set to the same value. If you're currently using such a device for your edge NAT and experiencing problems with it either the device is broken or something is misconfigured as like I said everything is always "NATed" through such a device so it doesn't make any sense it'd have higher latency with certain internal IP values.
But seriously for home use without NAT look at PD, for business use with static routing and statically configured devices behind that routing look at what your ISP wants to sell you and see if you can call them on their crap but to be honest if you're running VOIP the business service is probably worth it anyways as you can get them to honor voice QOS through the oversubscribed local node into their backbone. If you go this route the IP space itself is the same as v4, you can either get it from your ISP or you can get it assigned to your LLC or whatever via your local RIR - literally anyone can get a /48 block assigned to them this way, maintenance fees for the allocation are the same as v4 but the RIRs actually have the space itself for free unlike v4 where you have to buy addresses and pay the maintenance fee.
You can tunnel if you want but I really wouldn't recommend it for VOIP. The same options you have for IPv4 VPNs are available for IPv6 and the setup is no different beyond the address type. There is also the option of teredo or 6rd but again I wouldn't really bother with them at this point in the game, they were intended for deploying v6 prior to its availability in ISPs not for this use case.
But the general idea is there is nothing about IPv6 that changes the way static addresses, static routing, or static allocation works beyond the size of the address field. That doesn't mean your ISP is choosing to give them to you at a reasonable price but it's not because of IPv6.
The latency comes because it seems services fall back to a server reroute for a media stream for example if you have a double nat situation they can't get through to route directly. It's not the NAT, its the approaches used to work around the NAT. This hits particularly hard with IPv6 (ie, the fallback will be a server that does next leg IPv4 if needed).
We hear that IPv6 has more IPs than people. Great. It should be easier, not harder, to get a block of these IPs.
ISPs don't want to hand out static blocks.
Static RIR allocations also poor and in some ways harder than it was to get IPv4 allocations early on (Have 13 end sites (offices, data centers, etc.) within one year or 2000 devices etc) or go to IPv6 multi-homing.
The limiting factor in some of this is not IP address quantity but routing complexity - I understand why they may want to limit things from that side, but it limits the utility of the space.
And all of it is harder to configure and operate for most folks. Sure, Google was maybe all in on IPv6 for google cloud from the start, but they have crazy money - and even for them I'm sure it was a pain and a big lift to offer that as a service to their GCP customers 15 years ago.
For the average person -> it's still not that good.
Note: I'm kidding about google and their rockstars delivering IPv6 early on. It was as painful for them with all their experts as everyone else - which tells you something.
One clear pain point, ISPs not giving out static IP's (v6). So what's point of huge space?
The routing path is the same regardless if you do NAT on your internet edge or not and there is no double mat in the case of IPv6, perhaps v4 if your carrier was doing cgnat due to address exhaustion.
The benefit and aim of the large space is that all devices can get unique public IPs not that all devices can get static public IPs. This prevents the need for cgnat on the carrier side which creates all sorts of problems and even prevents the need for complex NAT punching for user p2p such as games or real time communications. It also prevents the need for paying millions of dollars just to have IPs to serve one town due to scarcity from a small numeric field.
I'm not sure what is more difficult about getting a /48 from your RIR today than was getting a /16 in the early 90s, in each case you just register and say "I've got a business using IP" and are approved. I've never been denied, even for my personal LLC. I even had 0 pushback getting a /32 assigned for a large org I worked for 2 years ago - that's an entire IPv4 worth of /64 prefixes assigned without question or selling a kidney like on IPv4. I've also never had trouble registering dozens of businesses for static IPv6 blocks from their carriers for when they didn't want to manage the internet handoff.
For the average person they don't know what a vlan is or a static address or what IPv6 is for that matter, and they don't need to, which is what is so great about IPv6. For those that do know what VLANs are PD is great and comes out of the box on every ISP for $0 instead of paying them for more public addresses like in v4. For businesses static handoffs really are 0 difference to arrange from the old.
Google was amazing with the V6 efforts early on but GCP was God awful. In fact to this day it still requires dual stacking GCP VMs on the internal side otherwise everything breaks and you can't access GCP APIs via v6. Both Azure and AWS have been light years and decades ahead of GCP on the V6 front.
As for AT&T being a general money sucking PITA to deal with yes, they are generally recognized as the worst large ISP to deal with and will make you want to pull your hair out. They won't do it with U-verse they'll push you to ATT business fiber, charge an arm and a leg, and take 6 months to do it. Again though your beef is with ATT's business offerings not anything to do with IPv6, there is nothing stopping them from doing the same thing they do on consumer IPv4 connections they just choose not to.
I want to do this, but Comcast's prefix isn't stable, I get a different one every time my lease renews, which means it is impossible to have a static IP for all my network devices, since neither pfSense nor OPNsense support NPTv6 to a dynamic prefix.
It would be really bad for business if Comcast started assigning static addresses for all their customers. The doxxing villains would surely take advantage of a world in which same address == same person.
If some dodgy site gets a visitor from a Comcast netblock they would know that, should they ever de-anonymise the address, the John at the other end has zero plausible deniability to fall back on.
That being said, there’s no excuse for Comcast to at least give you the option of a static /48. I see that they themselves have a /20. That alone is enough for a /48 for each of 268 million customers (8x their current userbase) who would each be able to route 65k broadcast domains (/64 subjects.)
I've been using IPv6 on Comcast for years now, and my prefix has been stable during that entire time. Double check that your DHCP client is not sending a new UUID for each lease request. The UUID should be stable so that the DHCP server knows to give you the same prefix each time.
I've got a /60 with multiple VLAN's running without issues.
That is pretty dreadful. You may be able to use RFC 4193 (ULA) addresses to get some stability but then what you get is a sort of buggered up IPv4 experience with really long addresses.
It would make a worthy challenge, the struggle would be legendary etc 8)
What network equipment do you use inside your home? Ubiquity has driven me nuts with the poor IPv6 support. I expect the US consumer home network gear is in just as bad of shape. Trying to upgrade my Comcast modem to IPv6 gave me a device that hard crashed every 6 days to 1 month, that had to be replaced 6 times until they finally would give me the next model up to fix the problem properly.
Edit: This is for a business modem owned by Comcast, needed because of a static IP config.
> Trying to upgrade my Comcast modem to IPv6 gave me a device that hard crashed every 6 days to 1 month,
Could be worse. The CenturyLink CPE I had would crash and reboot if a fragmented ipv6 packet touched it. The replacement didn't do that, but had some trigger that ended up with massive extra latency.
Residential AT&T Fiber with their own equipment seems to work pretty flawlessly for me - stable v4 IP and v6 prefix even across hours-long disconnects.
Wow; that is a lot worse than I thought. I really wish IPv6 was better understood than it is now, it really is quite a good standard, but it is also quite a bit different than IPv4 which I think scares people away (it can also be hard to remember longer IPv6 addresses).
I think we need to start judging how good a standard is by how easy it is to implement for its intended purpose.
The purpose of IPv6 was to superscede IPv4. 25 years later, only 1/4 of the top sites from this link are IPv6 enabled. That's... well, at some point you have to stop blaming lazy sysadmins or stubborn vendors and start considering that it's genuinely just a bad and hard to understand standard.
In 2050 we'll still be on IPv4. That's how bad I think IPv6 is. Technically impressive? Sure. Viable as an understandable network paradigm and designed for widespread real-life use? Looking like no.
It's not that IPv6 is bad. There are no other, more successful alternative proposals to grow the address space while maintaining end-to-end connectivity. It's just a difficult coordination problem. From a purely technical point of view IPv6 works, today. It's not hard to set up IPv6 networks and connect them together. But there is a lot of IPv4-only equipment, legacy applications, etc. in active use which would have problems with any new protocol.
Not wrong, but I have a feeling that a protocol which changed things less would have caught on a lot faster. IPv6 changes a lot more than just expanding the address space.
32bit IPv4 gives us 4.2 billion IP addresses (although there are fewer usable addresses due to reservations etc.). If we would have just tacked on another byte we'd have 1 trillion (theoretical) IP addresses. Two extra bytes and we'd have some number I don't even know the name of (~2.7e14).
Changing from 213.113.223.023 to 142.213.113.223.023 is a lot less invasive, both for users and implementations (although increasing the address space isn't necessarily easy, it doesn't require an entire new stack).
Now, these other IPv6 changes aren't necessarily bad and also address real problems as well, but it seems IPv6 changes too much in one step for its own good. In this regard, it's not that dissimilar to Python 3 (except even worse!)
Also: one think that struck me about that list is that sites who do implement IPv6 are all Western, and that none of the Asian (mostly Chinese) sites implement IPv6. You'd expect it to be the other way round because Asian/Chinese would benefit a lot more from IPv6 since they have fewer allocated addresses, and their infrastructure also tends to be newer so legacy hardware is less of a concern. I don't know what this means or why this is the case though.
> I have a feeling that a protocol which changed things less would have caught on a lot faster.
Perhaps. IPv6 had more goals than just increasing the address space. Some of these goals were interdependent; for example, just increasing the address space without doing something about routing table complexity would have been a recipe for disaster, which is part of the reason why IPv6 uses much longer addresses with a fixed number of bits reserved for the local subnet, and why it also strongly discourages the non-hierarchical routing which has become commonplace in IPv4.
> Changing from 213.113.223.023 to 142.213.113.223.023 is a lot less invasive, both for users and implementations….
I would say 2602:7b:294e:d207::1 isn't much worse to remember or type than a dotted-quintet (based on, but not equal to, one of my real IPv6 addresses). Implementations don't have any issue with 128-bit addresses, and probably prefer that over an odd size like 40 bits due to alignment. Users usually don't have any reason to care about IP addresses; that's what DNS and mDNS are for. Or copy & paste if you absolutely must work with raw addresses.
> (although increasing the address space isn't necessarily easy, it doesn't require an entire new stack)
In practice, it does. You could certainly model it more closely on the original protocol, but the systems wouldn't be interoperable. System calls, library APIs, applications, and GUIs would all need to change. You'd have to rebuild all the routing hardware and redesign any protocols that embed IP addresses. Basically everything that needed to be updated to work with IPv6 would still need to be updated to work with "IPv4+1B". The changes might be smaller but it's the fact that you need to change these things at all that makes the process so difficult.
There are some other changes in IPv6 that are more debatable, like replacing DHCP with SLAAC when we could have probably just used a straightforward IPv6 adaptation of DHCPv4, at least in the beginning. SLAAC strikes me as the sort of thing that could have been deployed separately once IPv6 adoption was well underway. But I wouldn't say that these minor differences represent significant obstacles to IPv6 adoption.
It is interesting that most of Asia is trailing somewhat behind, whereas India is at the top of Akamai's charts for IPv6 adoption[0].
Same with Security Keys, there are a bunch of technologies like this, where you can literally write documentation explaining "This is what we did at our multi-billion dollar business to successfully solve the problem" and people will walk past, fingers stuffed in their ears, hoping that some day the problem will be solved somehow, but, like, magically without them having to change or learn. Just keep doing what they're doing and then, somehow magically it'll be fine. See also: Climate change.
For most people, IPv4 is a solution to a problem that didn’t require change or learning. It’s just what is used behind the scenes to make the web and chat and email happen. And happen it all does, without trouble, so why lots of money to replace it?
What is the sales pitch you would bring to the CEO of a Fortune 500?
> What is the sales pitch you would bring to the CEO of a Fortune 500?
When you buy or merge companies, and they both have RFC 1918 addresses, you'll probably have a conflict between the two entities. You'll probably have to implement NAT with-in your own network and hope the two sides don't have to talk to each other that much. (Or you completely re-IP the acquisition.)
With IPv6, either the companies will be using their own PI IPv6 space and/or they will be using unique ULA prefixes, so the chance of conflicts will be very small.
This at least was one of the business cases for Wells Fargo, "the fourth largest bank in the United States by total assets and is one of the largest as ranked by bank deposits and market capitalization":
Over time, ISPs are pushing more users to IPv6 + CGNATv4 because they don't have enough IPv4 addresses.
If an internet service needs to distinguish users by IP address, say for spam fighting reasons, then IPv6 will provide finer granularity because the addresses are not shared by multiple users. Depending on how the ISP implements CGNAT, IPv6 may also improve performance and geolocation accuracy.
(They'd also be doing those ISPs a favor, because offloading traffic to IPv6 lowers the operating costs of CGNAT.)
There isn't one until IPv6-only ISPs (or plans) pop up offering cheaper connectivity because you don't need an expensive v4 address. NAT sucks and everyone's job would be easier if they didn't have to deal with it, but the CEO likely doesn't care about that and probably just sees the "add IPv6 support" scope and cost estimate and NOPEs out.
I love IPv6 btw. I just don't think you'll see anything meaningful happen until FAANG drop IPv4 support. Imagine that. People would convert pretty quick if Google couldn't crawl your site or you couldn't buy an iPhone without IPv6...
That's not really the price of an IPv4 address: you don't have control over it, it's just not changing because they made a DHCP reservation or something. Owning an address means you can announce it to peers via BGP, set up PTR records, etc.
IPv4 addresses are expensive right now. Registries run out of new allocations years ago, so if you ask them you'll be put in a waiting list[1] hoping one for a block to be recovered. To get one right know you have to go on the market and negotiate a transfer: blocks are selling at ~50$/address right now. The price more than doubled in the last year or so: people are even speculating on it [2].
Your ISP probably hasn't tried to acquire IPv4 addresses recently. https://ipv4.global/reports/ shows prices around $40/address, so it would take 2-3 years to break even at $1.30/month.
(Although, people rent apartments with break-even periods well beyond 10 years, so maybe 2-3 is still fine.)
> it can also be hard to remember longer IPv6 addresses
mDNS helps since you can use hostname.local without having to set up a DNS server. I was going to make a joke blog post about using ipv4 addresses as hostnames so you can "keep using ipv4" while actually using ipv6, but I found you can't have "." in hostnames, so maybe instead use "-".
If you run your own DNS resolver for your local network, you can use a Discovery Proxy (RFC 8766) to allow unicast DNS resolution of multicast DNS records. I'm using mdns-discovery-proxy[0] (slightly modified to support a newer version of the zeroconf Python library) with bind9 so that xyz.local is mirrored in unicast DNS as xyz.home.arpa. The script (proxy.py in Git; I renamed it) is run with this systemd service (/etc/systemd/system/mdns-discovery-proxy.service):
Does mDNS work across VPN tunnels? The main reason I delay IPv6 is because I access hosts across the VPN by their IPs, and I don't want to publish their DNS records.
I guess that's equivalent to setting up a hosts file... Unless the DNS resolver can be configured to treat a selected server on the VPN side as authoritative for .mynetwork.
Also, ULA. You can have both “real” (internet-routable) IPv6 addresses for all devices as well as (fixed) ULA addresses for local communication and ease of use. fd00:dead:beef::/64
IPv6 will never be universally adopted because they chose to make baroque auto configuration features, and the propeller heads, who are forcing this on everyone, gaslight us by telling us we shouldn't rely on having a private address space as a way of having control over your own network.
My current setup is comcast and att to the net. Internally I've got a DHCP server, with reservations for key equipment (ie do a certificate issuance for these as well) - think proxmox / esxi web interfaces). A few items x.x.x.20 and less static IP (ie, gateway etc).
This system works great. Comcast down? No worries, failover to ATT (and visa versa). Everything works through the NAT, failover is seamless.
I've spent a bit of time naively trying to get ipv6 to work as smoothly. The way IPv6 addresses are handed out, auto-change, are typed etc. It's just no where near as smooth.
We needed IPv5 - I basic extension to address range - that's it. Just add another 0-255 at the beginning or end of things and be done.
My other complaint. Desite supposedly having more ipv6 addresses, my ISP WILL NOT give me a static block / prefix etc.
In other words, there are enough IPv4 addresses that I can get a block of 5 static IPv4 addresses, but CANNOT pay for a static IPv6 block. What's the limit / issue with giving me a static IP prefix if I'm willing to pay? Seriously...
I feel like proponents of Ipv6 have not actually tried to use it at the consumer / prosumer / small business level.
To answer your last point - it’s not IPv6’s fault but ISP’s. In most of the EU it’s trivial to get even more than one static v6 prefix and I wish I didn’t have to deal with NAT or even double NAT as it’s more and more common and instead could just run v6 only.
I gave up on some SIP/VOIP stuff because this (and other protocols) generate lag etc when you are going device > NAT > server > NAT > device route, vs device to device.
I just need ONE prefix, but a group of 5 or 8 would be amazing (then you could use the default IPv6 scheme for addressing things).
Maybe there is hope, the US lags in some of this a fair bit. There should be enough space it would seem.
> In other words, there are enough IPv4 addresses that I can get a block of 5 static IPv4 addresses, but CANNOT pay for a static IPv6 block. What's the limit / issue with giving me a static IP prefix if I'm willing to pay? Seriously...
> I feel like proponents of Ipv6 have not actually tried to use it at the consumer / prosumer / small business level.
Have the same issues. I solely blame my ISP for it, not IPv6. They still think IPv6 is like v4, but with extra addresses.
A little bit off topic (but might be an option if you are a really dedicated prosumer guy or a business it sysadmin) but you can get static IPv6 Prefixes from Internet Registries and announce them yourself over BGP. You can buy prefixes from Securebit.ch, for example.
My shitty ISP gives me a static v6, but only a single subnet (/64 Prefix). I even tried getting the business package, but even then they would only give me a /60 prefix, which isn't enough for me.
Now I have a whole /44, of which i will never even use 5% of.
Interesting trivia: The experimental Inter Streaming Protocol (ST) used version 5 in the IP header, though it was never officially known as IPv5. Consequently, IPv6 is so numbered to avoid confusion.
This was a huge problem with the IETF early on but real network operators persisted and got fully functional vrrp, dhcp, and private networks for v6 years ago.
As for disabling autoconfiguration, high end network hardware has always supported disabling router advertisements. Consumer devices should have this option, there is no reason not to. A generic workaround in any case is to configure the local subnet with a prefix length other than /64.
I’m so confused, why can’t you have a private network? It’s the best way to run it. You get a pool of public addresses to use from your ISP that you can use for anything! and then you give yourself the entirety of IPv6 private address space for your internal network.
But now you're relying on your ISP to do your network addressing for you. What happens when you have multiple sites? Now you have to do more ipv6 epicycles.
Sorry, guess I wasn’t clear. I’m talking about using NAT with IPv6 being the best way to set it up. Your ISP gives you a whole pool of public addresses you can use for hosting stuff publicly or forwarding or high availability. None of your devices will have public addresses. Then you use all of the private address space for your internal stuff.
I mean, there's a huge set of local IPv6 addresses for you to use, and odds are all of your computers are already using some (maybe more than 1). You don't need a NAT box at the network edge to set a private network. And iptables support what you described without a problem.
But most people prefer to allocate the public addresses to the actual computers, not route them by demand. So the edge machine acts only as a firewall. It's easier, and there are enough addresses.
I tried this. It doesn't work. First, which ISPs give you the static IPv6 blocks? Its pretty easy (for $10/month) to get a block of IPv4, but I had a hard time getting anyone to find any free IPv6 addresses (oddly).
What problems would occur if we were just nat-ing everyone behind those 4 billion IPv4 addresses?
I run a popular website and I have never heard anyone being unable to use it because it is IPv4 only.
I just tried test-ipv6.com and it gives me a score of 0/10, saying "You appear to be able to browse the IPv4 Internet only.". I basically live in the internet. And I am not aware of any problems this causes me.
There are entire swaths of IPv4 addresses (100.64.0.0/10) reserved just for ISPs to assign to their customers' WAN interface which will not interfere with the RFC 1918 addresses people use on their home networks:
The easiest and most reliable way to expose a computer on the internet now is those services which work something like a VPN where they have an ip address and route everything sent to it over to you via WireGuard or similar.
That way you don't have to worry about dynamic addresses, ISP blocked ports, buggy router firmware. It all just works. Things like ngrok can do it really easily for http traffic.
> The easiest and most reliable way to expose a computer on the internet now is those services which work something like a VPN where they have an ip address and route everything sent to it over to you via WireGuard or similar.
Right, but that only works if the other end has an address, and they're increasingly scarce/expensive.
You can prefer it but it will never happen. Most home ISPs have some kind of restrictions on incoming connections and the majority of home routers have buggy or incomplete firmware which make hosting at home difficult.
The benefit of the VPN option is that it requires cooperation from no one and rips right through all the obstructions the ISP and routers put in the way. People hosting at home are an extreme minority so there is basically no chance we will go back to when every single computer was directly connectable.
Perhaps, much like many of the other standards we've settled on despite the existence of technically superior alternatives, this solution is good-enough, and it was easier to implement, and it was here first. Sort of like how we still use UNIX instead of Inferno.
With IPv6, you don't have CG-NAT, or double NATting, at the ISP level. If both sides are behind CG-NAT, then direct peer-to-peer communication is impossible or at least unstable to establish.
> What problems would occur if we were just nat-ing everyone behind those 4 billion IPv4 addresses?
Even with NAT'ing we're running out of IPv4 addresses.
Now I NAT on IPv4 at home, even though my router/ISP supports IPv6. First thing I do on any Linux install at home is get rid of IPv6. I don't see where the problem is. I really don't see why my home machines should have an IPv6 IP: the outside world sees my router's IP and that's it. Now I'm certainly misunderstanding all the benefits and security that IPv6 would bring me at home but meanwhile I'll stay on IPv4 and I really don't see what the problem is either.
Not a networking expert by any means, but having built out a home network, my understanding is as follows:
Benefits-wise, your devices are addressable on the Internet, so it becomes simpler to create peer-to-peer connections, firewall traffic, and create segregated subnets.
Security-wise, your devices are addressable on the Internet, so all the workarounds to punch through NAT with terrible security implications aren't needed (I'm thinking UPnP mostly, but STUN/TURN/ICE are easy to get wrong). Essentially, under IPv4+NAT, your devices are already "addressable" via a combination of your router's IP and some form of session token, but securing such traffic depends on the successful implementation of a NAT-traversal protocol by a third party.
> Security-wise, your devices are addressable on the Internet
Nope. By default home routers (e.g., Asus) will block incoming connections just like with IPv4. It may allow pings (ICMP) in, but that's usually it.
You have to manually go in and tell the router to allow new connections in (either generally, or per service/port), just like the "DMZ" functionality with IPv4 many routers have.
And to open up those incoming connections on IPv6, we'll invent some other variant of UPnP so users don't have to manually go punch holes into their firewall to allow peer to peer connections.
IPv6 doesn't solve the problem of everything in the internal network being unable to accept incoming connections. With a NAT you need to set up port forwarding. With IPv6 you need to punch a hole into your firewall. Either way, home users will not be doing it by hand... we'll invent some protocol to do it and that protocol will have security issues.
> It may allow pings (ICMP) in, but that's usually it.
I sure hope it does. Blocking ICMP can cause TCP connections to hang due to inability to do MTU size detection.
With IPv4 this is usually not as visible, but with IPv6 if you block ICMP your connections will block as soon as you try to transfer a large block of data.
If it's working for you then great. NAT adds latency, makes the router more complex, and breaks peer-to-peer stuff (e.g. there's a game I like to play where you can have games on a LAN or over the internet, but what you can't do is have a game between two people who are behind a single IP address and other people on the internet, which became a problem when two of my friends moved in together); even in systems that have workarounds for NAT those workarounds generally add latency (e.g. your video chats might have to be routed through a central server rather than directly to friends). As IPv4 addresses become more scarce, you'll probably get put behind CGNAT (or have to pay extra to avoid it) which again adds more latency and cost. But sure the reality is that using IPv4 from behind NAT is tolerable for most people, so there's not a huge impetus to migrate.
> the outside world sees my router's IP and that's it.
At some point, that will go away due to CGNAT. A lot of people have to share their public IPv4 address these days, which means no inbound port forwarding, and potentially getting banned from services if their "neighbors" misbehave.
On the other hand, CGNAT does improve privacy to some extent.
I'm on Google Fiber, with the provided Google Wifi router, using a Google Pixelbook running Chrome OS, and cannot access google.com via IPv6 (or any other site for that matter).
I'm going to hold off as long as possible before being forced by silicon valley giants to use ipv6. I do not wish anyone to know how many devices or which device I'm browsing from. NAT is a casual layer of privacy and provides commonplace plausible deniability. IPv6 eliminates that for no personal benefit.
I too like NAT and am not sure why everyone is so keen to get rid of it.
With IPv6, all my home machines could be naked on the internet and individually addressable. But no one honestly wants that.
So there will be a home firewall. And instead of port forwarding there will be punching holes in the firewall.
And because regular home consumers won't want to do this manually for every service on every device, there will be a UPNP equivalent, however terrible that already is.
I recall hearing stories of ISP's trying to limit how many devices could use a given Internet connection and how retarding (IE as in actually limiting progress) that was.
I don't need my ISP trying to bill me per machine connected.
Some part of me wants IPv6. I know I don't want ISP level CGNAT. I know I don't truly understand IPv6.
The cost/benefit ratio hasn't motivated me to look closely at IPv6 yet. I am hoping that by the time I am so motivated, there will be plentiful standard patterns of home use, easily readable (please not more tutorial videos...) for me to learn and to point family and friends at.
The internet is supposed to work on a server-client model where you can FTP to someone's site, etc. NAT is nothing but a workaround that has caused problems.
What problems? Everything here works just fine. Except Google/Facebook/MyIsp don't know how many devices I have... ...who also are the people pushing ipv6 the hardest for some reason.
One issue is that RFC6724 will cause most clients to prefer IPv4 when the IPv6 address is a ULA (unique local). But if you're hitting a NAT either way, then maybe it doesn't matter.
It's not really silicon valley giants that really care that you use IPv6.
They already managed to get most of their IPv4 resources for a reasonably low price.
It is new small companies that will want you to use IPv6, since they will be the ones that will be fighting over the scraps of IPv4 space left by the giants.
Software that still does not work because it uses hardcoded ipv4 addresses or sockets: Steam, WoW (probably many other Games too), node/npm (before version 17), but for the most part it works! The offenders can also mostly be fixed using clatd.