At some point, some low-hanging companies are just going to start running IPv6 only applications and deal with the fall-out of some nn% of their customer not being compatible. Those customers will complain to their ISPs, which will provide incentive to get IPv6 deployed (should have been done 10 years ago honestly at any credible ISP). Getting the number closer to 100% will make it easier for new companies to deploy IPv6 only, until we get to the point that IPv4 is seen as some legacy thing that isn't relevant but used to be important in the dark ages of Web Deployments.
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.
> Those customers will complain to their ISPs, which will provide incentive to get IPv6 deployed
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
fun fact: comcast have been proactive about ipv6 because their management network grew so large and unwieldy, through various acquisitions and long term inefficient use of space, that ipv4 RFC1918 10/8 (and 192.168 etc) was no longer sufficient to address all of their individual netblocks.
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 issue is that each set top box, cable modem and everything else gets a management IP address on the network as well for allowing configuration changes/validating status/all that fun stuff.
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.
yes, from what I've heard, they specified full ipv6 as a non-negotiable "must have" with their CPE vendors (and CMTS) almost 16, 18 years ago. Comcast gets a lot of shit for its poor customer service practices, as does any huge cable company, but the people who run the core IP network knew, and still do know what they're doing.
I think a lot of SMBs are the holdouts for IPv6; their entire IT infrastructure is IPv4, and switching will be expensive because every router, subnet, VLAN, &c. must be upgraded. Small home networks are comparatively easy once all clients support IPv6: switch from a single subnet in the private range to a single /64 and add a stateful firewall. Since SMBs can run a lot of clients with very few (or even one!) public IP, IPv4 addresses will need to become much more expensive (or critical remote services will need to switch to IPv6 only) before it's cheaper to upgrade internal infrastructure to IPv6.
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.
Many SMBs should probably go full cloud and once that's done they can "downgrade" the office network to zero-trust and maybe deploy IPv6 at the same time.
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.
I'm not saying there are devices that don't support IPv6 (though there are), I'm saying the IT costs of reconfiguring the infra for IPv6 are higher than the costs of paying many times the current going rate for an IPv4 address.
The trend on the "IPv6 Adoption" tab is fascinating. It looks like the inverse of the usual "high traffic during the week, low traffic during the weekend" pattern that I'm used to seeing in traffic graphs.
I wonder why? Is IPv6 adoption significantly higher for residential internet connections vs. corporate networks?
I mean yes, people who don't know what an IP is use whatever their ISP gives them, and ISPs have mostly rolled out v6 by now (albeit imperfectly). Businesses actually manage their networks actively, and they use what they know, which is almost always v4.
Mobile Network operators have been quite forerunning with regards to ipv6. That is primarily the driver for ipv6- iOS forcing apps to have an ipv6 backend was a huge driver too for services.
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.
Corporate customers are very slow to transition to IPv6. Most of them aren't feeling pressure on the IPv4 space the way ISPs are and corporate security appliances are notoriously slow to adopt IPv6.
Even if IPv6 is used internally, a lot of enterprise environments have outbound proxies which will use IPv4 by default. For example HP may have a /8, but all outbound is forced through a small number of PoPs with very enterprisey http proxies.
I was on Chorus/UPC in Ireland. I asked them in 2013 when v6 was coming, they told me it was coming in 2014. I asked them in 2014 when it was coming, and they said 2014. I asked them in 2015 when it was coming, and they said 2014.
Well, even when ISPs are dilligent in deploying IPv6, they still have to deal with troublesome end-user hardware that can't just be replaced overnight.
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.
I wonder when (or if) we will see new IPv6 only ISPs. That would be an indication that the transition is actually happening. Even though you note that most of your internet communications are done over IPv6, I doubt that you would be willing to go for IPv6 only ISP.
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.
This is very good example how an ISP can move to IPv6, but my comment was mostly speculating about the IPv4 part. Even US T-Mobile needs to have a bunch of IPv4 addresses to maintain it's IPv4 proxy (and the size of IPv4 address space they need is determined by the size of their expected customer base).
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).
I think that once customers are only assigned IPv6 addresses, then IPv4 is a bit of a sunk cost with regards to addresses. You may be left with the 'overhead' of running the proxies for the IPv4 Internet.
Look at how long it took ISPs to turn off Usenet. I'm sure they'll keep running DS-Lite for decades to come, but they'll gradually allocate less and less resources to it, maybe put clauses in peering agreements that they pay less to upstreams who are IPv4-only. And then eventually IPv4 will become an optional extra, and then outsourced to one of a handful of firms still handling it...
The big hold up, IMO, is ISPs. They seem completely unmotivated to upgrade their infrastructure to support IPv6. Until a majority of them do that, I don't think any 100mm company will do a "IPv6 only" thing.
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.
Maybe someday Verzion FiOS will support native v6. When I set up a Hurricane Electric tunnel over a decade ago I never thought I would still be using it in the 2020s.
How will large corporate networks transition? I've recently seen a large organization using the 5.0.0.0/8 address space. The decision to use these addresses was made a long time ago and they still didn't switch to an actual private address space and choose to deal with all the issues instead.
Dual Stack. Start off with by deploying IPv6 across the network without touching the IPv4 environment. Most modern operating systems will just automatically detect they have an IPv6 router and auto-configure. Big advantage of IPv6 is that address autoconfiguration is built into the protocol itself - no need for DHCP, Static Configuration, etc...
IPv6 is a disaster. It's too difficult to understand or configure properly, and it's too different from IPv4. There is a ton of software that breaks with IPv6, and a ton of system administrators that doesn't understand it (and for a reason, it's too complicated for nothing).
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.
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.
I'd argue that that's in essence what NAT (especially CGNAT) does by abusing the 16 bit port number: extend the 32-bit assessing space to ~48 bits. And it pretty much works just fine for many many use cases.
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.)
For home users and non-professionals, IPv6 is simpler than IPv4. Every device autoconfigs selecting its own address via SLAAC. No DHCP needed. No need to understand NAT and no dealing with subnets.
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.
Ditching Ethernet broadcast that hit every single interface on a network when you only wanted to communicate with a single device on a specific protocol is a big win. Getting rid of Subnets by making the smallest possible subnet infinitely large eliminated 90% of network confusion around subnets. Privacy based IP addresses also a nice addition. After working with IPv6 for 10 or so years, you really grew to appreciate what an architectural advantage it has over IPv4. As for deploying it? I dunno - I just plug my Ubuntu laptop into a WiFi Network and it just seems to work. I'm pretty sure the comcast routers I've connected to have had zero configuration beyond what they can pick up connecting to comcast. In the future - people (other than say Network Engineers working for IT) probably won't even discuss things like "IP" addresses.
Yeah. My useless ISP router supports it as well here. But it doesn't work when there's a second router in between. Something to do with Prefix Delegation not working, supposedly. And the ISP router by itself has zero controls for IPv4 DHCP, and so on, so it's absolutely useless by itself.
IPv6 isn't all that difficult, insomuch as IPv4 is not basic itself. In fact it's probably easier to teach someone with no prior knowledge IPv6 instead of IPv4. "What's the netmask" isn't a question for user endpoints, it's /64. You can still DHCP, you can still hardcode, but the replacement for ARP can also assign you an IP without having to configure external services to make that happen.
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 mention it'd be god awful to implement that kind of thing in non programmable level hardware.
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.
IPv6 is no more difficult to understand than IPv4. In many ways it is easier since there are fewer legacy RFCs pertaining to it. System administrators don't understand it because they have not been forced to learn about it yet the same way they were forced to learn about IPv4.
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.
I'm just a programmer with a tiny homelab, and it took me less than a week to understand enough to be able to set up an IPv6 LAN. This included learning enough to be diagnosing and fixing routing/DHCP/RA issues in my router OS and all the LAN machines, implementing prefix-delegation to one of the LAN machines to make it a subrouter for Docker containers, and setting up NAT64 and DNS64 on the router so that the LAN machines could even disable IPv4 entirely. And those latter two were just me flexing because it was a homelab; a regular LAN wouldn't go that far.
I'm not sure what this "ton of system administrators that don't understand it" is having difficulty with.
Maybe it was easy because it was your home lab. System administrators will have to deal with orders of magnitude more complexity and thousands of devices. Even if their home labs are meticulously IPv6, moving a corporation to IPv6 is a major undertaking. How can they justify the effort if IPv4 still works and costs nothing?
> How can they justify the effort if IPv4 still works and costs nothing?
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.
> I'm not sure what this "ton of system administrators that don't understand it" is having difficulty with.
"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".
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
>it took me less than a week to understand enough to be able to set up an IPv6 LAN.
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.
Did you misread the 6s in my comment as 4s? I'm not sure why you're telling me that IPv6 is more complex than IPv4 when my comment said nothing to the contrary.
He is telling you because you come off as a know it all who can figure everything out while at the same time you question why can't other people figure out the same as you can while at their own home labs. Apparently though you couldn't figure out this answer to your obviously self answerable question.
If this is what you got from my comment, it seems you need to read more closely. I listed specifically what I did learn, pointing out how it was not everything but was enough for setting up a LAN.
> 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.
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.
My current home router is a cheap Microtik which does exactly what you describe. I also previously had a low end Ubiquiti EdgeRouter with the same setup as I have now. I am pretty sure the free router my ISP supplies does that as well but I have not had the opportunity to test it out.
I'm using an Ubiquity Edgerouter Pro PoE with exactly this configuration. I'm not saying it's the best product for this purpose, but I have used it in this way for several years now.
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.
The only reasonable way I can see to do this, would be to have an IPv4v2 packet within an IPv4v1 packet. So the v4v1 packet is delivered to its endpoint then stripped and the v4v2 packet traverses onwards to its destination.
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.
> IPv6 is a disaster. It's too difficult to understand or configure properly, and it's too different from IPv4. There is a ton of software that breaks with IPv6, and a ton of system administrators that doesn't understand it (and for a reason, it's too complicated for nothing).
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.
> 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.
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.
I’m having a hard time thinking of what kind of network topology would result in a routing loop. Can you elaborate?
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.
Two different /48s might be on two different sides of the world; the first router has no idea what the full path from it to either of them is (and of course the path shifts dynamically because that's how internet routing works) so it has no idea which paths might have IPv4-only routers on.
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.
>> I would have preferred an IPv4 version 2, and extension to the address space of IPv4, possibly in a backward compatible way
> 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.
I'm not looking forward to asking my parents to visit http://[fe80::abcd:whatever] to access their router interface when something goes wrong. Hopefully they'll be able to use basic numeric IPs for the rest of their lives.
Depending on OS, you might need to actually put the interface name in there? As you can have fe80::1 on multiple interfaces...it being link-local. Maybe browsers are holding it back?
IPv4 is a disaster, when you consider what you need to use it in a modern day system. IPv6 is far simpler in nature, and doesn't require many of hacks that have plagued enterprise networks like SD-WAN, NAT and NAT copium.
It's far easier to learn IPv6 from scratch than to learn IPv4, and then also learn the hacks underneath it, it's miserable.
> IPv6 is a disaster. It's too difficult to understand or configure properly
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.
I am not aware of the reason they went to such a high-complexity setup. They could have simply added a 4 or 6 digit hex code prefix to the IP addresses and figured a way to geographically lock that code.
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
Part of the problem is older consumer networking equipment. Comcast has supported IPv6 for quite a while, but many routers I've used are not configured correctly out of the box to work with Comcast's IPv6 implementation. Even getting IPv6 to work with my new UniFi equipment took changing a setting or two away from the defaults, though that is more expected with prosumer and enterprise gear.
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.
It is not just ISP, I would guess a TON of corporate, enterprise, and business networks have no functionality of ipv6, even if their hardware supports it, the first thing the network admin does is disable all that....
I am surprised you say you work has functional IPv6, I know we have not even talked about enabling traffic anywhere for IPv6
I setup an IPv6-only server a few years back. At the time the biggest annoyance was that github wasn't available - so I couldn't clone my dotfiles, projects, and things.
Having checked just now I see that github is still IPv4-only.
The graph starts in November 2019 because that is when the waitlist system was introduced. There's not point in going back further because further back the waitlist didn't exist.
So this really big increase in November 2022 is a brand new phenomenon, and the waiting list has been sitting at 0 for the entire time since the 2019 increase.
RIPE ran out of spare addresses at the end of 2019. After the queueing system was instituted some organisations must have returned some address blocks, which were used during 2020 and 2021, and my guess is that these have now run out. (it could just be that the return rate is below the request rate, but IMO the graph looks too straight for that).
If you look at the graph for the address pool (https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-pool) you see that the number of available addresses rose starting from February 2020 and then was rather constant until decreasing again in August/September before running out now. To me the timing looks like it's Covid related, I guess many companies didn't want to change their addresses while the admins couldn't get physical access to the servers...
"Since the RIPE NCC began operations in 1992, we have been responsible for distributing IP addresses and AS Numbers in our service region. In November 2019, we exhausted our remaining IPv4 pool. This means that networks in Europe, the Middle East and parts of Central Asia are no longer able to receive “new” IPv4 addresses from us that haven’t previously been used by another network."
I imagine some critical mass will be reached where cloud providers start charging exuberant fees for IPv4 addresses and many businesses go IPv6 only (which wouldn't even be a big hit for mobile users[0]), and this news will be widespread enough to encourage ISPs to actually roll it out at a faster pace. Now, whether that's in 10 years or 20 is to-be-seen, but I agree with you and I doubt the rollout of IPv6 hits the point where people stop wanting IPv4 addresses all-together within 30 years.
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.
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).
All of the cloud providers and even VPS services have been dragging their heels on IPv6 for ages and it makes no sense to me. These services could all benefit from having IPv6 only options for people who don't need IPv4 addresses. V4 addresses are turning into real money, you would expect the services to try to optimize their use to save costs.
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.
Am I right in thinking that IPv4 will only go away if all clients can support IPv6? For example, there are many embedded devices that will never be updated to have dualstack (including many home routers).
Does anyone have IPv6 only facing servers for public consumption without any IPv4 alternatives?
Home routers have a very short life-cycle. Most of them have a median life of < 10 years, and it's reasonable to expect that the majority of them will be upgraded every 20 years or so. It's the other embedded (manufacturing, utility, etc...) devices that have 20+ year median lives that will prevent IPv4 from ever going away. Dual Stack (as the vast majority of Windows/MacOS/Linux/BSD systems are capable of) - creates a nice transition path - slowly but surely more and more IPv6 creeps into DNS/Local Addresses. If you deployed a IPv6 only facing server today - then some 20-30% +/- of your potential customer base wouldn't be able to connect - but that number will go down by 1-2% each year for the next while, until, in 10-15 years, you'll be able to reach 98+% of your audience, so you'll say WTH and go for it.
You probably want to upgrade sooner for faster wifi anyway. My router I only just got from my ISP caps out at 100Mbps while the ISP provides gigabit speeds.
I don't think 20 years will happen but I've seen modem/router combos that lasted for ten years. Customers bought them way back when, and never considered buying replacements because they just worked. If all you do is read news and do taxes, you can still get away with 802.11g easily. You can pull about 10 to 20mbps down that, and for many people that's more bandwidth than their ISP provides then with.
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.
This is true but most of the ISPs I worked with (in an admittedly smallish town) would often upgrade for the user every 5 years or so. A lot of the times it was needed as they shipped the cheapest routers they could get, even when it wasn’t they’d roll out new stuff as people called in. 10 years I could see, my mom and dad used the same tiny netgear modem/router for 7 before having me redo their network.
This is true but I think, ime at least, most people don’t buy their own routers and get a cheap modem/router/Wi-Fi ap unit that gets replaced every few years when they experience issues. Then again my experience was It so it wasn’t like the people who never had issues called.
Home/consumer use is where IPv6 is at highest adoption. It's businesses that lag behind. Still amazing to see clear 9-to-5 weekday difference between IPv4 and IPv6 traffic in graphs in 2021.
Just yesterday I witched my office network to IPv6 and one thought kept creeping in regarding security.
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?
I do understand that but NAT was acting like another layer of firewall because I could be sure that none of my devices behind the nat could be accessed without port forwarding. With IPv6 they can
This is not exactly true. There are many tricks in the NAT traversal toolkit, depending on your configuration it can be fairly simple to work around. In every case where you use NAT, you also use a firewall.
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.
Not from a passive, receiving network, no. If anyone on the network uses a web browser, there's a good chance your network can be attacked by a malicious ad through NAT slipstreaming, through (https://samy.pl/slipstream/)
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.
That's not security, that's an assumption. UPnP was so vilified because it broke that assumption and revealed NAT never provided security, it provided an assumption.
NAT is a workaround for the small amount of address space that was allocated originally. That's not the case on IPv6. I'm sure you can NAT stuff but why the hell would you want to do that and have to maintain all the stateful pain in the ass stuff required such as NAT tables which are going to be much larger.
If you have machines in the network which you don't trust to handle their own incoming connections securely you can block those connections at the firewall, without port or address translation. Ideally you'd put those on hosts on their own locked-down VLAN. NAT (or NAPT) doesn't add any security (see: NAT traversal) and having different internal vs. external addresses significantly increases the complexity of the system—not just the router but applications as well, which are forced to deal with their public addresses and ports differing from the ones they were assigned.
I'd rather blacklist devices that I believe are somehow secure than blacklist devices that I think are insecure. How would you even keep on top of that in a large company network? Better to just default to hiding all devices behind the NAT
NAT complexity is only marginally more than for a stateful firewall, and is probably lower than for an application firewall. And you still want a stateful firewall in IPv6 networks!
Not needing to do address translation is a large amount of code that you don't need to run to keep IP traffic flowing.
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.
But NAT can protect your internal addresses. If your ISP changes your IPv6 address/prefix, all devices in your network will change their addresses too. This is pain in the ass that can be alleviated by NAT.
You can use link-local addresses for that. There addresses are only available inside the local network and are never routed. When you use IPv6 your interfaces have multiple addresses, at least one external and one link-local.
You can. I've seen sites use it because they didn't have an allocation of their own, but they didn't want to rely on their ISP's numbering either. So they used 1:1 NAT between their carrier's space and their ULA space. Like renting a /8 and mapping it to 10/8. Except in v6land it's nowhere near as crazy as it sounds.
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.
You can still have an NAT with IPv6. But ideally you don't, and you just put all traffic through a firewall. You can still block incoming connections or whatever you relied on that NAT for before.
Please DO NOT rely on a NAT for any sort of security. "Getting around" a NAT is so common today that Wikipedia even has a fairly comprehensive article dedicated to it [0].
Whether IPv4 or IPv6 does not negate the need for a firewall at the ingress/egress.
Wouldn't those all apply to a simple stateful firewall too?
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.
> Wouldn't those all apply to a simple stateful firewall too?
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.
In addition to all of the comments mentioning that a firewall accomplishes what you're looking for (and it is almost certainly built into your router) I'm curious as to what exactly you mean by "switching" your office network to IPv6. Are you just saying that you enabled it? Because you'd hit more than a couple speedbumps browsing the web if you completely got rid of IPv4.
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.
Basically all consumer routers block incoming connections by default. It works almost the same as NAT except you can allow the same port on multiple machines in the network now.
> If I'm on IPv6 there is no NAT and it's basically security by obscurity (not really but port scans would take forever)
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)
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.
"We are continuously measuring the availability of IPv6 connectivity among Google users. The graph shows the percentage of users that access Google over IPv6."
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.
The second sentence explicitly tells you what the graph is showing. The first sentence doesn't contradict that, it just seems to provide some context. (?)
According to the linked article there was no wait until about a month ago, except for a short blip at the end of 2019. But now the waiting list is growing rapidly and the wait is increasing by about three quarters of a day per day.
HN doesn't like to hear this, but the shortage crated is artificial, and there also is nothing wrong with NAT.
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.
NAT works for some use cases, not so well for others.
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.
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.
SRV records could work for alternative ports, but those websites wouldn't be able to get Let's Encrypt certificates without talking to the API of their DNS provider. ACME does not allow alternative ports to be used for security reasons, so we'll need a solution for that.
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.
> SRV records could work for alternative ports, but those websites wouldn't be able to get Let's Encrypt certificates without talking to the API of their DNS provider. ACME does not allow alternative ports to be used for security reasons, so we'll need a solution for that.
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.
IPv6 does not make it any easier or any harder to know the number of physical devices behind a firewall. Even if you sat directly in front of the handoff to the ISP with a packet sniffer counting the number of unique sources you'd still get the wrong number. Correlating source tuple with destination tuple and making inference would get you a more accurate number (though still not perfect) but that doesn't care about v4 vs v6.
> 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.
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]
I'm really curious when this will change. In Canada, my home internet provider and cellular provider are both ipv4 only. I've asked about it in the past and the answer seems to constantly be "Meh".
That might actually be another useful case for a NFT, /24 blocks can be traded in real time and when combined with the RPKI can be used as proof of ownership.
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.
Of course you can't sell property that you are renting. Right now mostly unused IPs are being sold off, but in a few years we might see companies optimizing their networks to free up addresses and sell them.
At the General Meeting in November, RIPE proposed some substantial changes to the charging scheme, to be implemented from 2023 (1 year away), and one notable difference is that RIPE is considering charging a fair market value for IPv4 assignments, in addition, to set up and maintenance fees.
On the contrary, assignments continue. Suppose Alice wants to sell a /16 to Bob. The mechanism goes like this: Bob agrees to pay Alice $5 for this address block, Bob writes up paperwork saying why Bob needs a /16, and sends it to RIPE. Alice sends RIPE paperwork saying she doesn't need this /16 any more, and has agreed a deal to sell it to Bob.
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.
I understand how transfers work, but is RIPE really planning to charge $50 per IP or more for transfers? What would they even do with the resulting billions in revenue?
Currently RIPE costs maybe €35M per year to run and does maybe 5000 transfers per year.
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?
No-one really talks about this. Multi-homing tends to revolve around BGP with IPv6, which while is good technically, the actual process of getting an AS outside of RIPE is bonkers (plus, regardless of that you really need to shell out money).
Yep, if you can even get one! Someone posted on r/ipv6 that they tried to get some provider-independent space from ARIN for an SMB client and got rejected. If you can't rely on getting one then you can't make that your standard process at all.
209 comments
[ 2.7 ms ] story [ 132 ms ] threadI'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]
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?
;)
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.
Assuming company valuations continue to inflate, by 2030 $100m goes to any team who manage to agree on a business card design
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.
https://developer.apple.com/support/ipv6/
https://havevirginmediaenabledipv6yet.co.uk/
> Answer: No [crying face emoji]
> We've been asking since March 2010.
Then Virgin bought them.
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.
bold for you to assume we will have active internet for 100 more years /s...
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).
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...
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.
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.)
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.
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.
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.
I'm not sure what this "ton of system administrators that don't understand it" is having difficulty with.
My comment was a response specifically to this.
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.
"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".
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
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.
If this is what you got from my comment, it seems you need to read more closely. I listed specifically what I did learn, pointing out how it was not everything but was enough for setting up a LAN.
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 the freebie Technicollr C1100T that you get with a CenturyLink DSL connection.
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.
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.
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.
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 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's far easier to learn IPv6 from scratch than to learn IPv4, and then also learn the hacks underneath it, it's miserable.
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.
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
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.
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.
I am surprised you say you work has functional IPv6, I know we have not even talked about enabling traffic anywhere for IPv6
Having checked just now I see that github is still IPv4-only.
What's causing the big increase now?
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.
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.
Funny how their site has a handy pop-up definition when you hover over IPv4, but not for LIR.
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...
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.
[1] https://docs.digitalocean.com/products/networking/ipv6/
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.
https://fly.io/blog/32-bit-real-estate/
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.
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.
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.
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:
* http://upnp.org/specs/arch/UPnP-arch-AnnexAIPv6-v1.pdf
* https://en.wikipedia.org/wiki/Port_Control_Protocol
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.
Whether IPv4 or IPv6 does not negate the need for a firewall at the ingress/egress.
[0] https://en.wikipedia.org/wiki/NAT_traversal
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.
But, yeh, I went through the same moment of fear that you did when I first turned on ipv6.
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.
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.
https://www.google.com/intl/en/ipv6/statistics.html
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.
Market prices on the other hand have exploded this year, $50 per address isn't uncommon anymore.
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.
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.
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.
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.
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.
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
[3]: https://www.cs.columbia.edu/~smb/papers/fnat.pdf
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.
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?
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.