IPv4 Waiting List
ripe.net
ripe.net
I'm very surprised at work and at home how often most of my Internet communications is running over IPv6. There are some surprising exceptions though [1].
I'd be willing to place a wager that there will be a $100mm company that is only IPv6 by 2030. And that the "Default IPv6 only on the Internet unless there is some weird edge case" will occur by 2040.
IPv4 as a protocol, though, will never, ever, go away - we'll see it widely deployed for the next 100 years.
[1]
$ dig news.ycombinator.com AAAA
; <<>> DiG 9.16.1-Ubuntu <<>> news.ycombinator.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46616
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;news.ycombinator.com. IN AAAA
;; Query time: 176 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Dec 09 15:21:09 EST 2021
;; MSG SIZE rcvd: 49Assuming company valuations continue to inflate, by 2030 $100m goes to any team who manage to agree on a business card design
I would have preferred an IPv4 version 2, and extension to the address space of IPv4, possibly in a backward compatible way, so that applications, routers and equipment not built for the new protocol can continue to work, of course considering only a part of the address (e.g. if the network passes trough some old routers, it's not a problem since they only have to look at the most significant part of the address that is in the same place of the IPv4 address) and can ignore the extension.
Having a dual stack network is also a mess, and I don't get how it was considered a good idea. IPv4 this way will never go away, and we will always have two network stacks on every computer. And if you have to choose between two, you will choose the easier one, or the one you know, that is IPv4. A simple extension would have been far more easier to rollout.
I'm not sure what this "ton of system administrators that don't understand it" is having difficulty with.
Don't mean to brag but it took the 12 year old me less than an afternoon (armed with a CISCO book) to understand IPv4 syntax/routing/ARP/DHCP + whatever and roll it out to my 2 computers lan.
The difficulty curve jump from IPv4 to IPv6 is humongous (IPv6 + ancillaries took me 2 days to setup in my home, and that's with a decade of IT experience.)
The issue is there are just so many officially right ways to do the same thing. Even assigning 'static' addresses has 3 official methods. Yes I get why there are so many of them (flexibility!) but it's a lot of stuff to learn and put together.
Nothing about that is different for IPv6 for your 2 computer lab.
But did you understand how your LAN differs from the internet, how NAT works, all about port-forwards, firewall traversal and why some apps could traverse firewalls (UDP) and some ones not (TCP)? Or did that come later?
IPv4 has tons of hidden complexities people conveniently forget exist when they lament how terribly inaccessible IPv6 "really" is.
"It's different" is the primary thing I hear. I'm a network guy and I learned rudimentary v6 in college ten years ago. I'll be the first to admit I don't know as much as I should, but give me a day and a good resource and I can easily be back up to speed.
My boss on the other hand....."man, it's just so complicated, I hope we never change".
I believe the problem is that IPv4 is no longer costing nothing. It's gradually getting more sparse, and thus more expensive.
Soon only the major data-centers (AWS, Azure, GCP) will be able to afford IPv4 addresses, and you as an IPv4 only company will be forced to use their platform if you want to continue running IPv4 only.
My comment was a response specifically to this.
Now do it across complex collapsed core network with 1000's of devices spanning multiple locations with multiple WAN's of differing types that all have to route together
My main complaint about the model I have is that you only have hardware switching on the first two ports, making the remaining ports somewhat useless as the CPU isn't fast enough to route more than a few hundred Mb/s.
It's the freebie Technicollr C1100T that you get with a CenturyLink DSL connection.
The IPv4 header and the way routers work wouldn't allow for a variable address. The source/destination sit in front of variable length extensions and the actual payload. Not to mention it'd be god awful to implement that kind of thing in non programmable level hardware. You could always implement it as an option header but then you've basically invented "v6 over v4" which is already a thing. Of course there is always NAT which v4 endpoints are already used to so this is a non-problem anyways, I've run v6 only at home for years at this point.
A lot of applications break on it sure but that's because a lot of applications are hardcoded with the assumptions about how big the address is not because the address gets put into a container named "v6" instead of "v4 version 2" by the OS.
Not to disagree with you, but to emphasise this - a lot of stuff in v6 is intentionally easy to implement in hardware. Stuff like the 64/64 address split, fixed-length headers. The only benefit to fixing head length / next header at 40 bytes is to enable zero-knowledge hardware accel.
Essentially similar to people describing one of the benefits to pipelining on the M1 being fixed instruction length - you can pipeline a packet/instruction without parsing it.
Especially when mDNS is in the mix and every device gets its own .local domain, which already happens with iOS, macOS and Windows devices (plus Linux with avahi), it is dead simple to have a very reliable local network.
What happens is, IPv4 works out of the box. IPv6 doesn't work, because the fancy router doesn't get a big enough subnet from the useless ISP modem.
Getting it to stay working for an entire week without a reboot? Seems to be impossible. But IPv6 just works.
This gets suggested all the time, but it's a fundamentally broken idea that could never work. What happens when one router uses the "extension" and the next one doesn't? You get a routing loop, so your packets get dropped. This would happen approximately 100% of the time when using this kind of "extension".
> And if you have to choose between two, you will choose the easier one, or the one you know, that is IPv4. A simple extension would have been far more easier to rollout.
Lol no it wouldn't. If you think people are dragging their feet on IPv6, that's nothing to how long it takes them to roll out an "extension" that's even less visible.
> This gets suggested all the time, but it's a fundamentally broken idea
Agreed. It needs to be 100% backwards compatible, or else it's going to break havoc on the internet.
And there's no such extension which can be made. Otherwise it would have been made by now.
So if you're going to break compatibility anyway, you might do so in a way which is clearly signaled and doesn't allow for the myriad of "undefined" failure modes that a theoretical IPv4.1 is going to have.
It seems like the first router would have to be forwarding only a subset of a /32 to the second router; if the second router was responsible for the whole /32 (or more), then it would have no reason to send packets back to the first router even if it didn’t know about the extension. But forwarding a subset of a /32 to a router that doesn’t know about the extension is clearly a misconfiguration.
If you have to advocate addresses in IPv4-routable blocks (/32s, or I think /30s in practice because of needing a broadcast address etc.) then your protocol doesn't fix the address exhaustion problem and you still have to make a clear distinction between the parts of your network that are running "v4.1" and the parts that are running "v4". You'd end up with something like 6to4/6rd but running that way forever, with no prospect of ever improving, and the IPv4 address space fragmentation issues would get worse and worse. So there's not really any practical advantage over CGNAT.
This doesn't solve the dual-stack issues, as either the endpoint needs both v4v1 and v4v2 stacks, or it needs to be offloaded at the router - essentially re-inventing NAT.
What v6 has done, is essentially say there's no way to do this without breaking things, so we might as well break everything at once. So a lot of things that were optional, hacky bolt-ons in v4 have been adopted properly, because if we're going to add a 2nd stack, we might as well make the effort worth it - because lets face it, we're not going to have another chance to make a 20+ year transition any time soon.
Now consider other tech that's even more different and how we jumped on it over the last decade. Anything related to mesh / overlay networks is just as complicated in practice and we learned how to use it just fine. People are capable of learning and lots of public traffic already goes over IPv6. And if they cannot learn about IPv6 given all the time we had available... maybe they should be replaced with people who can learn? We managed to move from IPX to IPv4 in the past and that was a bigger change.
Pre-IPv6 all IP code had 32 bits reserved for addresses. For more addresses, you would need >32 bits.
How do you squeeze >32 bits of data into 32 bit data structures?
You would need to touch every bit of IP code out there to expand the corresponding address filed (e.g., in a struct in_addr)—which is what had to be done for IPv6.
* https://en.wikipedia.org/wiki/STUN
* https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
* https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...
See also "NAT Issues when playing games":
* https://support.plume.com/hc/en-us/articles/360035745134-NAT...
Certainly we'd need hole punching protocols (UPnP/PCP) because IPv6 firewalls would be default deny on incoming connections, but the addressing issue introduces a bunch of things on top of that. The fact that these kludges are considered 'normal' and/or 'okay' is kind of sad.
And how do you hole punch through CGNAT? (AFAIK there is no way.)
Everything is being crammed into HTTP/QUIC/whatever because of all of these limitations: what applications could have been designed better if bits flowed more freely? (SCTP and DCCP died because of limited middleware network boxes.)
Backwards compatibility would have made it far more complex.
If you sit down to look at IPv6 it's really quite straightforward. I think a lot of network admins are secretly hoping to retire before they have to learn a new technology though.
That's not really true. If you put a minimum of effort, you should be able to setup a local-only IPv6-subnet quite easily. And going from there to internet routable IPv6 takes almost no effort at all.
Yes. There are things which are different from IPv4. But it's not rocket-surgery. If you had any genuine interest in understanding it and put in some effort, you would find most of the "difficulties" are not really all that difficult.
If we were to start with a "from scratch" mindset, I would argue it's rather IPv4 which is hard to understand:
- subnetting? how? why?
- NAT?
- port-forwards?
- upnp assisted firewall traversal?
- upnp UN-assisted firewall traversal?
- Forcing app-developers to use UDP over TCP because... lack of end-to-end connectivity and ... again firewall traversal often only being possible with UDP.
- And what about carrier grade NATs?
And all other kinds of stuff we've just gotten used to being that way.
IPv6 solves most of those things right away... So the only thing you have to learn is the addressing-scheme... And that's about it.
I think everyone who complains about how IPv6 is "hard" has honestly just forgotten just how terrible hacky (and thus complex!) our IPv4 everyday situation really is.
It's far easier to learn IPv6 from scratch than to learn IPv4, and then also learn the hacks underneath it, it's miserable.
Sure, that wouldn't give you the 340 trillion trillion trillion IPv6 addresses, but it would have turned 4,294,967,296 IPv4 addresses into 281,474,976,710,656 ipv? addresses and been easy enough to remember that on your local "block" you use idk, "AF09" as the prefix or whatever, and every person on the planet would have about 35 ip addresses (or ~9,000 with a 6 digit prefix) available to them on the new setup not even accounting for NAT
And at 60 percent usage, it will probably be India[1]
[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
I wonder why? Is IPv6 adoption significantly higher for residential internet connections vs. corporate networks?
That‘s never been a requirement. What Apple does require is that apps correctly work over an IPv6-only network that uses NAT64/DNS64. Which means not hardcoding any IPv4 addresses and generally not expecting domains to exclusively return IPv4 addresses.
Your experience with huge ISPs has obviously been different from mine. I am deeply grateful that I've benefited from two "first world" advantages: Comcast has (surprisingly) been very proactive about IPv6 support, and here in the Bay Area I have actual competition available for me to switch to. But in other parts of the country, that's for sure not true
---
to address the dig portion of your comment, the AAAA record (err, or lack of it) for github.com likely is a lot more impactful than HN
It's not that I think major users are going to switch, but I'll point out that GitLab actually does have AAAA records
turns out that if you allocate a private /24 to every POP you can absolutely exhaust 10/8 in a big last mile ISP.
they started with ipv6 for their own management network before any public netblocks started getting rolled out to customers.
The large push for IPv6 was started so that management of set top boxes/cable modems no longer required large islands of RFC1918 space where they had to deploy multiple NAT's to get traffic in/out of those environments.
I never thought about the scale of their internal network. It’s nuts.
Or will IPv8 go straight to 1024 bits?
;)
For example, here in Portugal the largest ISP (MEO) has had a wide deployment of IPv6 for many years. However, it's (up to very recently) main end-user router supplier (Thomson/Technicolor) has also had chronic IPv6 bugs in its firmware(1). MEO enables IPv6 by default nevertheless, but if you're an advanced user you'll have a hard time overlooking the random connection failures to IPv6 destinations.
(1) Specifically, it resets the flow label field randomly when it is non-zero (the case with most recent versions of Linux, macOS and, I guess, Windows). Turns out the flow label is taken into consideration by many load balancers so, if it changes mid-connection, your packets may end up in a server that has no knowledge of you and you get a connection reset.
Lack of IPv4 addresses is a problem for new ISPs trying to enter the market, as even with levels of NAT, you need some minimal address space to serve your customers, which is harder and more expensive to get. So on one hand starting with IPv6 only stack would avoid these problems, but on the other hand it also means that every potential customer will be unhappy and in the end, you won't get many customers willing to pay you for IPv6 only connection.
If you have a mobile device on US T-Mobile you only get a IPv6 address on it:
* https://www.youtube.com/watch?v=nNMNglk_CvE
* https://pc.nanog.org/static/published/meetings/NANOG73/1645/...
* https://www.internetsociety.org/resources/deploy360/2014/cas...
Any access to IPv4 is through a proxy.
So I was wondering when/if company in a similar situation would not feel the need to maintain IPv4 proxy or would seriously evaluate whether they still need it wrt of cost of the IPv4 address space necessary and potential loss caused by customers who would not be ok with missing IPv4 internet.
But maybe such speculation is missing the point, and cost of the IPv4 addresses is not as bad as keeping dual IPv4/IPv6 stack running in a datacenter. I don't know.
That said, you definitely have a point that right now, I should rather wonder how many other ISPs are moving to IPv6 only stack with IPv4 proxy like US T-Mobile did. Here I would definitely expect that telcos today are moving in this direction when planning new infrastructure (eg. for edge).
Note that NAT64/464XLAT solve the reverse problem. NAT-PT was the theoretical solution, but see RFC 4966 for all the reasons why that was a failure.
It’s true that many SMB network infrastructure devices have poor support for IPv6, particularly w.r.t. the management interface.
But IPv6 support is old at this point. Very few things have no (as opposed to inconvenient) IPv6 support.
For heavens sake, there are versions of IRIX and VMS/VAX with IPv6 support. Those OSes run exclusively on hardware that hasn’t been manufactured for two decades, and the companies that released them have been defunct for almost as long. Windows XP (deprecated over 10 years ago) supports it. MacOS 10.7 (released 10 years ago) supports it.
In other words, if you’re willing to run network management from a dual-stack host, you can probably switch over all “regular hosts” today at zero hardware cost.
You have to be running seriously old hardware and software to not have IPv6 support today. So old that it should be on an air-gapped network anyway.
The only relatively common exception is Cisco Meraki and some cheap consumer-level AIO router/APs.
The cost of IPv4 addresses is slowly creeping upward, but hasn't hit a point of being prohibitive for a company. Once they hit near the $1k level, that's when I think things will start to change.
https://www.dslreports.com/forum/r32136440-Networking-IPv6-w...
Amazon spends a lot of money on IPV4 blocks for AWS. They would directly benefit from wider IPV 6adoption.
This would be a great way to get regular people to care about this technology. That, in turn, would make ISPS care much more than they currently do.
I bet there are lots of customers with 10 year old gigabit routers that have had no reason to be replaced, and will still be perfectly serviceable for another 10 years, especially if they use a separate wireless access point. Many of these people probably don't even know what any of this means.
Having checked just now I see that github is still IPv4-only.
Most of their customers in pretty much everywhere. Global IPv6 adaptation is at like 33% and only a couple of countries pass the 50% mark.
Then Virgin bought them.
https://havevirginmediaenabledipv6yet.co.uk/
> Answer: No [crying face emoji]
> We've been asking since March 2010.
I am surprised you say you work has functional IPv6, I know we have not even talked about enabling traffic anywhere for IPv6
bold for you to assume we will have active internet for 100 more years /s...
If I'm on IPv6 there is no NAT and it's basically security by obscurity (not really but port scans would take forever)
What if I host a small web script on my machine and I surf the web with my IPv6. Couldn't all website owners do port scans on my address (because they obviously see my address) and then access my local site or even God forbid one of my staff is running an unpatched windows. How is it safe if it's basically (in ipv4 terms) a 1:1 NAT for all my machines?
You should still be blocking incoming requests for IPv6 endpoints and only open ports you intend to serve publicly.
NAT wasn't meant to be a security mechanism and because of that, the practical designs found in most devices don't treat it as such.
On IPv4, NAT and firewalls are usually one and the same rule set. That rule set is slightly smaller with IPv6 because of the lack of NAT, but the mechanisms are still the same. If your IPv4 firewall fails, NAT won't save you, because that's part of the system that failed.
If you're still insistent on using NAT then... use NAT. The core technique works on both protocols, you'll just have to set it up yourself because router vendors don't usually implement it.
100% of consumer IPv6-capible routers block unsolicited inbound IPv6 by default. It's not something you need to worry about unless you are hosting, and in that case your concerns are the same as if you're using IPv4.
Whether IPv4 or IPv6 does not negate the need for a firewall at the ingress/egress.
I mean, clearly OP doesn't need to worry about the lack of NAT, but not having gone through all of the things listed on that list, I would assume that they all require an active participant behind the NAT/firewall, and would still be required for just a plain old stateful firewall (assuming you don't have the ports open) when you want to communicate with some other endpoint behind another firewall.
Not necessarily. I mean if someone's setup really is "just NAT" then you can just send packets with the addresses of their internal hosts to their router and it will route them.
One of the differences between IPv6 and IPv4 is that the v6 address space is enormous and stack assumes your interface will have multiple addresses.
In particular, on each interface you normally have:
* A link-local IPv6 address (non route-able). This is used for neighbor discovery and router solicitation, among other things.
* A static-ish cryptographically generated address (often called a secured address). This is used for incoming connections.
* One or more temporary addresses with relatively short lifetimes. These are preferred for outgoing connections. The lifetime of these addresses often overlap because any the OS has to maintain the address for any open connections.
Note that these addresses can be generated automatically using SLAAC, and you would normally have a set of secured and temporary addresses for each upstream router that is sending router advertisements. You may also have another set of secured and temporary addresses in the IPv6 private range (equivalent to 10.0.0.0), if your router is advertising that (useful for internal services like DNS, where you want to configure the server address in the DHCPv6 config). So it’s not unusual for a given host on a simple home network to have a dozen addresses in 2 or 3 subnets (on one Ethernet interface).
The bottom line is that your server should be listening on the secured address and your web browser should be using temporary addresses for outbound connections.
If it's not a unique address for every request, it's unfortunately too long.
You can always change the configuration to reduce the address refresh interval for your OS.
But, yeh, I went through the same moment of fear that you did when I first turned on ipv6.
Sure, you absolutely need a stateful firewall, but not needing address translation makes it easier to troubleshoot, makes it easier to establish end to end connectivity and no need to port forward or things of that nature so multiple clients can all use the same port.
* https://en.wikipedia.org/wiki/STUN
* https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
* https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...
Not sure if that's more or less complicated than already knowing your IP address and 'just' using UPnP/PCP:
NAT isn't required in v6, it's not wanted in v6, but it's perfectly possible. If you think about it, PAT/NAT (port-based NAT) doesn't happen at the IP stack, it happens at the port level.
That's why firewalls exist. And they work with IPv6.
My ISP gives out an IPv6 address to my Asus, which also picks up some prefixes for allocation via DHCP-PD. This causes my printer pick up an IPv6 address, but it is not accessible to the outside world.
Statefull firewalls still exist with IPv6, so by default connections from the general Internal cannot connect to your 'internal' systems. Hole punching still needs to be done with UPNP/PCP (at least on residential systems; SMB may not want this)
* http://upnp.org/specs/arch/UPnP-arch-AnnexAIPv6-v1.pdf
* https://en.wikipedia.org/wiki/Port_Control_Protocol
The advantage of IPv6 is that you no longer have to have things like STUN, TURN, etc. (Remember Skype super-nodes?) Your client knows its own IP(v6) address, gets the IP address of the other end, and then tells your firewall to allow connections between just those two addresses. Once your session is done the ACL is deleted and you're completely default-blocked from the outside again.
Copy-pasting from a previous discussion a little while ago:
---
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table(s) it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall. With IPv6 the address/port rewriting is not done.† Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.‡
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence. The security comes from the state checking.
† It is possible to have private IPv6 addresses using ULA, and then the router/firewall uses NPTv6 to rewrite the prefix (leaving the /64 interface component alone).
‡ Just like with IPv4 (NAT), to allow unsolicited 'new' connections in you have to do do firewall hole punching with (e.g.) UPNP. But by default things are blocked.
---
No-NAT != access from the Internet.
That is the cause of the current spike/backlog.
RIPE checks the paperwork matches, and transfers this /16 from Alice to Bob. They can charge whatever they choose for this, RIPE's members are the LIRs who are paying those fees (including Alice and Bob), so they're effectively agreeing among themselves how to pay for the existence of the RIR.
However, this entry is about the Waiting List, which is for a steady trickle of small blocks (one /24 each) just to get new members started. The idea is, you need a few IPv4 addresses for say, the new Spanish ISP you started, even if it's mostly an IPv6 ISP, so here is a small block for that purpose.
So, not billions of dollars. The exact scheme has not been determined, the proposal sketched was that a /24 would cost maybe €5000 in 2023. Maybe they do 4000 of those, that's €20M.
The rationale is, industry consolidation means that per-LIR fees either need to increase substantially over the next decade (unfriendly to small members, forcing further consolidation) or a new fee mechanism is needed. Understandably members who scarcely need RIPE services because they have a perfectly nice IPv6 block are frustrated to see that members paying the same annual fee incur significant staff time (meaning more FTE cost) because their stupid IPv4 renumbering changes mean paperwork. So, why not make that cost money?
I'm not sure what this graph means. The first sentence implies it's the number of users with IPV6 connectivity. The second sentence implies it's the number of users that access over IPV6-- but a big subset of users with valid IPV6 connectivity might end up only connecting with IPV4 for various reasons.
Funny how their site has a handy pop-up definition when you hover over IPv4, but not for LIR.
Tradable… check.
Has some inherent usefulness… check.
Price is rising rapidly… check.
IPv4 is going to live forever as a non-crypto coin!
I know you’re joking but it’s not tradable (by home users). I can’t just sell my IP address to someone else. ISPs.. maybe, but I can imagine they make more money continuously leasing them out than selling them for a one off payment.
What's causing the big increase now?
Market prices on the other hand have exploded this year, $50 per address isn't uncommon anymore.
I'd hold them for 3+ years really. It seems very unlikely that IPs are going to lose value within 5 years. We're betting on 10+ years before the bottom falls out (you can see some of our math at the bottom).
IP addresses truly were the first NFTs.
0: most all cellular/5g networks already provide IPv6 since even CGNAT is expensive compared to assigning a /128 per-device. iPhone 13 (or ios 15 with iPhone 12) also has a 'data mode' switch, which will use 5G if it's faster than the local wifi - this likely opens up the device using cellular to allow access to IPv6-only sites when their WiFi doesn't support it.
What's the one-true, best-practise, everyone-accepts-it, supported-almost-everywhere way to provide dual ISP connectivity to an SMB with IPv6?
Once they solve the class of problems like that it'll take off a little faster.
Does anyone have IPv6 only facing servers for public consumption without any IPv4 alternatives?
well, kame.net will only give you a dancing turtle over ipv6..
Why buy an 802.11ax capable router when the best connection you can get is an 8mbps DSL connection that drops out when it rains?
Even at that price it was cheaper to rent a modem for a buck a month, but some people like to own things, I guess.
Even worse is when someone deploys IPv6 but does it in a comically nonsensical way like Digital Ocean[1]. Yes, you read that right, they assign /124s even though the smallest allocation is supposed to be a /64. And if you think this means you're sharing the same IPv6 address with virtually every other droplet in a datacenter, you would be right. Welcome to every blacklist everywhere. It is kind of like hosting an entire datacenter off of a single IPv4 address.
https://aws.amazon.com/blogs/networking-and-content-delivery...
https://aws.amazon.com/about-aws/whats-new/2021/11/applicati...
I guess we can thank US government partially for that: https://aws.amazon.com/blogs/publicsector/aws-enables-us-fed...
First, running exactly one open port per IP (443 or 80) is the worst use of resources. The whole "crisis" could be solved with simple browser support of something like SRV records. This could be implemented with "here and now" technology, rather than adopting a new standard for the entire internet backbone.
Next, widespread use of NAT provides plausible deniability for everyone on the internet. Google, Facebook, Comcast, Verizon, etc push ipv6 hard in order to enable causing tracking of individual traffic on the internet. These institutions have exactly 0 business knowing how many physical devices are behind a firewall. No, ipv6 privacy extensions do not provide the same sort of anonymity that a NAT firewall does before you hit that downvote button and take away some of my fake internet points.
Hahahaha....
Oh.... The amount of bullshit I've dealt with over the literal decades, going back to secondary school, college and University, as a consumer, because of NAT (The joys of console gaming and "Strict NAT" or skype in the early days just falling straight over).
The privacy implications I will however grant you.
TLS SNI[1] and the HTTP Host: header[2] already do this. Enabling multiple HTTP(s) serving ports with something like SRV wouldn't give us any additional capacity here.
> These institutions have exactly 0 business knowing how many physical devices are behind a firewall.
These institutions can already analyze TTL, source port, IPid, and other packet metadata to enumerate hosts behind NAT.[3]
[1]: https://en.wikipedia.org/wiki/Server_Name_Indication
[2]: https://en.wikipedia.org/wiki/Virtual_hosting#Name-based
Try hole punching for games through CGN:
* https://en.wikipedia.org/wiki/Carrier-grade_NAT
AFAIK there is no way to do it, so you're SOL if that's what your ISP uses.
Many ports have also been restricted by the browser because you can format malicious HTTP requests to be an DoS vector for certain services, like IRC, which has been abused by malvertisers in the past. Because of this you'd still be working with a whitelist of ports, only extending the problem a bit longer.
I'm not entirely sure what privacy your NAT guarantees for you. Individual devices can already be fingerprinted by their behaviour, so you'd need to run identical software on identical hardware to combat that. If you manage to do that, you're only one Set-Cookie away from unique identifiers anyway.
Because of the refreshing nature of privacy extensions, you can't derive an exact number of devices active on a network. More and more random new addresses become in use over time to the point where you'd need access to your router (which your ISP already has, unless you configure your own) to get a proper count. You can at best get guesstimations, but that's not much different from the result of NAT.
In theory, I agree with you: pasdive fingerprinting IPv6 is easier than passive fingerprinting IPv4 on an ISP scale or larger. In practice, though, I don't think it matters. Someone who has access to all traffic from your network, probably has access to some kind of boundary as well.
If you already install your own traffic collector to NAT everything through so your ISP modem doesn't see your devices, you can do the exact same for IPv6. NAT may be strongly discouraged, but it's still possible using the same techniques.
The security reasons would go away with the presence of the SRV record specifying the allowed port for the domain though. Well, at least as much as any other DNS challenged based method is secure.
I know a database that's updated every night via a server-to-server connection that passes five levels of NAT, and when that crontab broke someone had to fix it by finding and correcting a bug in a 1500-line NAT configuration on one important router where the consequences of a mistake would be very bad indeed.
It works in the sense that the database is updated, but I cannot help thinking of Truth 3 in RFC1925.