What is the practical significance? (please explain like I'm 5)
Google says:
> The main difference between IPv4 and IPv6 is the address size of IP addresses.
What are the practical implications for internet users and infrastructure maintainers?
Google says:
> The main difference between IPv4 and IPv6 is the address size of IP addresses.
What are the practical implications for internet users and infrastructure maintainers?
For users: the widespread deployment of NAT has eliminated global end-to-end connectivity of the internet. That drives further centralization of the internet, as offering services requires expensive purchases of IPv4 space, big central NAT gateways and makes p2p applications difficult to impossible.
For infrastructure maintainers: the increased address space makes it possible again to allocate addresses as you wish. There's no need to architect your network around IP address scarcity. You can allocate pretty much as many networks as you want, for whatever you want, without worrying it's going to be too small.
While there are ways to poke holes in NAT, it’s not really scalable. Also, you might be behind more than one level of NAT and not even realize it today. eg: When I ask a website for my IP, it shows something different than what my hotspot is assigned… and my hotspot is not reporting an RFC1918 address. This means I am already sharing ports with someone else on the public IPv4 address that the world sees. Also, no http proxy in the middle here.
As for obscurity of addresses, NAT is pretty easily guessed in most scenarios today. IPv6 has far more address space per network making it really hard to scan. That combined with privacy addresses that change constantly is a pretty compelling reason to use IPv6 over IPv4+NAT if what you care about is people not being able to guess your IP.
Right, but you can't do this without punching holes in your firewall, and I assert that's not a desirable tradeoff, at least for consumer use cases. As far as I can tell, you still need an arbiter with a public IP address.
> While there are ways to poke holes in NAT, it’s not really scalable.
Agreed, but this is a relatively infrequent problem. It seems like there is some belief that IPv6 is going to make p2p stuff painless, but for most use case it's still going to require poking holes in something; however, for a few use cases (e.g., 2 game consoles in the same network) it will be significantly better. I definitely agree that there's some benefit to foregoing NAT, but it doesn't seem like it will improve most use cases and it certainly doesn't seem like it will deliver the painless p2p experience that many people expect.
> As for obscurity of addresses, NAT is pretty easily guessed in most scenarios today. IPv6 has far more address space per network making it really hard to scan. That combined with privacy addresses that change constantly is a pretty compelling reason to use IPv6 over IPv4+NAT if what you care about is people not being able to guess your IP.
My concern about obscuring addresses was more about making fingerprinting more difficult (some website can't just see my IP address and associate it with my identity), albeit this isn't a well-founded concern, and it could be mitigated by rotating IP addresses.
That's true, but setting up these firewall rules dynamically is way easier than setting up NAT mappings (for example, UPnP through two different NATs never works properly).
And even for consumer use cases, gateways could provide a way to allow all traffic to a specific destination, as most operating systems should provide a proper firewall. Of course, there is still work to be done, the UI for these firewalls should be made better (for example, allowing an application to request to accept incoming packets, and letting the user choose if it should only for the LAN, or for the whole Internet, etc).
Indeed IPv6 by itself will not make p2p stuff painless, but it's still a better basis than IPv4.
This is ultimately an operating system issue. For most of the history of the web, we've used NAT routers and firewalls as a fig leaf over the operating system issue. What is it? Operating systems are extremely promiscuous about listening for traffic on a multitude of ports. Operating systems are promiscuous about including a vast number of daemons running in the background handling a variety of tasks. Operating systems are promiscuous about running a bunch of daemons that phone home all the time.
All of this stuff is completely opaque to the user. All of it occurs on a default opt-out basis. All of it requires an extraordinary amount of knowledge for the user to feasibly withdraw consent. This is the operating system problem.
In another world, I can envision computers running operating systems which are totally transparent and easily understood by their users. All running services would be opt-in and users would be fully aware of exactly what's happening on their machines. That would be the world where end-to-end internet connectivity is highly desirable.
You can still have a DMZ, servers, and devices directly connected to the internet, but a gateway with a stateful firewall is a wonderful thing and your typical gateway with NAT helps makes things dead simple solving far more problems than it causes.
You're talking about a different problem: How can I extend the concept of my "home network" to the devices that I use and trust regardless of where I am? I'd argue that this is something that suggests that VPN functionality should get built into gateway devices.
Regardless, I don't want scammers in Malaysia port-scanning my 10 year old printer that's never going to get a security update.
Bugs and therefore vulnerabilities are inevitable. The larger your attack surface, the more likely some rando is to find a vulnerability and exploit it. No walls is real convenient up until someone unexpected walks right in and trashes the place.
It's ultimately an issue at every layer, hence "defense in depth". Every layer does its part for security, we don't punt because some other layer ought to handle it.
And so many of these layers exist for legacy reasons, business expedience, and market failure. They don’t actually make things better.
Even then, you have the issue of bugs - not just in the programs themselves, but also in the kernel-mode stack and even in the hardware. As long as something is reachable from the Internet, it will get scanned and assaulted from the Internet - and the lower your attack surface is, the better.
I sort of glossed over this part so now I have a chance to elaborate. Alan Kay has put a ton of thought into this issue [1]. He firmly believes that we can build an operating system and application software with an extremely small footprint (LOC's) so that a single person can understand the whole thing.
Since he gave that talk, we've moved further and further away from Kay's vision. We've made things more and more complex, opaque, centralized, and difficult to change. We've given away our future to big tech companies. Heck, we've even given away the past. We've lost much of the freedom we had back in the 90's, let alone the 70's and 80's when Kay did so much of his work. We're going to have to work incredibly hard just to regain what we've lost.
Do we just go back to the software Middle Ages?
It's like saying, if a person walking around at night gets mugged, it's a "them" problem for not carrying a weapon to defend themselves. Uh, no, let's create an environment where even a completely unprotected child is safe. Oh wait, we already have.
https://www.f5.com/services/resources/white-papers/the-myth-...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
In the IPv4 case you have NAT and a firewall. If you have some software that you want others to connect to (communication, gaming, etc) you have to punch a whole through the firewall (via UPnP, PCP) and then the software has to use a bunch of protocols to figure out what the public IP address of your router is: see STUN, TURN, etc.
See "How NAT traversal works":
* https://tailscale.com/blog/how-nat-traversal-works/
* https://news.ycombinator.com/item?id=30707711 (2022)
* https://news.ycombinator.com/item?id=24241105 (2020)
With IPv6 you just have a firewall, which you punch a hole through when needed (UPnP, PCP) and you're done (because there's no futzing about with determining the network address). When the P2P session is done the whole is closed and you're protected again.
So if you have a 'home network', it cannot be reached from the Internet by default.
Note: you already have a device that's always on the Internet: your mobile phone. Lots of telcos are IPv6-only and you there's not NAT or firewall between it and the Internet.
The two biggest use cases for direct p2p connections are multiplayer games and video calling. Latency is unavoidable if your traffic has to bounce around a third-party
Not at all--end-to-end encryption is still a very desirable property. I certainly don't want a consumer router decrypting my browser traffic even if it is re-encrypting it to send to my device. I'll tolerate HTTP proxies on the server side when I'm administering the proxy and I need layer 7 routing, but I want to avoid it wherever possible.
> The two biggest use cases for direct p2p connections are multiplayer games and video calling.
You still have to punch a hole in your firewall either way. The only advantage ipv6 has is that you can have two hosts listening on the same port (whereas port-forwarding in a NAT context only works for 1-host-per-port).
Tangentially, I was never a big fan of player-hosted games anyway because they tended to be more vulnerable to cheating and the host always had an unfair advantage (or else a dramatic penalty in the case of lag compensation). Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit (although a poorly written game server might still do just that).
What prevents you from putting the same validation logic into the client, thus rejecting malicious packets at the destination?
My point is that IPv6 restoring the end-to-end principle need not jeopardise the - real or perceived - security of multiplayer games.
If “you” refers to the user, then because the game isn’t architected to have a server running next to each client if the server binary is even distributed to users at all.
If “you” refers to the game publisher, then because they aren’t architecting it that way to begin with, because they aren’t thinking about running the server as a security feature.
Moreover, a game developer has incentives to protect its own servers; it has much less incentive to protect its end users. You might argue that it’s end users being hacked is bad for business, but most end users wouldn’t be able to attribute a hack to a particular piece of software or infrastructure if they even know they’re hacked in the first place (consider the rampant insecurity in the consumer router and iot spaces).
Different use cases beget different requirements.
No you don't have to do hole punching.
With IPv4 it is much much harder.
p2p communications can be nice for latency sensitive communications. Sometimes it's faster to communicate from user A to user B directly instead of going from user A to server Z to user B (although, sometimes it's not faster... if latency is important, you really have to try all the accessible paths and use the best one, keeping in mind that paths may have asymmetric latency, so maybe you want A to send to B directly, but B should send to A through an intermediary; and path latency isn't static, so for a long session, if it's important, you need to probe throughout and change thigns around)
But, maybe you don't want your connection to be a full peer capable of receiving as well as initiating connections, you can run a stateful firewall on your end and drop incoming initiations. You'll still benefit from having end-to-end connectivity because it means your ISP can process your packets with basically no state, so there shouldn't be problems with connection state timing out and your connections being dropped without warning. If you run your own stateful firewall, you may still have that problem, but you might have less state required for a stateful firewall instead of a NAT, so maybe you can manage more connections.
This is a job for a firewall. NAT is not a firewall. You can easily filter incoming connections to untrusted devices when using IPv6, with the advantage that when you want to allow a certain kind of traffic in you can do so without messing around with port forwarding or dealing with multiple devices competing for access to standard port numbers on a single public IP address. That's assuming you actually get a public IP address; if you're behind CGNAT then port forwarding isn't even an option, since it would need to be configured on the ISP's side and not just in your router.
If you enable UPnP for automatic port forwarding, as most do, then NAT isn't blocking much of anything. The only difference between NAT with UPnP and IPv6 with no filter preventing incoming connections is in whether devices which open ports but don't set up forwarding can assume that incoming connections probably came from the same local network. However, it's considered poor practice to treat access to the local network as a means of authentication. (Note that with NAT alone if your router receives a packet addressed to your local network's private IP range, and not the routers public IP address, it will forward it unmodified; preventing that is a firewall function, not a NAT function.)
> and I think it's kind of nice that the Internet only knows the address of my router rather than that of my physical machine
If you use IPv6 with privacy extensions enabled then the Internet will only know your /64 network prefix, which is basically the same thing (unique per subscriber and subnet). The rest of the address will be randomly generated and short-lived, unless you choose to assign an additional long-lived address e.g. for a server.
> I'm not sure whether I care if that gateway is doing NAT as well or not? What can I do with a non-NAT-ing gateway?
Doing NAT isn't the problem, requiring NAT is. When the architecture requires NAT devices can't receive incoming connections without port forwarding even when you want them to. We've gotten rather good at working around NAT's limitations (not without cost), but with IPv6 those workarounds are unnecessary. For example, any peer-to-peer multiplayer game, video chat, or file transfer app where both sides are behind NAT depends on third-party servers for NAT traversal. (Note that the fact that this works at all without actually forwarding all data through the third-party servers shows that NAT is not a reliable system for preventing incoming UDP connections: it can be tricked into thinking a connection is already established.) With IPv6 you don't need the third-party servers as the peers can connect to each other directly.
This will never happen. NAT gets replaced with a stateful gateway still doing conntrack (look at OpenWRT...) and p2p works exactly the same. UPNP, port forwarding, STUN are still relevant and work the same... Except IPv6 hexadecimal addresses are a usability disaster and dual stack will forever be a security disaster. Worst technology ever.
Yeah, blocking incoming connections by default is a bad habit and needs to stop. It's fine for untrusted devices or private VLANs which shouldn't be accepting direct incoming connections in the first place (like cheap IoT gadgets), and should probably be additionally filtered to prevent inter-device connections and access to arbitrary Internet sites, but a laptop, phone, or tablet is perfectly capable of deciding on its own whether to accept or reject an incoming connection, and moreover as a mobile device must assume the network could be hostile anyway.
> Except IPv6 hexadecimal addresses are a usability disaster…
How are IPv6 addresses "a usability disaster" when you never see them? Just use DNS like a sane person.
> …and dual stack will forever be a security disaster.
That's a new one to me. How is dual-stack (IPv4+IPv6) any worse security-wise than any other situation where you have multiple "upstream" Internet connections, e.g. for failover or load balancing?
You don't trust "cheap IoT gadgets". I would like to be able to trust any/all my devices. But I don't.
I don't trust M$/Apple/Linux - AND any associated applications people might want to use at home(kodi, plex, screencast, NAS for example) - to be 100% perfect when it comes to "deciding on its own whether to accept or reject an incoming connection".
I see "block by default" as being a layer of security - one bit of defence in depth.
Happy to drop NAT (with it's IP<->port mapping complications) for a straight IPv6 firewall though.
EDIT: concision
If you've ever connected your phone or laptop to a public WiFi network (or for that matter, the cellular data network) then it's been exposed to an environment were there is no extra layer of protection from incoming connections beyond that implemented by the host itself. We generally expect that to work without major security issues. Non-mobile, "appliance"-type devices might need stronger filtering if they weren't designed to be connected directly to the Internet, but that assumption is becoming less common as more devices require authenticated connections rather than trusting the local network.
I would aim for a default block with allowList and agree with you that a non-IoT host using a UPnP-like mechanism (does UPnP cover IPv6 firewall like scenario?) is probably ok.
Ideally I'd like some kind of notification system where I can click "allow" for the firewall. (Maybe the firewall notifies my phone?) I think UPnP as it currently stands is a bit too hands off but can understand not every user wants to deal with this.
And we agree regards mobiles being in a default hostile environment and expecting it to work. But I see that as a matter of fit-for-purpose. I don't trust every computer I have to that level.
The miniupnpd UPnP daemon (used e.g. by OpenWRT) includes code[0] to handle IPv6 "pinhole" requests—not port forwarding, which isn't required for IPv6, but rather just opening a port in the firewall to permit incoming connections to a certain host.
[0] https://github.com/miniupnp/miniupnp/blob/b734f94bdf6ff555a2...
I wish I could upvote you multiple times. This interaction with you has been most enlightening. Thank you.
You get a /48 and each of your networks gets a /64, with hosts picking random 128 bit addresses in each.
The 16 bits in between the two subnets mean you have room to breathe for doing whatever you like. Maybe 64k VLANs, or maybe a hierarchy with semantic meaning. You don’t need an IPAM tool if the addresses have meaning.
My favourite: you can route a /56 to a Docker host and have 256 separate bridged networks, all globally routeable. You never need anything like that, but the open space is refreshing. Like I said: room to breathe.
Actually, if you want to avoid renumbering, don't you want to have that whole block of servers share a subnet?
With IPV6 we can give every device it's own public address, but one major concern is that it could lead to an explosion of insecure devices accessible directly from the internet. Right now if your printer or refrigerator is insecure, it doesn't really matter because it is inaccessible from the internet. The business answer for this is properly configured firewalls and proxy servers, but that's too much for the average home user.
The biggest downside is systems that assume all addresses are IPv4. These could be legacy hardware thats been sitting in a closet chugging along for 20 years, or brand new software where the developer didn't consider v6 as a possibility.
EDIT:
Some specific benefits:
Cheaply hosting stuff from my house.
Easy Direct secure communication without a middle-man.
More competition for hosting companies
Room for more people
Obviously we start to see which routers are "good" home routers shake out as IPv6 adoption picks up, but given current statistics homes are leading IPv6 adoption and it is businesses (with their complex surveillance proxies and IPv4 micro-management practices) that are greatly lagging in adoption curves. (Typical IPv6 graphs show a "bathtub" effect where IPv6 goes up in evenings and weekends as people switch from work devices and networks/VPNs to home devices and home networks.)
Homes are more ready for IPv6 than people want to give credit to. Claiming NATs to be one of the best features of Home IPv4 seems sometimes to just be FUD designed to be anti-IPv6 as much as it is a legitimate concern.
Experts might, but most security isn't a visible property to most users, or at least they won't readily or reliably attribute router vulnerabilities to the router. This in turn means that security will get worse but the market probably won't correct itself, or at least the correction won't manifest as markedly better routers (the consumer router space sucks as it is because the customers aren't usually experts). I don't think this is a compelling reason to avoid an ipv6 transition, but I don't agree with the implication that ipv6 will have positive security benefits.
I also haven't seen one that has IPv6 support without having a default-deny IPv6 firewall.
They may exist, but certainly aren't common.
This gets repeated, but we've already got lots of home IPv6 routers and none of them allow direct access by default. You need to jump through some hoops to enable external access. Nobody wants public access by default and anyone who does it will get noticed and called out very quickly.
So what is the alternative for the average home user?
If you want to talk to Indian web users, you'll probably want to upgrade your servers from Irix version 5.3 to at least 6.2 (but preferably 6.5.22, as it has some security fixes).
Now, you might be saying to yourself "Self, Silicon Graphics went bankrupt in 2006. Where the hell am I going to find install media for Irix 6.5 in the middle of 2022?" The answer to that, my friend, is eBay.
Or maybe you're thinking, "But labcomputer, I don't trust these modern computers with their instruction re-ordering mumbo-jumbo! I want them to interpret the binary as ~~god~~ the compiler intended! And besides, my VAX doubles as a space heater. What am I going to do?"
Well, good news! You're still in luck because you can upgrade your VAX to OpenVMS 5.7 and take advantage of all 128 bits of IPv6 goodness as you gently fall asleep to the roar of your VAXCluster's fans.
Windows users don't need to feel left out, either. Ole Billy-boy's got you covered. You can upgrade to Windows XP (on that powerful new Pentium II you just picked up) to access glorious <blink> tags on IPv6-hosted websites in 256 colors!
I host my own task manager, calendar, media center, document server, google drive alternative, google photos alternative on my home network and can reach it from anywhere. It is all possible with IPv6 without paying a whole lot to other services.
In future, I think IPv6 is going to play a crucial role in next generation of hardware devices and software applications that will bring people back from walled gardens to real Internet. We might finally have something where people host their own data like photos, stories at home securely and then they choose who should access or who should not. I know I am being way too optimistic but a man can dream.
I disagree. Technologies like Tailscale, zerotier and Wireguard mostly exist to secure your private, distributed network. Tailscale has all kinds of measures to circumvent NATs, sure, but the main point is access control, encryption by default and presenting as little an attack surface as possible (by routing everything through Wireguard).
IPv6 doesn't give you that: IPv6 addresses can still easily be spoofed, and ports can still be scanned. And vulternabilities in applications listening on public ports will always exist. VPNs provide you with an additional layer of security.
That's not related to IPv6. If your ISP allows spoofing addresses, then v4/v6 doesn't really make a big difference.
> That's not related to IPv6.
I didn't claim it was. It is, of course, already an issue in IPv4 networks.
OP was claiming that, once everyone uses IPv6, VPN solutions like Tailscale or WireGuard would no longer be needed. I disagreed because one of main features these solutions provide is access control, i.e. which device gets to connect to which device (and which application) in your private network. Not only is this much more cumbersome to achieve with IPv6 alone (as you need to set up appropriate firewall rules manually on each device), the security guarantees afforded by such firewall rules also won't be as strong as 1) IP spoofing cannot be prevented, 2) encryption is not the default, 3) the attack surface is much larger.
> If your ISP allows spoofing addresses
This has nothing to do with one's ISP. The ISP cannot possibly know whether the sender IP address on an IP packet is legitimate or not.
You don't need IPv6 for this. People can just connect to your IPv4 address.
Customers are supposed to get a /56, and the global routing table consists of /32's or at maximum a /48 in regards to subnet length.
This greatly reduces the global routing tables size because aggregation is actually doable, compared to IPv4.
Also, ipv6 has some neat features like duplicate address detection, link-local addressing and Stateless autoconfiguration.
You don't have to futz around with NAT and figuring out how to do connect P2P:
* https://tailscale.com/blog/how-nat-traversal-works/
You have your home router firewall, you punch a hole in it (UPnP, PCP) on an as-needed basis, do your P2P thing. When you're done, the firewall hole is closed.
No magic/fancy protocols trying to figure out what your "real" address is.
Instead of having to chat or talk your some provider's central server, the software on your device can talk directly to the software on the other person's.
Every device will have a unique IPv6 address. This solves a lot of pain regarding port forwarding and NAT — an issue I felt often when trying to play video games or host a Minecraft server when I was younger. It’ll be easier for regular people to access their local networks which could help make it a more mainstream option for people who want to home host services like file syncing or media servers.
You get a unique IP with NAT too, it's just not globally routable which is actually really nice since most people don't want the entire planet to see their internet network and folks running servers and P2P applications are generally capable enough at networking to configure their router to allow communication even with NAT in place.
If IPv6 wants to do away with NAT, what solution does IPv6 offer for preventing device enumeration and tracking?
It is really amazing how people on the internet will call you stupid back when you were a kid when it is completelybout of your control.
And no, some services services are a serious pita to configure with NAT even if you know what you're doing. That's also assuming you're not NATed by your ISP and can bind external ports in the first place and that's not a given.
I know we'll all have to move to from IPv4 eventually, but I can't help hoping that by the time that comes we'll have moved on to IPv7 or at least IPv6SE or something that addresses all the issues that have hurt IPv6 adoption.
Sure, if you are speaking about core routers, they don’t care about state. But for homes and offices, traffic direction matters for security.
Practically all of this is still very unlikely, but at least it is a step in the right direction.
There are technical implications on routing and "what is on the internet" vs "connected to the internet" (the difference between having an address vs a NAT gateway for access).
But for India specifically, the difference is more political & specifically for the internal cloud infra land.
IPv4 was "sold & bought" during the era when US and Europe controlled who got how much.
See the xkcd for an idea of the distribution - https://xkcd.com/195/
If you are a up&coming cloud provider in India, you definitely have a scarcity of ipv4 addresses you can hand out to your customers - you can hand out ipv6 addresses no problem, but if people's devices are on ipv4, then this is behind the scenes and needs a fair amount of complexity.
You can do several tricks on the hosting side with DNS and SNI (so thousands of domain names can map to a group of 10-15 IP addresses and the loadbalancer can use the SNI to route the connections to the right internal ipv6).
So IPv6 adoption for cellphones for instance is not really important for the clients on phones, but it really matters if you want to build out a cloud infra stack hosted in India by a provider (like Reliance) who doesn't own enough ipv4 ranges to scale up things.
What's the Google IPv4 DNS? 8.8.8.8. It's beautiful enough to be a decoration to frame and hang above a fireplace.
What's the Google IPv6 DNS? Heck if I can remember, it has some 4's, 6's, 8's, 0's, 2's, and some colons and double-colons liberally sprinkled like a salt shaker that had its cap fall off as you were shaking it.
I'm basically a walking DNS server of the company I work at, I know all the IPv4 addresses of pretty much every machine, and I couldn't do that with IPv6. I also know all the IPv4 addresses of every single IOT device in my home.
It's really no wonder that the world is very slow to transition to IPv6.