The graph is interesting when you zoom in, much more IPv6 use over the holiday period and also recently during the period of lockdown measures. I would guess the majority of IPv6 traffic comes from devices on 4G networks. More devices are on 4G when visiting family and friends over the Christmas period and when working remotely.
It's not just 4G. It's consumer networking in general, which isn't held back by legacy enterprise networking equipment. When your residential ISP turns on IPv6 for their network, they also tend to turn on IPv6 for the modem+router combo devices they lease to run your LAN. Or if you're the kind of power user that buys your own router, it's almost certainly new enough to support IPv6.
Yes, tonnes of benefits. If you've ever been through a merger, you'll know the pain of dealing with getting the everything working when merging networks. That issue doesn't exist with IPv6 to anywhere near the degree because you don't have overlapping RFC1918 space to deal with. IPAM with IPv4 is a massive pain in the backside once you get up to a certain scale, even if you're allocating from 10/8. If you have multiple DCs, you're in for a world of pain. $WORK is having to use internal NATting for some stuff due to us running low on RFC1918 space, but guess what: even that doesn't quite work because there's a lot of software used in DCs that doesn't play at all nice with NAT.
> IPAM with IPv4 is a massive pain in the backside once you get up to a certain scale, even if you're allocating from 10/8.
Comcast (an US cable ISP) starting deploying IPv6 because they have so many CPE devices that they are out of IPv4 addresses to do management on them. Story from 2010:
It's also why Apple mandated at some points that iOS apps had to work on IPv6-only networks: it was a requirement from mobile phone companies, as IPv4 addresses are getting scarce, and mobile telcos don't want to shell out cash, so they use IPv6 on phones and do NAT64.
Well - you may have overlapping RFC 4193, but if your network engineers have done their job well, you are randomly choosing from a big honking FD/8 address space, and the odds of a collision are statistically very unlikely.
Exactly - the engineers who authored RFC 4193 were super familiar with the problems of RFC 1918 space - and so they were super, super clear on exactly how you needed to allocate space from the FD/8 network. The details are very clear, and the RFC is an awesome read - but the net-net is you can generate a /48 - which means you have 2^16 sub-networks to work with (each subnetwork having effectively unlimited number of hosts allowed on it) - and you can connect with 1,000 other companies that have done the same thing, and there is only a 4.54*10^-07 chance of collision.
I know IPv6 network engineers despise RFC 4193 - but, it offers extraordinary flexibility around addressing - particularly if you have large networks that you want full control over. At my last gig, we deployed over 25 million nodes in RFC 4193 space, and it worked like a charm.
The idea that NAT is in any way related to security needs so badly to die. You don't need NAT for a firewall or access control. NAT is a hack to stretch IPv4 and that's it.
Nearly all security intrusions today are "pulled" in anyway via the web, e-mail, update channels, etc., or are injected by human beings via large scale or targeted phishing.
I did netsec for a while and during my tenure all the incidents we had were caused by phishing of one form or another.
Once you are inside the network, any tiny bit of defense in depth supplied by NAT becomes irrelevant.
Yes. It offers better scalability! E.g. at my university, our institute has its own IPv4 /24. That means a maximum of ~253 or so devices. We have exhausted that number and for every new client, an old one has to go. Now with a /64 this would be no problem at all.
To mitigate this the IT department is currently using VLAN-tagging for some of the devices. But it gets convoluted. And the more convoluted it gets, the higher is the chance for misconfiguration, errors, and security issues. Yet, they don't want to make the switch to IPv6 already.
In IPv4-land, it's not an 'internal network' if every device must have an externally routable address - if it is required, IPv6 has an obvious advantage.
In the requested scenario (internal Enterprise network), the proper comparison should involved IPv4's 16 million private addresses; I can't see any practical advantage to IPv6 there.
It's an internal network if it's inside your networking perimeter. The type of addresses you use on it are irrelevant to that.
Most enterprise networks need to be routed to other networks -- either other networks inside the enterprise, networks inside other enterprises or the internet. To make that work sanely all of the networks involved need to use address ranges that don't overlap. RFC1918 is pretty much the definition of overlap, and using it makes things way more complicated than they would otherwise be.
It's fine for IPv6 engineers to want to make everything directly routable, but in IPv4 the difference still matters, and therefore that's the scenario we need to compare against.
The IPv6 enterprise argument is 'You might one day have to renumber some devices because some other enterprise might have set up overlapping addresses, therefore you definitely have to renumber everything now, and oh, every time the ISP decides they don't like you, because private addresses are icky'. Obviously that's a hard sell.
> The IPv6 enterprise argument is 'You might one day have to renumber some devices because some other enterprise might have set up overlapping addresses, therefore you definitely have to renumber everything now, and oh, every time the ISP decides they don't like you, because private addresses are icky'. Obviously that's a hard sell.
If you’re an enterprise you would just get your own IPv6 block assignment. It’s not like they’re expensive or hard to get hold of.
Companies already buy and manage domains, this is no different. Using a domain you don’t own is just plain stupid, same applies to IPv6 ranges.
Or you could just say screw it, and use RFC4193, and then all you need to ever worry about is prefix remapping at a few key touch points. Particularly if you don't care about external routing in the first place.
16 million is way too few because of collisions and the birthday paradox. Even with a tiny corporate network, you are likely to connect to other companies’ networks, and, with private addresses, no one coordinates allocations. Collisions are quite likely.
Also, the major players probably have more than 16 million devices, especially if you could VMs.
Every sane large internal network is segmented. I doubt all the "more than 16 million devices" need to talk to every other device. The IPv4 limit is an annoyance, but not a big one for the typical internal networks.
When my internal network connects, via any non-NATed means, to a vendor’s internal network, there is a chance that my addresses conflict with theirs. If the vendors have even a few tens of clients, this risk is quite high.
My parent's BT internet connection got upgraded in the last few months and they were provided a new BT Hub 2 with IPv4/IPv6 enabled. They live in a moderately rural village in the UK.
It is very different week days vs weekends too. Mobile connectivity is part of the answer, especially in the US - but more over businesses tend to have crappy network connectivity which is perversely small-C conservative and that means lots of them are still doing IPv4 even when that's directly contrary to their own needs.
Corporate networks tend to have a lot of local policy, and so that's a maintenance burden that probably nobody is paying for so it's just a growing debt for the organisation. Even if every policy was excellent when it was deployed many of them probably hurt by now. At home that stuff tends to get flushed periodically but medium-large businesses have processes to preserve the status quo. The same underlying mechanism that prefers to terminate the 25 year secretary who "made fuss" about a VP putting his hand up her skirt rather than do anything about that senior executive will also prefer to buy $5000 Cisco switches and then disable everything that makes them better than a $50 Costco switch over just buying the Costco switch (let alone using the features of the expensive switch). Change is seen as bad and must be prevented.
This hurts for security a lot too. There's a very good chance that accessing work email from a work laptop in the office is meaningfully less safe than accessing GMail on your phone in a random coffee shop because of such policies.
The highest weekly peak so far is 33.42%, and the troughs are just below 30% at the moment. The last time the weekly peak was ~30% was in December last year.
Maybe I'm weird, but I would assume that less devices are using 4G because of the lockdown, at least in the US are similar countries... most people are staying at home, i.e. on their Wifi, right?
And yet, when I beg my google cloud rep for IPv6 addresses on instances (or on anything that isn’t the load balancer) I get told that it is not on the immediate roadmap.
The cloud providers have pushed back ipv6 adoption so hard imo. At least native ipv6 access.
I know they’ve thrown in some token support and you /can/ make something work; but compared to VPS providers which consistently deliver machines with IPv6 addresses by default- it’s a huge barrier to adoption. You have to really /want/ it, and most people don’t see the value. Unless it’s a backend for an iOS App.
Azure's IPv6 "support" saddens me. It's just painful how minimal their support is.
For one, they NAT all IPv6 traffic.
Let that sink in. Let it percolate. Mull over the fact that the entire purpose of IPv6 is to eliminate NAT, and that it's practically impossible to get an IPv6 NAT-ing network device.
Microsoft must have had to write their own, custom network load balancers to NAT IPv6. It's madness.
Oh, if that's not bad enough, they also hand out ludicrously small /124 ranges of just 16 addresses. Sixteen! Not sixteen trillion or some crazy huge number like that, which is what I've got on my home internet. Sixteen. Six and ten.
But no worries, right? Just allocate more blocks! Bzzt... that would run up against the subscription IP limits with just 100 addresses.
Okay, fine, just because my lab environment needed more than a couple of addresses doesn't mean that everybody is so wasteful with the precious IPv6 address pool. Some people can constrain themselves to just a handful of addresses, and don't have a problem with any of the above.
Except that when Azure finally adds proper, native IPv6 support, whatever work their early adopter customers have done will have to be thrown out and redone. Subnets. DNS addresses. Load balancer rules. NAT rules. Security Groups. Everything will have to be revisited.
We've been experimenting with Azure's IPv6 support at work recently. The fact it uses NAT is insane - though we could tolerate that. Even worse is that the NAT is broken - it doesn't update the ICMPv6 checksum when it rewrites the source/destination address, so the machines on both ends drop all ICMPv6 traffic that passes through Azure.
This is rather bad considering the importance of ICMPv6 in IPv6 (for Path MTU Discovery, for example).
Their support is being rather useless, despite us having to pay for the privilege of reporting a bug in their own infrastructure to them!
Path MTU Discovery is broken in Azure's IPv4 stack as well, which is even more sad. Similarly to you, I had to report to them that their VPN tunnels only send PMTUD in one direction, so you get this wonderful experience where TCP streams with big packets work in one direction, but not the other! With most ACK packets being small, this can take a surprising amount of time to discover and troubleshoot.
Microsoft sells to a lot of crusty enterprises, and I bet a lot of the IT folks there think NAT is for security and refused to use IPv6 if it wasn't NATed. They probably deployed it that way to placate that particular piece of brain dead security cargo cultism.
Azure sucks anyway. Their prices are not good and their management console is horrible.
It's natural because AWS/GCP/etc are against internet style system architectures (=natural IP addressing of your components), they are all about RFC1918 subnets, NAT gateways and L7 proxying. AWS even tells you it's bad architecture (or at least not "Well Architected") to build internet-style systems.
RFC1918 was forced upon the cloud providers only because there weren't enough IPv4 addresses to go around.
If Amazon had started in 1980, they would have simply allocated a /8 for each region and be done with it. No NAT, no gateways, no address translation of any sort. Everything routing to everything else natively.
I also wonder if they're pushing this for lock-in reasons. If they make everyone architect in this way then people need more load balancers, NAT gateways, firewalls, and other complexity, and they charge for all that.
I have noticed that the cloud vendors seem to drag their feet on trivial free features that would undermine the need to use some expensive offering that auto scales to match your credit rating.
For example, Azure Network Security Groups (NSGs) have some glaring omissions that were ignored for years, but have just recently been oh-so-conveniently resolved by Azure Firewall. The old NSGs were free, the firewall costs money, and they also charge per gigabyte of data transferred through it!
Of course, they're recommending that all customers should immediately "uplift" their network architectures to plumb everything through a central firewall.
Big cloud figured out how to monetize the tendency of most programmers to overthink, over-architect, and over-engineer everything. It's as if the authors of the old design patterns book found a way to charge for every singleton and factory. Brilliant!
Bucking this trend and building an "Internet-style architecture" is a competitive advantage. You can save multiple orders of magnitude on your hosting and bandwidth costs.
They had addresses to go around, but not any more.
AWS has 24 regions. If each one had a single /8 block -- which would be the bare-minimum at their scale these days -- they would eat up 10% of all available IPv4 addresses!
Keep in mind that they would still have to "carve up" that /8 for each customer, which is still an overly tight fit. Either everyone gets a bunch of small random pools of addresses (eww), or they have to restrict each region to a small number of customers (bad for business), or provide each customer with tiny subnets (too restrictive for the big fish customers).
With IPv6 this just vanishes. They could have multiple address ranges for each Region, AZ, CDN POP, or whatever. They could have ranges for each service, making firewall rules trivial. They could give each customer a huge prefix that they could still carve up into many subnets.
IIRC, all GCPs IPv6 support is complicated by the fact that they adopted IPv6 from the get-go for internal routing, and layer the user-visible virtual address space on top of it, embedding the user-visible addresses inside the invisible "actual" VM addresses, and that layering strategy allows for something super amazing or fast or something. Something like that.
So then you ask the engineers, "when are you going to adopt IPv6?" And they're like: "What do you mean? We've never NOT used IPv6 for everything important."
On the one had my GCP server's "native" IP address that the OS sees is always an IPv4 address. On the other hand, it's always in the 10.x.x.x/8 range. Everything else is NAT and LB.
Google definitely uses IPv6 internally (ie office WiFi is now using IPv6 only (with the router doing translations to IPv4 if the site doesn’t support IPv6) and afaik most of the servers in the datacenter/clusters are IPv6 only now as they ran out of IPv4 LAN IPs for their clusters.
I just think that there’s little demand on cloud (and tons of other high prior work)
There would be a lot of demand if IPv6 wasn't an "also ran", a "tack on", some checkbox to tick.
Think about how much network complexity would simply vanish if everything used only public routable IPv6 ranges.
No more split DNS. No more NAT gateways. No need for a separate "public IP" and "private IP". No need to carefully "carve up" the 10.x.x.x range to carefully avoid overlaps... even with future business partners. No need to worry about the "size" of subnets or accidentally running out of addresses in the cramped /24 subnets most people allocate.
It goes on and on.
And on.
But none of that is possible in the public cloud, because it is IPv4 first, and 99% IPv4 by default, and if there's IPv6 support, it's broken, or incomplete, or half-arsed.
Looking at the number of unprotected databases (see i.e. https://news.ycombinator.com/item?id=23957510) I think it's good that cloud providers push for gateways etc. in order to restrict access on network level.
(They still could do IPv6 proper - no argument there)
You don't even need an outbound connection. If your router receives a packet with a dest IP set to one of your LAN machines, it'll be routed to that LAN machine. NAT does nothing to stop that, and thus does nothing for (this aspect of) security.
I believe that was only because it was mandated by the federal government as part of procurement process. It’s the same reason there was a half baked posix subsystem in Windows NT. I don’t have citations at the moment to prove my memory.
MS is major pusher of IPv6 in corporate world. Remember that when Windows 2000 was released, major v6 traffic was 6BONE overlay.
Over the next few releases, they worked hard on v6 support, and in fact some issues people had with Vista were caused by NT6 being IPv6-first OS, across all of the MS solutions. MŚ had to go backwards a bit in 6.1, introducing things like v6-over-HTTP tunnels because they found that assuming native v6+ipsec working was too much, even with Teredo.
I began my IT career in 1999 and I saw exactly one network that still had significant amounts of IPX usage, but it was already primarily IPv4.
If any vendor had tried to sell a network product in 2001 that didn't do IPv4, they would have been laughed out of the room.
Nobody is laughing in the faces of vendors in 2020 for selling products that can't do IPv6 properly... or at all.
Nobody will be laughing in 2021. Or 2022... or...
I suspect we'll be having this conversation in 2030 as well, and the same people complaining about the side-effects of carrier grade NAT four levels deep will trot out things like "IPv6 doesn't have security because it's not behind a NAT!"
One of the last pieces of software I remember using IPX exclusively was Westwood Studios "Red Alert 2" released in 2000, along with its expansion pack released in 2001
I mainly remember as Vista dropped IPX support, rendering those games unplayable on LAN's for years until someone developed a UDP patch instead
AWS supports IPv6 almost everywhere. Azure has some support but requires IPv6 NAT for some mysterious reason. Most of the smaller cloud/VPS providers support it: Digital Ocean, Vultr, Linode, OVH, Packet.net, and so on.
The AWS elastic load balancers don’t support IPv6 targets, and since they are used in almost all circumstances means that AWS’ support for IPv6 is practically irrelevant. Plus, it’s not on their road map to fix.
My ISP supports IPv6, and while I can understand why a large organisation would want to use it (especially given the increasing cost and scarcity of IPv4 blocks), I'm still yet to be persuaded of its benefits for home users. I admit that I only have a very cursory understanding of how it works, and perhaps I'm just stuck in my ways, but the scale and complexity seems so extreme compared to IPv4, with no compensating advantages that I can see. So all my devices become globally routable. And? I can already do everything I want and need to do with a single IPv4 address and NAT.
Even just working out what IPv6 devices are on my network and who they're communicating with seems very difficult given the giant address space. I'm slightly ashamed to admit this (feels very anti progress!), but I've blocked all the IPv6 traffic on my home LAN. Devices can still talk to each other, but no IPv6 packets are allowed out to the internet. Everything still works fine. My firewall blocks a few hundred MB per day of IPv6 traffic, and I have no idea what any of it is.
Very happy to be told why I shouldn't do this though.
You've had a few replies so I guess mine will be lost to the aether.
NAT vs Direct addressing is an interesting topic, because we've gotten so used to working around the issues inherent in NAT that we take them as a sort of given. I'll lay them out here:
1) The actual NAT state table in your router is much slower than a simple bit-map firewall lookup. This will show up as a bit of latency on every new connection.
2) The state table can get full. When that happens some connection needs to be evicted. For web technologies this wont look too bad.. Maybe a websocket connection gets closed and re-connects in the background. But if you're streaming something over raw TCP then that's annoying. Basically it makes your internet connection just that little less stable.
3) uPnP exists to try to mitigate the p2p issues with NAT; but does a poor job. -- Take for instance, a video game with VOIP, consoles are notorious for this; centralising and muxing everyones audio is expensive, so it's more useful to help people build peer meshes. So "NAT PUNCHING" is the normal way to go, but of course that doesn't always work, so you have weird tutorials on "how to port forward" when in reality this shouldn't be needed, a stateful firewall would be enough if not for NAT. Some guides even suggest putting your devices in the DMZ with direct port forwards on every port from the internet[!!]
> The state table can get full. When that happens some connection needs to be evicted.
This would be so much more convincing with some numbers to show it actually does happen in reality, especially at a rate that's comparable to other random connection drop-outs.
The most common symptom of this is someone mentioning that their home 'router' regularly needs reboots to keep working well. Excluding memory leaks, it's frequently the state table running out of space and connections going sideways as a result.
This is hard for individuals to see, but put a fair bit of load on a home consumer 'router' and, presuming you can get enough access to it to watch resources, you'll see it run out.
This is one of the things that better home network devices do: have sufficient RAM to handle a big state table, and manage it well.
IPv6 completely sidesteps this by not even needing a state table because no NAT.
> IPv6 completely sidesteps this by not even needing a state table because no NAT.
You may have forgotten that a stateful firewall that tracks inbound and outbound connections still needs memory to store a state table still applies in IPv6.
Now it also needs 8x more memory per entry, as the addresses have gone from 2x 32bit to 2x 128bit.
There's almost certainly more data in each entry than just the IP addresses, so it won't be 8x. NAT also requires a second set of entries to track the NAT session, which further equalizes it.
Makes sense if this happens, but does this actually happen to you? I've heard vague and rather dubious third-hand stories along these lines, but I've never actually encountered a router that needs rebooting to keep working well.
This actually seems bizarre to me now that I think more about it. The routers I've seen allow something like a few hundred thousand established connections over like a ~week. Say 300,000 over 3 days. To exhaust this you'd need to establish on average one new connection every single second (300000/3/24/60/60 ≈ 1), continuously for a week, while also timing out on every single one of them silently. Surely a normal person wouldn't exhaust such a table?
Exhausted NAT state tables is excessively common, evictions happen silently and the assertion that a reboot is required is for other reasons which I think are likely unrelated.
Professionally I run one (two, actually) of those annoying 'always online video games' and state drops in low quality routers is the most common cause of VOIP drop.
It seems like most router firmware has some kind of intelligent sensing software to see if there's a lot of traffic going over a state and then attempting to avoid evicting it. But for VOIP which can sometimes be silent.. or for a person not moving around in a game (and thus sending/recieving very few and very tiny updates) it can be seen.
Now; you want concrete evidence, and unfortunately the kinds of routers most people have (Say, a Virgin Hub 3.0 which is based on the Touchstone TG2492[0]) does not lend itself to being monitored well.
We're in some luck though, as I happen to run something immeasurably more powerful: a PfSense branded NetGate APU2[1]
PfSense absolutely /loves/ letting you know how it feels; and if we assume that I'm a "normal" user, (I have 1 laptop, 1 phone and an apple watch as the only devices on my network right now and I'm just browsing like normal) then we have some measure of how much memory a state table really consumes.
My state table currently contains a mere 170 states (according to iftop), but it's not really hurting my memory:
> 6% of 4030 MiB
Yet, I can see that some states have been forcefully closed, despite having lots of ram available to store too (these statistics were reset yesterday):
state-mismatch 748 0.0/s
In general the state table is very busy:
State Table Total Rate
current entries 152
searches 90040931 338.1/s
inserts 437333 1.6/s
removals 437181 1.6/s
it's worth noting that this device is forcefully configuring itself to hit a max of 403000 states total:
states hard limit 403000
So it's not "memory" like you suggest, but since doing nat translation on every single packet is CPU intensive, states can be dropped if the table can't keep up.
Thanks for sharing. While I have a hard time grasping your usage (why in the world are 3 devices opening 1.6 connections every second?), it's not really relevant as your own data shows state tables don't get exhausted, right? Your table only has 152 entries, which is quite a far cry from exhausting its 403,000 slots.
This is fairly normal and common, especially if you browse without aggressive ad blocking.
I routinely see a single ad impression make over 20-50 connections outbound, and repeatedly close and reopen or randomly open new ones for various reasons, the most common being some form of "anti ad fraud" tracking that repeatedly polls to get an average or median latency, new connections and requests firing on every mouse move, etc.
Would also be entirely unsurprised if phones that had free mobile games and equivalent were polling and sending stuff like location data every minute.
My point is that even when I don't quite run out, something is dropping states.
the Hard limit is just one imposed by the OS, it doesn't seem to matter that I have absurd amounts of free memory, or that the kernel is quite content with loading up hundreds of thousands of states: they still get dropped.
And like I said, my hardware and software platform is many dozens of times more advanced than what most people are using at home.
As for the usage; easily explained by: every single website I open, all of the things that website asks my browser to pull in, every DNS request, every NTP update and every 'ping' to see if the device is online-- counts as a new state.
You're talking about the state-mismatch rate being nonzero, right? I take it as a given that that represents the router dropping states? And you're assuming that must be due to NAT slot exhaustion? If that's what you're saying, it clearly doesn't square with the 152 slots being in use currently (nor does it make sense to me otherwise, given everything I explained above). So either the states are being dropped due to a different reason than you're claiming (I see no link to table exhaustion? it seems like a conjecture), or I'm completely missing a giant piece of the puzzle. Heck, if I take the name at face value, "state mismatch" just sounds like it could be due to a bug in the connection endpoints (or random package spamming from the internet...), rather than anything related to the router at all.
Routers, especially cheap ones, are often equipped with weak CPUs because they aren’t designed to handle heavy processing loads. It’s not like you’re calculating physics or processing 3D animation directly on your router, right?
But network address translation _can_ be a processing-heavy task.
Every single packet that leaves the private network needs to be translated, and every single packet that comes in from the public network needs to be translated. Each individual translation may be simple enough, but with heavy internet use, it all adds up.
Here’s my network activity while browsing the web: https://i.imgur.com/oP8PrX4.png, with one 720p YouTube video open in a tab and a dozen other tabs for various websites, all in the Edge browser.
The top nine processes are using an average of 1,182,149 bytes per second. Every network interface has a maximum transmission unit (MTU), which is the largest size that a data packet can be. Ethernet and Wi-Fi have an MTU of 1,500 bytes.
My computer, doing nothing more than watching a YouTube video, is putting a minimum load on my router of 788 packets per second. That’s assuming the bytes are all divided into 1,500-byte packets, which isn’t the case in real world usage. Somewhere between 1,000 to 3,000 packets per second is more realistic.
The load is worse during bandwidth-intensive activities, such as multiplayer gaming and torrenting. In fact, torrenting is so intensive that it’s the primary cause of NAT issues for home users today. (Open connections to dozens/hundreds of peers, with each connection involving high-speed downloads and uploads.)
And it’s not just one computer on a private network. It is commont to have a smartphone or two, maybe a tablet, smart TV, plus a handful of other devices for the rest of the people sharing the living space. They all need network address translations too!
At the end of the day, we’re talking thousands and thousands of data packets per second, all translated by a weak CPU that can’t keep up. It’s one reason why cheap routers are prone to slowing down.
Notably: while doing that (and opening youtube) my state table grew to just under 400 states. So, youtube needs a lot of connections it seems.
I'm sorry but I still don't get how any of this implies NAT table exhaustion. A few hundred entries is literally 3 orders of magnitude away from a few hundred thousand entries. I don't see the problem.
Anecdotal, but IPv6 saved me a lot of headache recently.
I got a warning about an unauthorized attempted login to my gmail account. They gave me the IP of the offending login. I was able to track that IP not only back to my house, but to a specific device in my house.
It was my NAS, and it was trying to log into gmail to send me an email about a failing drive. Gmail no longer allows username/password logins from third party apps, so I got a warning instead.
Without IPv6, I would have just chalked it up to a misbehaving device and ignored it since it came from my own IP, but because of IPv6, I was able to see it was from the NAS and investigate further.
What complexity? Devices being autoconfigurable without DHCP is less complex. Having no NAT is less complex. Having a public IP is less complex. You just got used to the complexity of IPv4.
Why the hell would you block IPv6. You ARE stuck in your ways. OS vendors consider it necessary on LAN for various functionality.
Devices configuring without DHCP as a network administrator is really hard. There is no longer a single method to be given an IP6 address, and with the auto methods, there is no log either. Only some clients will do dhcpv6 which means you often have two different auto configuring services on a network.
Similarly, to see devices on a network I now have to use neighborhood discovery whice gives me a bunch of IPs, but very hard to figure out which IP is for that raspberrypi next to me. Port scans are much harder.
Public IP address are great, but now a filtering firewall is always required at the edge, since I don't want my printer being reachable on the internet. There isn't a upnp for IP6 to punch wholes automatically either. Ironically P2P over ipv6 is harder because the firewalls are so unforgiving.
Honestly it's reassuring to read this. I do want to understand IPv6 better and I think I am slowly getting to grips with how it all fits together, but the details regularly make me feel as though I need to throw out a lot of what I think I know about networking, and rebuild my entire mental model from the ground up.
Yes, you should throw out a lot of what you know about networking.
Port scanning _should_ be difficult in IPv6. Instead, you should be using DNS and/or multicasting.
Having multiple ways to configure IP addresses _isn’t_ a problem. Modern devices have lots of RAM. They can handle having lots of IP addresses.
Because of how difficult it is to port scan IPv6, as long as you don’t manually allocate a low-entropy address to the printer, it won’t be easy to get to it. Even better, these days you can allocate a unique local address to the printer (RFC 4193, fd00::/8) and eliminate Internet access entirely.
https://tools.ietf.org/html/rfc4193
> Even better, these days you can allocate a unique local address to the printer (RFC 4193, fd00::/8) and eliminate Internet access entirely.
I.e. essentially what we already had with IPv4.
> Because of how difficult it is to port scan IPv6, as long as you don’t manually allocate a low-entropy address to the printer, it won’t be easy to get to it.
Security provided by 'the attackers get bored'....
Security is provided by a firewall. But a lot of IoT botnet stuff comes from people opening inbound connections to their cameras/NASs/etc so they can access them from elsewhere. These are hosts where the network security has been deliberately disabled. The large address space of v6 at least reduces the odds of someone finding the device -- an insecure, unexploited device is better than an insecure exploited one.
You could sort of consider the 64 bit host ID to be a cookie, stored in DNS, that has to be provided by the client to connect to the server. Viewed like this, the IP itself would be considered a layer of security, since it forces the client to know the correct DNS name (or spend a lot of time guessing) to connect.
Right so as I said elsewhere I'll be dropping all packets for incoming connections at the firewall. I was heavily downvoted for that comment... I guess a lot of folk will leave insecure devices open to the world.
IPv4 is from the old days of 1 device, 1 IP address.
RFC 4193 addresses are in addition to the globally routable IP addresses. Your laptop could have both classes of addresses. Your printer could have only one class of address.
Between the ULA and the global addresses, with DHCPv6 and NDP and IPv6 privacy extensions, my laptop currently has 13 IP addresses on its main network adapter. That’s leaving my router and my laptop on default settings, nothing special, no appreciable memory impact.
1. What the hell is DHCP-PD and is it better on or off?
2. What are 6to4, 6in4, 6rd, etc. and should the user care?
3. When should autoconf be stateless vs. stateful? I thought the point of IPv6 was to allow things to be stateless?
4. When should DHCPv6 be enabled vs. disabled? Why the hell is this even a question on some routers if devices are supposed to be "autoconfigurable without DHCP"?
5. What are the more subtle implications of all of the above that are not necessarily mentioned?
6. Give one good reason why in the world every single one of every user's devices should be reachable from anywhere on the internet for even a single moment in time? Why exactly do you feel you should even have a reachable path to my computer, and everyone else's too? Common sense precautions would suggest this shouldn't be possible by default.
Note: I personally don't need responses to all of these. I'm just listing some examples of questions that come up for people configuring it to illustrate why the choice to use IPv6 is hardly as simple as you depict it to be.
These are valid questions regarding complexity, but I also think you're ignoring the complexity of v4. Here are v4 questions for home modems/routers you're just used to: What's bridged mode? What's upnp? What's dmz? What are static IP assignments, wasn't dhcp supposed to manage IP addresses? What's port forwarding? Should I enable "telephony support" and "legacy game support"? What's SIP-ALG?
In both cases for residential use: you're most likely ok with the defaults. And if you want to change something, you have to learn about the tech.
I meant "doubling" the complexity as in IPv6 + IPv4 vs. just IPv4.
If your argument is users can ignore IPv6 complexities as they already do with IPv4, then you've just established the IPv4 complexities can be disregarded by the user... which means you just destroyed your own argument...
I'm not interested in endless debates here though; I feel like I've made my point sufficiently well. If this is an attempt to change my view on the matter I think you're misunderstanding the purpose of the discussion.
Yeah, this is exactly the sort of thing I'm talking about. Lots of additional overhead and work, and — again, speaking as a home user — no apparent benefits for dealing with it all.
I get all the concerns about CGNAT and so on, but that's something for the ISP to figure out. If I get a message one day saying that my connection speed is about to drop 30% because of my insistence on IPv4, I will of course react!
The question for me is not, "why would I block it?" but instead, "why would I enable it?". There needs to be a reason, and right now I'm not seeing it.
I think those have super easy to answer! All up-to-date OS-es support stateless autoconfig now, so forget about DHCPv6. Just disable it and everything will work magically.
6to4, 6in4, 6rd are legacy transition technologies, not needed when you have IPv6, so don't worry.
> Very happy to be told why I shouldn't do this though.
Because your IPv4 traffic goes (or will, in the future, as IPv4 depletes further) through a slow, overprovisioned CGNAT - making IPv4 much slower then IPv6.
That's scaremongering and simply false. Cgnat servers are not necessarily congested. I've been to several isps with cgnat and none of them suffered from congestion.
On a more personal note, if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.
NAT is fundamentally a limited technology that has massive scaling problems that simply do not exist in non-nat networking situations.
The larger the network behind the NAT, the more problems you get. This is also before considerations like the fact NAT breaks 2 way connectivity that is the cornerstone of the design of the internet.
>if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.
The explicit goal and reason IPv6 was created was to make up for the short-comings of IPv4.
The Internet of the 1990s was very different to the Internet of 2020. The widespread surveillance of activity as it exists today was not a consideration back then, nor were there the same security concerns, making it a desirable property to have every device uniquely and globally addressable.
Privacy extensions were then ratified (RFC 4941) after 2007 as a workaround, and firewalls get applied on hosts and gateways to protect against bad actors on the Internet (which are significantly more prevalent today than 20+ years ago).
IPv6 is not a magic bullet. The increase in addressable space is definitely a positive. Pretty much everything else is up for debate, depending on perspective and use case.
I've been dual-stacking networks for over a decade. The easy part[0] is making the network work with both IPv4 and IPv6. The hard part is making everything else work.
[0] Easy is relative. I agree with everything listed in https://news.ycombinator.com/item?id=24059729 as additional sources of complexity and confusion. That's still just the mole hill at the start of the mountain.
> I've been to several isps with cgnat and none of them suffered from congestion.
And I've been on several residential ISPs where IPv4 was unusable during peak netflix hours, likely because people were blindly disabling IPv6 on their devices.
I had to disable IPv6 for Netflix because Netflix has decided that the IPv6 address space I get from Hurricane Electric and the IPv6 address space my wireline ISP hands out are both "VPNs" and blocks them.
With AAAA enabled for *.netflix.com address resolution, I can't watch Netflix. If I actually paid for it, versus getting it included as a perk of T-Mobile, I'd have quit over that. I shouldn't have to fiddle with DNS to watch a service I pay for.
That's not necessarily a problem with nat; anybody with basic networking knowledge can tell you that packets that move through v4 and V6 do not have to follow the same routes. Since there are more users using v4 than V6 it's common for v4 routes to be congested while V6 routes are not.
While NAT works very well for home users, servers still need distinct IPs if they are to be accessible by the public. You can get away with shared IPs with some protocols but sometimes you need a whole IP to yourself.
The advantage of ipv6 for consumers is that many ISPs (especially non american ISPs) don't and can't hand out public IPv4 addresses, due to the lack of remaining IPv4 addresses for them to allocate.
The choice isn't between every device being globally routable (which is easily solved by a firewall WITHOUT NAT) and a single routable address, the choice is between zero public routable addresses, and as many as you need.
He didn't say "all", he said "many". And that is factually right. Many ISPs use DSLite/CGNAT and don't hand out public IPv4 addresses to their customers anymore. Yes, some offer the option to change to a public IPv4, some charge extra money for this feature, and some don't offer it at all!
E.g. my ISP doesn't hand out public IPv4 and you can't order it, unless you change to a business contract. However, my ISP is doing some weird 1:1-NAT, so while I don't get assigned a public IPv4 to my router, I do get assigned a single IPv4 on the CGNAT router that also translates back to my home network.
If your mail server is in AWS, it's not ipv6 that is the problem per se. It's that google has blocked the entire AWS address space. To be fair, you shouldn't be sending email from AWS without going through SES, which has it's own address space and has specific deals for deliverability to all the big mail recipients, like gmail and hotmail.
> Please provide citations if you’re going to speak so factually.
That's fair. I don't really have handy citations. I just know this stuff from working in email deliverability for a long time. I guess you can choose to believe me or not.
In my case, the messages from Gmail's MX suggest the problem was reverse DNS for the EHLO name returning the IPv4, for a connection from the IPv6.
I decided I'd need to configure Exim4 to issue a different EHLO name depending on whether it's connecting over IPv4 or IPv6, and then triple check (with tests) that reverse DNS unambiguously matched in each case.
But as deliverability was the priority, disabling IPv6 seemed lower risk than fiddling with config, seeing it work, then finding out a few weeks later that it introduced another "Google mystery factor". Reviewing that is on the todo list somewhere, very low priority.
A large part of the problem with IPv6 is that most developers and SA's don't have a lot of knowledge about it. This is why everything new is still built with IPv4 in mind, instead of thinking forward to IPv6. I think we could easily blame lack of IPv6 support at cloud providers to lack of knowledge with the developers and SA's they attract.
If more developers and SA's would have access to IPv6 at home, the practical knowledge of how to work with IPv6 would build up more quickly. I would experiment with it more, and build up more knowledge.
Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.
> Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.
You probably know about this already, but there are free IPv6 tunnel brokers you can use to experiment. I previously used Hurricane Electric's tunnel, back before Comcast had native IPv6 support: https://www.tunnelbroker.net/
I previously used Hurricane Electric, too, but Netflix blocked it.
A more practical challenge, Hurricane Electric is a 6in4 tunnel, not layered over TCP nor UDP. Some ISP-provided residential gateway devices (AT&T) don’t support 6in4, not even if you configure your device as a “DMZ” with a public IP address. Also, I frequently find myself in situations with IPv4 NAT and no public IPv4 addresses at all.
The only free IPv6 tunnel service that supported UDP was SixXS, which shut down in 2017.
Nowadays, AT&T supports IPv6 natively, and I went through an annoying amount of effort to bypass their gateway device and control the entire /60 instead of being limited to a /64 and being limited by their NAT.
https://github.com/jaysoffian/eap_proxy
In Japan, consumer Internet is generally IPv6 first since years. For my ISP, I get IPv6 directly but have to configure a provided ipip6 tunnel (or set up my own) to get external IPv4 connectivity.
I host some services at home, mainly targeted at friends and family.
Some are IPv6-only, because it's much easier to manage from my side. I whish I could add an A record for these that pointed to a reserved IP address that would inform clients the service is IPv6-only.
For now, I just don't put any, and browsers just display a generic error. Since some DNS don't answer with IPv6 addresses, the browser couldn't even provide a meaningful error message if it tried to.
Would that be worth an RFC? What IP address should be used?
* I don't know any browser or app that display a special, informative message in that specific case.
* You need a DNS server that answers AAAA record to detect this. Some ISPs do not provide IPv6 connectivity, nor do their DNS servers provide AAAA records. In most places I know, especially when talking about individuals, people use their ISP-provided DNS servers.
For web services, one sad way to handle it is to proxy through Cloudflare. IPv4, IPv6, DNSSEC, TLS at the cost of selling your users out to a budding monopoly.
They've been saying that since I signed up for FIOS, around 2011. I've heard that some FIOS deployments/cities have IPv6, but I don't know which, and it's not mine (Pittsburgh).
To me that's more of an argument for GP's idea. Make it rational for them to care about it. Display a big "You can't visit this website because <ISP name> won't let you. Here's their email:"
Obviously it's not worth it for any website that matters to actually do this, but it's fun to think about.
It's more like the carbon tax. The companies with lazy network admins are "externalising" the cost of their outdated networking on the larger Internet ecosystem.
Pure conjecture as I don't know how they're collecting the location data, but I imagine all Google traffic from China is going through a VPN. So maybe the vast majority of VPNs used by Chinese users are IPv4 only?
I often wonder if we improve the usability of IPv6, like a subset of Ipv6, would it help adoption?
Things like using only numbers and not issuing address with letters. We would still get larger than 64bit of address space, but we dont have to work with the gibberish address.
No. There’s no way around IPv6 addresses being 4 times as long as IPv4 addresses.
I mean, Google DNS is 2001:4860:4860::8888, and in the IPv4 style it would have been:
32.1.72.96.72.96.0.0.0.0.0.0.0.0.136.136
I’m sure if IPv6 were formatted like IPv4, Google would have formatted the address differently, like,
32.1.72.96.72.96.0.0.0.0.0.0.8.8.8.8
The point is there is no way around the address being uncomfortably long, and doing it in a new style with hexadecimal allows both easier manual calculation of the address and an opportunity to truncate all those 0s in manually allocated addresses.
That is exactly what I meant. Instead of 20FA:FF00 etc....
the sets should use Numbers only. It is still within IPv6 spec, we just dont user letters ( Yet )
Where is the Chinese traffic Google is seeing coming from then?
I wonder if anyone is exempt from the Great Firewall? What about senior officials including Xi himself? I’m sure if he asked for unfiltered Internet he’d get it.
That would just lower the number of samples though. For the blocking to drive the v6 percentage down, it would have to happen more often on v6 than on v4.
...which is certainly possible, but just "Google is blocked" alone doesn't cover it.
A large chunk of the US adoption will have been driven by Comcast. They were early adopters and innovators, not least because they have more CPE (cable modems) than are addressable with RFC1918 addresses.
My ISP in the Netherlands (Ziggo) provides me with native IPv6 if I use their supplied router, but forces me onto IPv4 when I use theirs in bridge mode in conjunction with my own router.
It's a kind of carrier grade NAT with 4over6 baked in.
Depending on the version of this they are relying on your modem to perform encap/decap of 4to6, hence when you switch to modem mode or your own router you fall back to what the network truly is... v4.
This is what the knuckle draggers at Virgin Media are contemplating apparently.
In the UK the best option for IPv6 is https://www.aa.net.uk/ but unfortunately for me the DSL speed in my area is pretty bad due to being a few KMs from the exchange.
The alternatives to all of this is to run your own Wireguard instance elsewhere on a v6 network, and tunnel the entire home network to it.
DS-lite gives you a v6-only internet connection. v4 is provisioned as a service over the top of that, using a tunnel between your router and a server inside the ISP. The underlying network is v6, so a router without DS-lite support will only get v6 (which will generate support calls because "your router must support DS-lite" is too complicated for many people to understand).
My guess is that turning on bridge mode also migrates you from the ISP's newer DS-lite service to their older v4-only one. This is unfortunately common in DS-lite deployments; ideally the old service would also have v6 so that you aren't forced to choose between v6 and non-CGNATed v4.
> unfortunately for me the DSL speed in my area is pretty bad due to being a few KMs from the exchange.
For VDSL the distance to an exchange shouldn't matter. The copper runs to a green box in the street, then another newer-looking green box nearby (or in some cases attached) with fibre in it takes the VDSL signal - and only old-school voice line conversations go to the exchange.
So definitely if previous ADSL speeds were poor it's time to check again. If you just meant that as shorthand then no worries, but I've run into way too many people who have the idea that all DSL is the same.
I have the same situation with Vodafone Cable in Germany. I was told it is because of 6-to-4 bridging. A customer on IPv6 must be able to bridge to IPv4 to reach IPv4-only servers, but a customer on IPv4 will probably never encounter IPv6-only servers (except when using an IPv6 testing tool).
I'm not a networking expert, but AFAIK there's nothing stopping them from making their 6-to-4 bridging available to customers with a custom router. However, getting that stuff up and running correctly can be tricky, so it would involve a lot of support burden on the ISP's side. Hence why they don't offer that, they just drop those customers down to a configuration where the customer gets to use well-known protocols only (IPv4 and DHCPv4 over Ethernet).
I'd assume it's because they expect that if you are using your own equipment it could be older and by just forcing v4 it reduces support costs. 100% pure speculation.
I think it's often out of necessity, when you have rapidly increasing numbers of devices (smartphones, IoT) and a large population. This could explain why IPv6 deployment is widespread in Asia. At some point maintaining huge CG-NAT deployments gets more expensive than implementing IPv6...
It's funny, I would have expected the countries who got the lion's share of IPv4 addresses to lag behind in IPv6 adoption, but it's the other way around.
With IPv6 identification (and therefore control) can be down to the person globally, but IPv4 forces NAT's. The inability to label all the things is a feature. NAT's are borders; they prevent fine grained censorship without larger consequences.
$ zcat /proc/config.gz | grep -i ipv6
# CONFIG_IPV6 is not set
That's a little silly, IPv6 privacy addresses are functionally infinite and unless you have a truly huge network behind that NAT then it's not hard to reduce the list of candidates if you have any other information at all.
The V6 privacy addresses are typically only rotated daily but the space is so large that it could be done almost per connection of the stack and router could handle that. Realistic rotation limits are probably every few minutes.
Nearly all modern operating systems use the IPv6 privacy extension, which creates random addresses periodically. Thus the tracking is randomized to the /64 (which is an end customer). This is more or less the same as with IPv4 (without CGNAT)
Is a /64 really an end customer? How common is that?
Both of my ISPs hand out new ISPs hand out new /64 prefixes every so often. One does it every half-hour, the other is comparable but I don't remember. I think they do it to encourage business customers to get more expensive connections, but the effect on my connections is that each device's IP address changes every few minutes, within the ISP's /32, and doesn't repeat in a year... and I do wonder how many IPSs do this.
/64 is a subnet. End customers get /56 to /48 so that they can run multiple subnets. It is, unfortunately, more common than it should be for ISPs to not even give the minimum of that range though.
Changing your prefix every half an hour would be... unusual, at least, although again I wouldn't put it past some ISPs to do that (possibly unintentionally)... but sounds like your prefix might be changing every time you do a DHCPv6-PD request, which makes me wonder if your DHCPv6 client might be generating a new DUID for every request rather than remembering it.
There's a fair few ISPs changing the prefix every day, but this is the first I've heard of anyone changing it every half an hour. If it was common I would've heard a lot of complaining about it by now.
Would you? You haven't heard any complaint from me, and I'm a unix greybeard with a home network and lots of incoming IPv6 connections — all I needed to do was shrink my DNS TTLs, and everything works well. Software's grown resilient to IP address changes nowadays.
Even my incoming rdiff-backup jobs don't raise a noticeable number of errors.
I read most reddit posts that mention IPv6, as well as comments on any blog post, news story etc that makes the rounds. People bitch and moan about every little problem with v6, including blaming it for problems caused by v4 or by completely unrelated causes and with no regard for whether the problem has been fixed 20 years ago or was just imaginary in the first place. They'll even complain about the benefits it gets them.
If 30-minutely prefix changes were common, people would definitely be complaining about it.
...but okay, I won't claim that I catch everything. Can I ask which ISP this is, or at least which country? Perhaps it's common in places that don't have much presence in the English-speaking parts of the internet.
It's nice to hear that it mostly works for you. It should do, but a lot of software is terrible at handling dynamic changes -- it seems to be something that programmers struggle with. The biggest problem should be that long-running connections aren't possible.
Your subnet is no more uniquely identifying than a (non-CGNAT) IPv4 address; if 32 bits identifies which router you're using (whether that's your home, coffee shop or whatever) then a 64 bit identifier doesn't make that router any more identified.
In the typical IPv4 setup, your network gets an IPv4 address. Everything in your network is trivial to group.
In the typical IPv6 setup, your network gets an IPv6 prefix from which client devices use randomized and rotating IPs. Everything in your network is trivial to group.
How long the network-identifying address/prefix is stable is purely an ISP design choice - some keep them as long as possible, others force a change regularly.
What do you mean by " Even if a few really get 32's, it's PR."?
The vast majority of IPv4 connections get an IPv4 IP (= a /32), CGNAT is pretty much only used by providers that don't have another choice and has various downsides for users too.
Obviously, it's temporary. Handing every possible IPv4 user 2^32 IPv6 addresses is a worse than pointless gesture. It's an 10^9 scale changing of the subject.
IPv4 not having enough addresses is why it's valuable. It's impossible to arm band every human with 32b.
EDIT: I'm comment limited for the night. @efzx: Seeing "google" in the same sentience with "does not have anything with tracking" is pretty good stuff.
Not just tagging many ISPs especially FTTH/P don’t randomize IPv6 addresses so all the IP addresses in your town, neighborhood and even building share the same prefixes and they are hierarchical so by just knowing your IP address one could figure out where you live.
I understand that even without efficiencies in routing it makes senses from an operational perspective it doesn’t mean that the privacy implications are quite horrendous.
The faster excuse. yawn Bandwidth (aka time waiting) is like a gas, it expands to fill all available human tolerance.
It's also always there to pretend the major corps care about (insert 15s ad here) it.
If you really measure response time, frame by frame, Windows 3.1 is faster than Windows Billion.
Process improvements in hardware obviate any trivial 40% benchmark. 400%, maybe, lets talk about it.
It's utterly irrelevant compared to what being to tag every item every person ever comes into contact with and the interactions of those items with other items; iterated as many times as desired.
Hardly a prerequisite; a lot of people manage to track individuals using cookies (and many other browser-related things). AFAICT the companies that advertise tracking solutions don't mention IP addresses very much.
IPv6 doesn't have NAT, it has different addresses for global and local scopes, but your OS never translates between these addresses and it doesn't need to keep a table of translations & connections, as you'd have with IPv4 and NAT.
Technically you can do NAT with IPv6, just almost nobody ever does it for the reasons you specify. It's pointless to do NAT when there is no address shortage.
In the early to mid 90's, nobody did NAT with IPv4 either.
Network Prefix Translation or NPT is the equivalent of NAT in IPv6. Let's say you have six WANs (I do in the office) and each has its own IPv6 allocation and BGP and a personal allocation is not available.
Your client machines don't know what is going on at the border, so they can't "choose" a route out unless you turn the lot into routers and use OSPF or something internally.
So NPT. Your router sends flows out over links and rewrites the prefix accordingly for that link. Its a bit horrible and I've decided not to bother yet.
