A thought comes to me: If IPv6 adoption continues to drag along, and AWS/Azure/GCP continue to expand their IP blocks like this, how quickly are we in danger of the cloud providers effectively being the Internet?
[1] https://www.theregister.com/2021/07/26/china_single_stack_ip...
On the server side, in contrast, NAT is winding down. 15 years ago, it was common to have either DMZ-style NAT, or on AWS you had to have NAT (they call it EIP). Nowadays, having a CDN or could-native load-balancer in front of your server is increasingly common. And behind those, that server just don't need a public IP (maybe only a shared outboud NAT for OS updates). That is - if you have a server at all (and not moved to lambda, S3, etc...)
Luckily i had created a reverse ssh tunnel on a vps before leaving.
If they are doing CGNAT further into the infrastructure, how would I even be able to tell at this point? I’m assuming someone would also block ICMP just so it would be less embarrassing, but who knows.
Comcast does generally seem to be moving towards IPv6 at least, which is helpful.
Check the IP on your WAN interface of your modem? I mean, that's how I have always been checking for CGNAT.
I've had this problem in the past with Vodafone, sometimes their AFTR (?) would go down but all ipv6 enabled hosts were still reachable. Only the ipv4 internet was unreachable. It took months for me to find that out, and I still don't know any workaround in case that happens again.
T-Mobile is running IPv6-only using 464 which is vulnerable to AFTR problems like you saw.
HTH,
John
As for the government mandate, also not possible. It would take our major ISPs over a decade to make this work, and the lobbyist would never allow it.
With that said, the DOD did make an interesting decision to move 175 Million IPs recently in routing tables.
You can read a short blog post here: https://brandergroup.net/2021/06/175-million-ipv4-addresses-...
I’ve been saying this for years. Nobody gets it because geeks don’t get ergonomics.
But, yes, generally, you're right. It's been seen from the very beginning as "a big move". If every address A.B.C.D was addressable as 0.A.B.C.D, and we opened up another 255 * 4 billion addresses... we'd have been converted a long time ago. And we'd have been better at actually implementing 'upgrades' because they'd be already done/completed - it wouldn't be a 'monumental task(tm)'.
We don't need every atom in the universe to be able to have 16 public addresses.
in modern (last 10 - 15 ish years) routing table size has been roughly the same for IPv4 and IPv6.
Modern, ISP grade routers have control and forwarding planes seperated between different (usually redundant) hardware components. The control plane is responsible for keeping states of routes (which routes do i recieve from a routing protocol? where is my next hop according to rule XYZ etc). Forwarding plane is responsible for forwarding packets across interfaces.
Route lookups happen in the control plane, but a route lookup is almost never for a dedicated address (especially in IPV6). route lookups happen at the subnet level, and IPV6 has a "standard" subnet size which leaves half of the address space for the subnet itself. (the first /64 subnetmask bits are used for network differentiation, while the other /64 is used to create host specific addresses).
This cuts down on TCAM size considerably, because the router doesn't need to store 128 bits of information per host, but only 65 bits + subnetmask for a very large group of hosts.
besides this, IPv6 has another advantage because fragmenting routes is far more difficult then in IPv4.
Usually, organisations get a /56, the ISP usually handles /48's and RIPE/IANA etc work with /32.
This all keeps the IPV6 routing table far smaller then the IPv4 routing table, which was one of the reasons IPv6 was invented in the first place.
> But, yes, generally, you're right. It's been seen from the very beginning as "a big move". If every address A.B.C.D was addressable as 0.A.B.C.D, and we opened up another 255 * 4 billion addresses... we'd have been converted a long time ago. And we'd have been better at actually implementing 'upgrades' because they'd be already done/completed - it wouldn't be a 'monumental task(tm)'.
would this actually change the amount of "momumentalism" in switching ipv4 for something else? Backwards compatibility with larger address sizes (be it 128 bits, 33 bits or whatever) is not possible because ipv4 stacks can only hadle 32bit address space. Updating those is about as a monumental task as implementing IPV6, considering you would still need two network layer stacks for each device to handle both IPv4 and the "ipv4+" version.
Really? I see 700k routes v4 and 70k v6 routes.
IPv6 will keep routing table size smaller since they can preallocate HUGE subnets to every AS (AS is what people would call an ISP pretty much) so that they only have to split their subnets by geolocation.
what i meant to say was, that in modern routers, IPv4 and IPv6 theoretical routing table size can be the same. There is no difference in terms of maximum routes in the routing table between both protocols.
That has nothing to do with the address being long, but with being compatible.
It would have been much easier to use long addresses that are long hashes of keys. Having only 40 bits means we need two layers of defense in depth to prevent intentional collision: a work function to make the cost substantial (about USD $8M per collision on today’s public cloud) and a single source of truth for lookup that still supports federation. You could punt on all that with 128 or 256 bit addresses.
Yet I did it because I was quite aware that it was very necessary for usability. I have had many people tell me they love that they can type a ZeroTier address.
I would bet anyone that if the addresses had been gigantic we’d have 1/10 the adoption.
Software is first and foremost for people to use. Most of the complexity in software exists for this reason.
Analogy: ZeroTier is to https://plus.codes/ as IPv6 is to mailing addresses. A mailing address is pretty long, but you can use its structure to route the mail efficiently.
Adding 16 or 32 more bits to IPv4 would have been trivial. The existing IPv4 address space becomes 0.0.n.n.n.n or perhaps 0.n.n.n.n.0 if you wanted to give every existing IP 256 addresses to assign while also multiplying the IP space by 256.
Easy, easy, easy.
Problem is, stacking the new protocol on top of IPv4 was never very reliable, so 6to4 is mostly dead now. It would've worked a bit better if the Internet had used 2002::/16 exclusively.
IPv6 was the correct long term approach. You wouldn't want to pick only 48 bits and have to do this again in 20 years.
IPv6 isn't even remotely that big. There are about 10^38 IPv6 addresses, 10^50 atoms on Earth, and 10^80 atoms in the universe.
For an actual conflict, someone would need to be using hostnames that had at least 16 segments, none of which were longer than 4 characters. Putting the burden on someone who wants to use extremely deep hostnames that look like bare IP addresses to type a trailing . on their hostname seems plenty reasonable to me. And if they want to use resolv.conf:search while still typing in 16 segments of a hostname, then that ambiguity could be resolved with a leading period.
I suspect the real reason is people who wanted to be able to write ad-hoc parsers using strchr().
We deal with the ambiguity by making it clear that if you expect to use DNS names that look like IPv4 addresses, you're going to experience the pain of unexpected behavior. I see no reason this general expectation couldn't also have been set for 16-segment hostnames that look like hexadecimal IP addresses.
Alternatively, a full IPv6 address without any '..' abbreviation could have been defined to start with a period. Then there would be no ambiguity.
When I lived in Ireland I only got a public IPv6, my IPv4 was behind CG-NAT. The nerd in me wasn't a fan of that on paper, but in reality I didn't have any issues with it.
I could see ISPs making a quick buck by switching to CG-NAT on IPv4 so they can sell off their IPv4 blocks.
Those IPs being recycled for servers/services doesn't seem too risky, given that they're not typically hosting anything.
Where an IPv4 solution for your clients only needs change-logging on IPbinding-to-client level, the CG-NAT requires you as an ISP to log every outgoing IPv4/port combination with timestamp to client mapping.
Which requires A LOT more storage and much more expensive equipment.
Going rate per IPv4 is up to $40 nowadays, selling of your v4 block might not be cost-efficient.
A good CGNAT implementations have support for static blocks: the subscriber always ends up a a specific ipnumber+portblock combination. (Each subscriber is assigned a specific number of exit ports and this all just logged once during startup so you always know where each subscriber ends up).
Should they run out of their assigned portblock, there are pools which you can borrow from (these need then to be logged who borrowed at what time etc). So all in all there is less logging than when everything was dynamic.
Usually, the law has specific procedures about how this information is requested, what responsibilities are with which party, and how long the response time should be for suchs a request.
When starting (or already being an ISP). You already know what kind of system you need to build that matches all these requirements by law. Simply saying, we do not have the required information wouldn't work because the law has very specific details about the requested information.*
* this is in a european country, so no clue if this is applicable to the US.
As a follow-up the agency, with the right court order, could get all the raw connection records and try to figure it out themselves. But if you don't know the exact time and (source IP, port, destination IP, port) combination you're not going to figure it out in a network with large scale NAT.
(For those who haven't heard the reference https://www.youtube.com/watch?v=FKCmyiljKo0#t=0m40s )
If cgnat keeps scaling, these ip Limiters need to phase out.
This problem would be easy to solve, if only there were some way for a website operator to phase out CGNAT and see a user's 128-bit IP address instead...
The association between IP and user/endpoint is changing, especially with the advent of Apple’s Private Relay, other privacy-protecting proxies, and increased CGNAT.
Website & hosting providers will have to adapt, but right now we’re certainly in a transition state.
Why does each individual connection have to get a port from the global allocator, rather than any of the pooling or hierarchical techniques that high performance memory allocators use?
No issues? So, how are people supposed to be able to access your machine then?
You can use IP6 or a commercial rather than domestic ISP if you really need to do it.
Looking back those 19 years, the availability and state of IPv6 has worsened for me - even though IPv4 shortage was known back then.
It's hard to understand why they don't just push through since there clearly are no real technical problems as witness by those few countries with major providers that actually actively use IPv6 (only).
On the other hand, the IPv4/v6 addresses on my A&A connection geolocate to either London or Bracknell (where their office is), about 400 miles away. I get a lot of pointless ads for things in Surrey that I have no intention of visiting.
With loose enough permissions your browser has a geolocation API that, depending on your device, will be a hell of a lot more accurate (if you have Wi-Fi hardware it can use that to work out where it is relative to the known locations of the SSIDs it can see, or straight-out use GPS).
None of this has anything to do with IPv6 - you give away some location information with your username and profile on this very site, for example.
At auction the larger networks tend to go for less money per IP since there is a smaller market of people who want and can buy them (you have to be approved by ARIN/RIPE/etc. for the allocation size), which drives the price down.
It seems to me like an arbitrage opportunity, since /24 and /23 networks have many more potential buyers. But you have to be approved with a regional registry for the amount of space in order to buy it.
Observing things from the buy side, I suspect that IP space is being brought to auction in a slow but steady trickle so as to maintain upward momentum on prices. The price has approximately doubled in the last year.
This hasn’t been my experience in RIPEland since post IPv4-exhaustion. Is this an ARINism?
Between cloudflare and AWS/Azure/Google most of the Internet is an oligopoly right now.
Interesting how nobody else replied to this part of your comment.
Technology certainly scaling and improving but it's being concentrated in fewer and fewer hands. In the past I could compete with most sophisticated companies, it wasn't unattainable. Barrier to entry is simply too high now. No single or small team of developers and technologists is going to compete with AWS.
A user doesn't really see any difference when traffic gets delivered over IPv6 instead of IPv4, so the scarcity of the global IPv4 space is meaningless compared to the incredibly vast usable size of the global IP space.
So offering any service just on IPv6 makes no sense in 99% of the cases. You can use if for some internal cases, if you can be sure that all your users have IPv6 wherever they happen to be.
If you are cloud provider and cannot offer your customers as many public IPv4 addresses as they want you are out of business.
This is the same as saying no one can own a Disney character because anyone can draw it at home. Or no one owns songs because you can freely transmit them between devices you own.
People still own those things in most jurisdictions around the world.
They need to go after other service provider, not isp. ISP provide CGNAT to facilitate access to ipv4 only service.
IPV6 is in many ways a simpeler protocol then IPv4. for instance, it has a significantly simpeler header then IPv4, it does not duplicate the broadcast behaviour of ethernet but relies on multicast instead.
Some parts of IPv6 are complex (mainly, IPsec) but those are not required to get an operational ipv6 network.
SLAAC & NDP are both significantly more simple then ARP and Automatic addressing under ipv4.
At that time, someone might think that IPv6 with all its faults might have been a good idea after all, but then it will be too late, since "v4 seems to work, all clients behind 2-3-4 layers of NAT, everything tunneled in HTTP/4.5 on a single port outwards to your VPS/VPN".
Not being able to host a game on your home computer, not being able to start a service unless GCP/Azure/AWS allows you to will be the end of the internet as we used to know it. Extra fun for anyone not being american enough to want to be a customer of the big three.
... there won't be any value in them any more.
if the only folks left who can use IPv4 are the hosting providers ("big three" or not), then nobody will be using using IPv4 to contact all the hosted services.
large swaths of users have IPv6 available to them. if there starts being some inconvenience to not having 6, we can be sure adoption will pick up even faster.
and upto that point, it will be SUPER expensive for you to try to get one (or 256), which they can pay since they have monopoly on them, and you only needing one can't.
Don't get me wrong. They say they support it, they have lots of PR that says the support it but in fact as a subscriber they do not.
"my internet provider, cox, does not actually support ipv6" to "I think it is safe to say that ipv6 is dead".
There are much more comprehensive ways to look at ipv6 adoption, e.g. https://www.google.com/intl/en/ipv6/statistics.html
They were purchased recently and maybe there is hope now.
The ability to launch a public-facing, commercial service and pretend like IPv4 never existed and you don't have to worry about it at all? Probably not within our lifetimes.
I'm on cox in southern california, and they rolled out IPv6 some time in the last year or so.