Do You Need IPv4 Anymore?
blog.daknob.net
blog.daknob.net
I have a bunch of services that I host from home, and with my previous provider (and country) I had a static IP with all the associated DNS and DMZ stuff to make it work.
I was about 2 days into a VPN rabbit hole when I discovered that Virgin gives out IPV6 AND IPV4 IPs, and that the v6 ones are publically routable! I was able to access my hosted service by plugging in the server and going to it's IPv6 address on my phone. Some quick Cloudflare IPV4 to IPV6 proxying later and I'm up and running as before. Can now access the service from any internet network (even IPV4 ones). No more DMZ, port forwarding, etc. Happy days.
So yes, I moved away from V4 in about an afternoon, no issues.
I'm not sure if the IP is static though. The server has a reserved V4 IP for internal stuff, I hope the router is clever enough to then keep the V6 one also static. With the address space being so large, I guess giving clients entire blocks of addresses that are static is perfectly fine?
WAN: A:B:C:D::1/126
LAN: A:B:110::/48
And no, the LAN subnet isn't in the ULA or link-local space.
In your case it's a static assignment, but otherwise it can be assigned via DHCPv6-PD (when your router asks for a WAN IP using DHCPv6, it also gets told that some prefix like your /48 has been "delegated" to it). The result is the same.
Okay, now it makes sense. I'm not sure how else I expected it to work.
Your "WAN" is a small transit subnet between your router and your ISPs, while the "LAN" is the actual public ip space you will be assigning to your end devices.
>If an address is publicly routable, what's "LAN" about it?
Routable or not, it's LAN because it's in your network behind your router. It's just an identifier.
For IPv4, you will be given <some random IP> on the WAN side and typically you assign 192.168.x.x (or other RFC1918 addresses) to your devices on the LAN side.
For IPv6, you will be given two random IP blocks with similar usage as the IPv4 ones, except that the LAN side is now publicly routable.
Ha! I have an iPhone 15 and when I switch to mobile I get an IPv4-only address! My mobile provider is Verizon. I assume results are going to vary drastically based on region. I feel there are a lot of assertions in this article without any real data to back them up. If it makes any difference, AS6167.
APNIC 34 (2017) presentation on Verizon and IPv6:
* https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_1...
Also, a 2017 presentation on T-Mobile US going IPv6-only:
(* Legacy space doesn't even have that)
The only thing I can see replacing it is if something I'll call "easyip" came around - something even more convenient than ipv4 for networks of under, say a few hundred devices
Only if you’re not the one who’s responsible for designing and managing cidr allocations
Again, the only replacement I can foresee is for an address schema that either doesn't pretend to even attempt global space or has a UUID scheme where network addresses are immutable, globally unique and inviolable.
This would potentially simplify an iot world if the addresses are known, globally unique and static.
You mean like IPv6 ULA? =)
No.
Currently when you get an iot device you usually connect to it through the smartphone, tell it your Wi-Fi hotspot, give it the password and have it go online.
Instead there could be a flow of going to the routers interface, select "scan new qr code" and you add the device that way - more realistically this would be done through the "myspectrum" or equivalent app as the isp usually issues the modem/hotspot for the majority of consumers.
A number of things would have to change to make that possible but it's a much easier setup flow and it likely requires less complex software on the device itself.
If you want really simple solution on device itself, just let it NDP for router info and drop any incoming SYN that's not already in the conntrack table or part of the ULA space. Boom - done.
(The only answer that makes sense here is supporting legacy devices, which will probably be a problem we'll have to deal with for the rest of our lives. Thankfully I don't appear to have any such devices on my network!)
Not that I'm advocating anyone use that particular subnet of fc00::/7 for their local network.
I dual-stack for my internet gateway.
IPv6 networks are simpler. They do many things automatically that have to be entered manually. The big one is don't have to worry about subnet size or subnet masks; all subnets are /64 and effectively infinite. This doesn't matter for home network but it is big advantage for corporate networks.
All I really need is to be able to accommodate IPv6 on the internet side, which I can currently do.
Alas, being on the global namespace means being dependent on your ISP** - what if they renumber or you want to move ISPs? - or going through the bureaucracy of registering your own block. Yes, despite an infinite space you still need to register to avoid fragmentation. That's something I never want to do.
* For example, IPv6 ULAs have a stupid lookup precedence - IPv4 addresses are higher which means ULA can't be used anywhere which is dual stack.
** There are ways around the latter like ULAs (see above) or using a local DNS (more mess if it fails, assuming everything supports this), or NPT - which would work, but again, the community hates anything that reminds of NAT even when it's totally stateless, so this is little documented. I don't think going against the entire community is a worthwhile endeavor. This should also limit your choice of routers since IIRC not everything supports this.
Not necessarily: as IPv6 becomes more and more mainstream (Google is saying 50% traffic), the need for IPv4 will become less, and so it may be relegated to 'legacy' status and a secondary consideration.
IPv6 from your ISP, fine, but once internal IPv6 is overly complex and unnecessary. Despite the claim to the contrary NAT is a feature, not bug.
The future for IPv6 is that Firewalls/Routers will handle IPv6 for the public addressees, then NAT to internal IPv4's.
How would this IPv4 internal host (say 192.168.1.10) send a packet destined to 2001:db8::1? You can't stick a 128-bit IPv6 address into your IPv4 packet - there are only 32 bits available for the destination address inside its header.
NAT is not magic, it cannot extract a 128-bit number out of your 32-bit number.
For your education:
I have deployed NAT64 in multiple networks before.
NAT64 is used when you have _internal_ IPv6 hosts who want to reach the _external_ IPv4 hosts. In order words, 2001:db8::1 can send something to 198.51.100.1 but not vice versa.
Your proposal is that we use IPv4 _internally_ since you think "internal IPv6 is overly complex" and we should "NAT to internal IPv4's". It doesn't exist since IPv4 is inherently forwards incompatible.
"HN doesn't understand the Internet Protocol" strikes again.
The big advantage is that don't have to worry about subnet size. No deciding how big subnet is going to be, and either making it too small and having to resize or making it too big and wasting space.
IPv6 is more complicated in that supports multiple addresses, but that is an advantage. For internal use, assign ULA addresses and route those over VPNs. For accessing Internet, computers use the ISP assigned addresses. Then assign fixed addresses from hosting provider to load balancers and external servers. This means that only Internet only sees random addresses; they know the provider but that is known with IPv4.
The S in IoT stands for security, of course. But it's going to be a bummer if my IoT devices forces me or my guests out of my network.
IPv6 can be made stateless with SLAAC so DHCP (and any DHCP-related limitations in the router) are completely out of the picture.
Ended up just paying for an IPv4 address to avoid the hassle.
I don't think this is "the year of IPv6" but it might be its decade.
(Though I agree there should be no such distinction, in a real P2P internet)
As a Spectrum Business customer, I wish I could tell you whether or not that was true, but IPv6 isn't available to me at all. I'd happily (okay, not happily, but I'd be willing to do so) pay for an IPv6 block (I currently pay for five static IPv4 addresses -- one of which is eaten by Spectrum's required router, the other eaten by my own router, but that's a different discussion..Grrr!), but I can't even do that -- as it's not even on offer here (NYC).
It seems that there's wide disparity in how/where Spectrum implements its IPv6, so YMMV.
Also IPv6 doesn't actually work reliably. You'll notice it when browsing the web for example, there are periods of 2-3 seconds without IPv6 connectivity. This does not happen on IPv4.
This exception doesn't apply to cities that have their acts together.
"End devices" are not mindless consumers of content like this very naming and article suggest. They are participants in the internet, if you let them. It's a shame kids are growing up today without being able to participate. Most are going to be intellectually stunted by it.
> First of all, let’s start with stating the obvious: most devices will have to talk to legacy services. This post will not argue against this, despite excuses for this decreasing.
> Luckily, IPv6-only devices can still talk to IPv4-only ones, and this is getting easier than ever before.
So... yeah, for that reason I do need to keep using IPv4, at least until either 1) AWS gets its act together; or 2) my employer moves away from AWS (which is very unlikely).
[0] Hyperbole... but probably not that unrealistic.
But as the article points out, it doesn't really matter. You could run a NAT64 service of your own, inside the VPC that AWS gives you. Your own systems can then be IPv6–only, saving you money while still using AWS services that still don't support IPv6.
/sarcasm
With single server, there aren't the networking advantages to using IPv6 internally.
"When" is the only remaining question.
The term is hinging more on the on-demand aspect of "X as a Service".
To use an analogy, IPv4 was like the harddrive of a computer. Removing it rendered the computer inoperable. But nowadays some ISPs are moving towards an IPv6-only core (much like how modern PCs are moving towards solid-state drivers) and IPv4, becoming IPv4aaS, (like the HDD becoming an external HDD) is no longer an integral part of the ISP network.
IPv4aaS simply means that: IPv4 is now removable.
We haven't removed IPv4 because right now, the HDD still contains a lot of stuffs so although unplugging it does not render the computer inoperable, it'll still create a giant headache. That's the on-demand part of IPv4aaS. Doesn't mean it'll be plugged in forever, and don't expect it to be when half of the Internet is already on this analogical SSD.
I’ve been hearing that I need to prepare for IPv6 for the past 20 years, and the benefits are always exceptionally vague or don’t apply to me. I’ll check back in a few years from now.
If my network wasn't prepared with IPv6, I'd had experienced dialup-era speeds for an entire week, but since I was, only half of the Internet were unusable. After some DNS tricks, I was actually able to browse the Internet entirely on IPv6 minus a few websites, Imgur being one of them.
But as the saying goes, ignorance is bliss. ;)
[0]: https://reddit.com/r/ipv6/comments/1as8dvy/is_there_a_way_to...
Also ask nicely, maybe today'll be the day they offer up a v6 route :p
[1] https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out/
$ dig -t AAAA gitlab.com.
gitlab.com. 300 IN AAAA 2606:4700:90:0:f22e:fbec:5bed:a9b9
I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better. They always switch because they have more than 65k servers or to support mobile better. I feel like the people in charge who say that we should all move to IPv6 are the same people that we should that say we should all move QUIC and for the same reason: mobile clients like it better. But it's just not useful on the server side.
You're just relying on a kludge that fucks up addressing which was only invented because there weren't enough addresses.
IPv6 where your home network or backend infrastructure is a transparent glass house is a failure by design. I hope I never get to be a DevOps and support that. Or have IPv6 in my home network. One bad firewall rule or insecure port open, and you get ransomware in your face.
I have met a lot of infrastructure engineers who do that... then never give the people who need access access. So the system just sits and collects dust.
You have users. Acknowledge them. The network shouldn't even be the primary security boundary to begin with.
One bad firewall rule or insecure port open
Firewall !== routing. Nobody said you can't run a border firewall on your home network.
The former sound like a management problem. One call from up above and access will appear.
If you're running a NAT, you're already running something much more complex than that.
It's not rocket science for CPE manufacturers to make "outbound connections only" the default. My home router does just that.
It's such a huge risk to show people what is in my network. It's such a huge risk to the business. It makes no sense to It makes no sense to reveal that. But I suppose telling you is not worth anyone's time, you're just going to say you like it better because you're a mobile developer.
> you're just going to say you like it better because you're a mobile developer.
Not sure what issues you have with mobile developers, but I'm not one, not that it should matter if the argument is sound.
Well... too bad? Do you want security or not?
> neither is my mother, who also has a home network, etc.
If your hypothetical non-technical mother just buys a normal off-the-shelf router (+AP+switch+...) then it'll already have a firewall by default. It's not like end-users are expected to design/implement these things themselves.
NAT is provided by a stateful border firewall.
Are you using NAT on your border device? Gratz, you're running a border firewall on your home network.
In my case, that worked... Sometimes. It really doesn't scale. At all.
Are IP addresses really such sensitive secrets from your POV?
* https://datatracker.ietf.org/doc/html/rfc3041
Updated in 2007:
You also don't have to use the MAC-based addresses on the server either. You can generate a random address and use that for your service.
Or you can regularly generate addresses on the server and update DNS so that the service has a new address every x hours or days. Or you could have the server not have any 'public' addresses, and whenever a new client wants to connect a new address is generated just for that client (with a TTL).
The thing about v6 is … you can just firewall permit like the entire North America block to whatever ports absolutely must be exposed … and just not get any attacking traffic?, at least if the address isn't somehow otherwise discoverable. This isn't possible on v4 (there is no such block, due to the space's fragmentation), and opening up v4 otherwise does expose you to a cesspool of incoming maliciousness. (Though … there are tools for this.)
If there was decent tooling available to me for "here are the IP addresses of the userbase" (e.g., some sort of phone-home system) that could keep the firewalls in sync with reality, I'd be more enthusiastic about it.
But the status quo is largely "security teams want IP firewalling, but don't want to figure out how to actually implement that in a manner that it will realistically work and not waste engineers time filing dozens of security requests".
I have a live feed of packets dropped by my firewall's "deny incoming on WAN by default" rule for fun, and I do occasionally see v6 packets being dropped. They're random addresses under the /48 that was delegated to me but which don't actually belong to any devices. So it doesn't seem to be because someone is actually harvesting IPs from my outgoing traffic, just guesswork. There was also one time where someone was very methodically testing every /64 by incrementing one at a time, with random bytes in the lower half, ie 2001:db8:abcd::$random, 2001:db8:abcd:1::$random, ...
The vast majority of dropped packets are v4 though.
WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Of course. Unless you add rules to allow incoming traffic, say a rule to allow incoming traffic for $LAN_MACHINE1_IP:$PORT/tcp, to cross from WAN to LAN.
>At least with NAT there is a known set of rules regarding how masquerading works, that I can reason about.
The reason the scenario in my previous comment doesn't work has nothing to do with NAT. The reason such a packet would be dropped is because the firewall has a rule to filter bogons on the WAN interface. More generally, your home network firewall will have a default rule to block all incoming traffic on WAN unless explicitly allowed via additional rules, and that applies to both IPv4 and IPv6.
>WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Well if you trust your ISP so much then I assume you just have your firewall turned off always, right?
Yes!
> How does that work?
Stateful firewalling.
It's much simpler than NAT masquerading tables. Just imagine a NAT, but with all address and port mappings being the identity function.
With a default-deny rule in a stateful firewall?
Publicly addressable ≠ publicly reachable.
People also don't seem to have any issues getting hit by ransomware even in a world full of IPv4-only networks and NATs.
Also my network (dual stack) is quite orderly as far as I can tell, thank you very much. I promise I won't ask you for help if that ever changes, if it helps :)
No, it's like you're a fish trying to explain flying to birds.
You don't understand the fundamentals of IPv6 (among other things, in other comments you have revealed that you think IPv6 addresses are MAC-based, think Comcast is a wireless ISP, and aren't aware of stateful firewalls). You have so many misconceptions about IPv6 it's no wonder you hate it.
Please refer to RFC6092 "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service" (Jan 2011)
(Despite the 'recommended' in the title, this is made mandatory by other specifications.)
It does exactly what you ask for: "Proper security is when everything is closed off and inaccessible by default."
Not only that. PCI DSS explicitly requires hiding the network topology from outsiders - even though they cannot connect. So it is either NAT or very short-lived IPv6 addresses, and guess what - for internal audits of who did what, NAT works better.
only if you chose it be.
It doesn't differ from a public routable IPv4 block at all: or you explicitly allow anything being routed to addresses in that block - or not
To be honest, I don't care at all what the site I'm trying to reach does internally after it terminates my connection to them via either IPv4 and IPv6 – just don't pretend that IPv6 is not a thing.
You can NAT IPv6, but it really sounds like you're doing security-by-obscurity, which is less than rigorous. If your servers are properly secured you should be able to publish a complete list of your servers and their IPs on your website and not impact your security at all.
> I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better.
I have. His designs were often... aspirational.
(And I say this not in jest or to be patronizing, I say this as a warning re. your security.)
Whether this applies to NAT is a different question.
Security by obscurity if these servers could be reached if you knew their "real names". In case of NAT, no amount of information will let you access these machines, so it is proper security. It is almost as good as airgap.
With IPv6, knowing addresses of these machines will let you spam them with packets and possibly breach them the second firewall goes down for any reason.
If you have a firewall, then no amount of information will give you access either.
> the second firewall goes down for any reason
Is this like... a thing that you've actually seen happen? Because it really sounds like something that at best happened 20 years ago in a freak accident that will never happen again. If we're allowing equipment to just randomly break to that degree then I get to assume that your NAT will just forward incoming traffic directly to servers.
With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
Well... yeah, if you open a port then the port is open. Since every firewall I've seen - including the ones in cheap garbage home routers - defaults to deny all inbound / allow all outbound, that's not the "default state", that's something you have to specifically add. (And again, same applies to NAT; you can add a port-forward rule, but if you care about security maybe don't.)
> With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
I am precisely concerned with the non-obvious ways. If we're talking about a server environment where every single device on the private subnet is trusted and doesn't get compromised, no ports are forwarded, there is no DMZ, and UPnP is absent or disabled, then it might work, but I would still trust it less than a firewall. In a home or office environment those constraints go out the window (UPnP was quite popular once, IoT ensures there's an endless supply of untrusted devices, and, y'know, Cross-Site Scripting attacks making every device with a browser a potential threat), which is probably why I have the cached heuristic of "don't trust NAT for security".
As someone who have been running IPv6-only services and before that, IPv4-only services, I find this premise to be untrue more or less.
Indeed, my topology is exposed to the internet. But no one has ever exploited that, because IPv6 networks are huge, super huge.
At best a random attacker will be able to tell which network one of your servers is located in, but they cannot find the other networked equipments inside this network. No one in their right mind will bother with your 2^64-sized network like how they did with IPv4.
Around 10 years ago the company I worked for used ipv6 to successfully deal with huge number of ephemeral VMs. It was a great solution.
I saw Fly.io using similar approach for their internal networking so I assume they did it bc they thought it was better as well.
So now you have.
Of course it's great for ephemeral stuff. It's just that most people don't have that problem and it's a huge pain to use it for anything else.
So no, I haven't.
> Of course it's great for ephemeral stuff. It's just that most people don't have that problem
A lot of people run containers these days. It’s not unusual to have endpoints in the tens of thousands or more and there are other considerations that make ipv4 management hard/impossible
And I manage a kubernetes container stack. It's simple, you NAT k8s connections to the outside network, or more likely use an nginx ingress.
I find it hard to believe that "huge" exceeds 65,536, which is how many addresses you get with a /16.
With ipv6 you can just assign every actor a /96 and they get 4 billion IPs to play with
Go talk to the infra people at Comcast. Their infra network is 100% IPv6 and their customers are almost exclusively fixed-location.
> ...I don't see the point of it.
I've personally seen (on more than one occasion) the IT infra mergers of pairs of companies delayed by 12+ months because of the need to renumber (and/or decom because there's just not enough IP address space) machines using RFC 1918 space. RFC 4193 eliminates the need for renumbering.
There are many other reasons for it, but that's one of the ones that tears my heart to pieces each time I have to use multiple VPNs for a year or more while the Great Renumbering is underway.
There are mobile providers so your argument is invalid. Also on the server side they are a famous case of people who need more than 65,000 servers which I covered in my comment.
And renumbering is so, so much easier than switching network stacks. It'd be years to switch network stacks, not only to change over the addresses but also to change over entire business processes and higher swaths of security engineers to keep track of your now much more vulnerable network. It would be a business change, not just a network change.
I'm thinking people connecting iPads and lightbulbs to some CPE, not data centers. And Comcast does that via IPv6, as do many cable or fiber ISPs these days. Many don't assign public IPv4 addresses to their residential customers anymore.
It's that, sure. But it's also Comcast's internal infrastructure devices. Comcast went all-IPv6 on their internal network because they have so very many things that they need to directly address... _internally_... that IPv4 wasn't cutting it anymore.
Even if they didn't provide IPv6 service to their end-users, they'd still be using IPv6 on their internal network.
When was the last time an attacker punched a hole through a firewall device?
Attacks generally start from compromising a user machine (e.g., phishing) or a server (via server-software exploit), installing some malware on already-internal machine, and start probing from there. Not being able to see the internal topology has hindered precisely zero network compromises.
> While we definitely need firewalls and/or packet filters at the network edge, most of today’s attacks work on application-layer, using SQL injection or “Advanced Persistent Threats” like sending an Excel or PDF file with a 0-day exploit to a click-happy user.
* https://blog.ipspace.net/2011/12/is-nat-security-feature.htm...
You may wish to start thinking beyond the castle-and-moat network security model:
* https://www.cloudflare.com/en-ca/learning/access-management/...
---
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4:
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table(s) it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 the address/port rewriting is not done.† Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.‡
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
NAT is not a security feature but a workaround for the lack of IPv4 addresses. The security comes from the state checking.
† It is possible to have private IPv6 addresses using ULA, and then the router/firewall uses NPTv6 to rewrite the prefix (leaving the /64 interface component alone).
‡ Just like with IPv4 (NAT), to allow unsolicited 'new' connections in you have to do do firewall hole punching with (e.g.) UPNP. But by default things are blocked.
T-Mobile US:
* https://www.youtube.com/watch?v=nNMNglk_CvE
Wells Fargo:
* https://www.youtube.com/watch?v=EzTWjNUb4H4
Microsoft
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
* https://www.youtube.com/watch?v=nd0vgU6WbPo
Google:
* https://www.youtube.com/watch?v=hb98hAb5_W8
LinkedIn:
* https://www.youtube.com/watch?v=6ukwR86BClY
Facebook is famously IPv6-only internally (and as of 2016, 60% of user traffic was over IPv6):
* https://www.internetsociety.org/resources/deploy360/2014/cas...
* https://engineering.fb.com/2017/01/17/production-engineering...