I Spent a Week Without Ipv4 (2023)
Key topics
Diving into the world of IPv6, one developer's experiment of ditching IPv4 for a week sparked a lively discussion on the practicalities of adopting the newer protocol. Commenters chimed in with their own experiences and tips, such as using tools to generate unique local prefixes and leveraging SLAAC (Stateless Address Autoconfiguration) to simplify address management. However, some hurdles were also highlighted, like Android's limitation of disabling DHCPv6, which forces some networks to continue supporting IPv4. As the conversation unfolded, it became clear that while IPv6 offers vast address spaces and reduced collision risks, its adoption is still hampered by device and OS limitations.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
20m
Peak period
126
0-12h
Avg / period
20
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 20, 2025 at 1:31 PM EST
13 days ago
Step 01 - 02First comment
Dec 20, 2025 at 1:51 PM EST
20m after posting
Step 02 - 03Peak activity
126 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 25, 2025 at 5:00 AM EST
9 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
- How to ensure there are no collisions in address space? Translates to, how to pick safe addresses, is there a system?
- How do I route from an external network resource to an internal network resource? Translates to, can you provide syntax on how to connect to an smb share? Set up a web service that works without WireGuard or equivalent?
- How does one segment networks, configure a vlan, set up a firewall?
- Open holes through firewalls, point DNS at the address, and it should just work, the joys of actually having public addresses.
- Same way as with IPv4 mostly. The only real difference is because SLAAC assumes a /64 you probably want your networks to be at least that big.
But come on! It is a legitimate question, do you just scramble keys when picking an address?
> the joys of actually having public addresses.
If your ISP gives you a static IPv6. Unfortunately in Germany none of the ISP for private users does (last I checked).
No. Your ISP or tunnel broker gives you a network prefix. Then you configure SLAAC to use that prefix and hand out addresses within it. Job done.
For example, the prefix might look like 2001:470:e904::/48. Your computers can use any addresses you want as long as they start with that prefix. Since you don’t want to manually hand out addresses to every computer, you configure a router to hand out addresses via SLAAC. Your computers will use SLAAC to discover the prefix from the router, then fill in the bottom 64 bits of the address with a random number. They then ask the local network if anyone is using that full address. If not then they are done and have a working address. If somehow someone is using that address then they try again. Servers that want a fixed address will just use their network card’s MAC address (or anything similar, if you want) instead of a random number. The protocol is the same either way.
Notice that this actually gives you some bits of your own to play with, if you want. The full address is 128 bits long. The first 48 were used by the prefix and the bottom 64 by the individual devices, leaving 16 bits in the middle. You could tell your router that the prefix for SLAAC is 2001:470:e904:42::/64, for example, and then use the other subnets for other purposes. Maybe 2001:470:e904:beef::/64 is a special subnet just for your meat freezer and associated monitoring equipment. I don't know, you get to make these things up for yourself. Maybe you manage a corporate network that has a separate VLAN for phones than for normal PCs, and a third VLAN for the guest WiFi. You can give them each a different prefix by embedding the VLAN id into the prefix you advertise via SLAAC.
There’s also DHCPv6 if you want even more control over which addresses are handed out, or you want to subdivide your network even more finely. Or if ISPs ever start handing out smaller prefixes.
> If your ISP gives you a static IPv6. Unfortunately in Germany none of the ISP for private users does (last I checked).
Sure, that’s true. But they probably don’t hand out static addresses for IPv4 either. Not without paying extra, that’s for sure. Either way if you want some static identifier for your computer(s) then the solution is the same: DNS.
Of course if you _are_ running a corporate network with a bunch of VLANS like that then you should actually get your own prefix from your RIR rather than from your ISP. Then you purchase IP transit services from your ISP rather than consumer internet access. You can then advertise your prefix(es) via BGP. Again, this is exactly what you would do for IPv4. Same software, same configuration, just longer addresses. The main advantage of this extra work is that you can keep your addresses static even if you move to an entirely different ISP. You can also use the same addresses over multiple connections to multiple ISPs for better redundancy.
I did give the answer: SLAAC.
> If your ISP gives you a static IPv6. Unfortunately in Germany none of the ISP for private users does (last I checked).
Weird, here in the UK all the ones I've had have given me a static /56. Still, the same answer for that (DDNS) exist as for dynamic IPv4 addresses, you still get the advantage of not having to deal with NAT.
- Easiest is to use your devices’ public (“global unicast”) addresses and allow traffic on your firewall. This is how IP was meant to be used; no NAPT in sight. If you like, you can use ULAs locally and then do NPTv6 for internet-facing access. But I’d recommend against that to start.
Regarding the services, there’s not really anything IPv6 specific. Whether v4 or v6, you shouldn’t be exposing SMB to the internet. Whether v4 or v6, you can put any IP-based service behind Wireguard or any other tunneling solution. There’s nothing specific to v6 there; just use v6 addresses in your config, and you’ll be good to go.
- Basically the same way as with v4; IP (whether v4 or v6) have mostly the same semantics in their layer (layer 3). The only thing is that you’ll want to allow certain kinds of ICMPv6 traffic, assuming your firewall vendor doesn’t do that out of the box. When it comes to VLANs, that’s layer 2, so your layer 3 protocol doesn’t play any role there.
Network segmentation is way more fun with v6 because you have enough address space to make nice hierarchical topologies.
- Use global/public addresses on all your devices (using something like prefix delegation) or use NAT.
- Same as IPv4. Prefix delegation will let your ISP assign you multiple networks, and then most routers will break these up into /64 networks for each of your VLANs.
Use MAC as the key for firewall and monitoring. Then you don't have multiple rules per device.
I have used these on my network and office to move to IPv6-only for Android.
What about lack of DHCPv6 prevents you from using IPv6 on Android?
Works great for me.
It does not "disable" DHCPv6. It does not support DHCPv6. Android (really Lorenzo Colitti) in/famously WONTFIX adding DHCPv6 client support:
* https://issuetracker.google.com/issues/36949085
Of course after over a decade of denying that Android needs some kind of DHCP in IPv6, it seems that Android may finally be getting some kind of solution:
* https://android-developers.googleblog.com/2025/09/simplifyin...
* Via: https://blog.ipspace.net/2025/09/android-dhcpv6-prefix-deleg...
Hopefully, having admitted (?) the error of their ways with being SLAAC-only they'll also add 'regular' DHCPv6 in addition to DHCPv6-PD.
Try connecting to your IPv6-only service on Hotel WiFi -- you usually can't.
It's unfortunate, but IPv6 doesn't really solve any problems for a home user. And I say this as someone that has deployed IPv6 at home before.
So you basically have a cloud server and a domain with a wildcard record, and you then forward IPv4 through IPv6?
I think this somewhat proves my point that IPv6 doesn't solve much for self-hosting. You still need some kind of working IPv4 setup. You are using IPv6 in place of either a reverse proxy or something like tailscale, which I suppose is more convenient.
IPv6 essentially enables "universal internet IDs" for every device, which could streamline a lot of things, but enable a lot of weird surveillance/power balance issues that the cruft of IPv4 is actually incidentally helping guard against.
Again, I'm old enough to remember when e.g. the ISPs were going to try to charge per device in each household.
I don't really see that coming again and if it does you can just do NAT66 just like you can do NAT4.
But, network effects.
But more generally, I think times have changed enough for per device billing not being a viable approach anymore.
Can someone explain why it's ambiguous?
On the subject, IPv6 is one of the strangest inventions on the internet. Its utility and practically are obvious no matter how you look at it except... just one thing.
Network-related things are generally easy to remember and then type from memory: IPv4, domain names, standard port numbers. Back in the day it was the phone numbers, again, easy to remember and dial when you need it. IPv6 is just too long and requires copy/paste all the time. This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades.
Because you don’t know how many zeroes are on each side around the 0001 in the middle.
It can be 2000:0000:1:0000:0000:0000:0000:1 or 2000:0000:0000:0000:0000:1:0000:1 etc.
Your link does not show different addresses from a valid compression, it shows different addresses from an invalid compression.
Conversely, if we compress the expanded addresses in your link, we will get 2 different compressed addresses.
In IPv6 addresses, :: is all zeroes and there's no ambiguity.
In IPv4 you also have 127.257 equal to 127.0.1.1, 123456789 equal to 7.91.205.21, and 010.010.010.010 is a well-know DNS server. This notation is also rejected by most implementations.
google.com: 2607:f8b0:4009:819::200e (5 groups) -> 2607:f8b0:4009:819:0000:0000:0000:200e (3 groups of added zeros)
IPv4 also has a similar, though rarely documented or utilized, shortcut system. Try `ping 1.1` for example. It expands to 1.0.0.1.
"the :1 is short for :0001 basically" is easy enough: you get 2001::0001::0001.
Then "just put that bit at the very end" -- but which bit? If it means the ":0001", then there's two of them and they can't both go at the very end. If not, then it fails to specify which bit. Either way I don't see how these instructions are followable at all, let alone easily.
Posed as a question, disingenuously.
2000::1::1 could be 2000:0000:0000:0000:0001:0000:0000:001, or 2000:00000000:0001:0000:0000:0000:001
There's ambiguity on where to fill in the five groups of 0000 in the second case.
I do get that but I also get 'There are so many I could have all I wanted ... or I could if any of our fiber ISPs would support it, that is'
That becomes 2001:0c2d:4308::/48 instead
After that you just need to remember the subnet number and the host number. If you remember 12.45.67.8 maps to 192.168.13.7 you might have
2001:0c2d:4308:13::7
So subnet “13” and host “7”
It’s not much different to remebering 12.45.67.8>192.168.13.7
I was sort of expecting that this week when I had to transcribe a v6 addy for a WAN-WAN test.
That's when I noticed that Charter (Spectrum) had issued 2603:: for one WAN and 2602:: for the other.
ref: https://bgp.he.net/AS33363#_prefixes6
https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
IPv6 was designed by political process. Go around the room to each engineer and solve for their pet peeve to in turn rally enough support to move the proposal forward. As a bunch of computer people realized how hard politics were they swore never to do it again and made the address size so laughably large that it was "solved" once and for all.
I firmly believe that if they had adopted any other strategy where addresses could be meaningfully understood and worked with by the least skilled network operators, we would have had "IPv6" adoption 10 years ago.
IPv4 was not designed as such, but as an academic exercise. It was an experiment. An experiment that "escape the lab". This is per Vint Cerf:
* https://www.pcmag.com/news/north-america-exhausts-ipv4-addre...
And if you think there wasn't politics in iPv4 you're dead wrong:
* https://spectrum.ieee.org/vint-cerf-mistakes
> IPv6 was designed by political process.
Only if by "political process" you mean a bunch of people got together (physically and virtually) and debated the options and thought what they thought was best.
The criteria for choosing IPng were documented:
* https://datatracker.ietf.org/doc/html/rfc1726
There were a number of proposals, and three finalists, with SIPP being chosen:
* https://datatracker.ietf.org/doc/html/rfc1752
> I firmly believe that if they had adopted any other strategy where addresses could be meaningfully understood and worked with by the least skilled network operators, we would have had "IPv6" adoption 10 years ago.
The primary reason for IPng was >32 bits of address space. The only way to make them shorter is to have fewer bits, which completely defeats the purpose of the endeavour.
> There was no way to move from 32-bits to >32-bits without every network stack of every device element (host, gateway, firewall, application, etc) getting new code. Anything that changed the type and size of sockaddr->sa_family (plus things like new DNS resource record types: A is 32-bit only; see addrinfo->ai_family) would require new code.
That is simply not true. We had one bit left (the reserved/"evil" bit) in IPv4 headers that could have been used to flag that the first N bytes of the payload were an additional IPv4.1 header indicating additional routing information. Packets would continue to transit existing networks and "4.1" capable boxes at edges could read the additional information to make further routing decisions inside of a network. It would have effectively used IPv4 as the core transport network and each connected network (think ASN) having a handful of routed /32s.
Overlay networks are widely deployed and have very minor technical issues.
But that would have only addressed the numbering exhaustion issues. Engineers often get caught in the "well if I am changing this code anyway" trap.
The scheme described by you fails to achieve this goal.
Header processing and alignment were an issue in the 90s when routers repurposed generic components. Now we have modern custom ASICs that can handle IPv4 inside of a GRE tunnel on a VLAN over MPLS at line rate. I have switches in my house that do 780 Gbps.
At the time when it was designed, IPv6 was well designed, much better than IPv4, which was normal after all the experience accumulated while using IPv4 for many years.
The designers of IPv6 have made only one mistake, but it was a huge mistake. The IPv4 address space should have been included in the IPv6 space, allowing transparent intercommunication between any IP addresses, regardless whether they were old IPv4 addresses or new IPv6 addresses.
How would you have implemented it that is different from the NAT64 that actually exists, including shoving all IPv4 addresses into 64:ff9b::/96?
See IPv4-mapped IPv6 addresses from RFC 1884 § 2.4.4 (from 1995):
* https://datatracker.ietf.org/doc/html/rfc1884
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
Great, there's an extra bit in the IPv4 packet header.
I was talking about the data structures in operating systems: are there any extra bits in the sockaddr structure to signal things to applications? If not, an entirely new struct needs to be deployed.
And that doesn't even get into having to deploy new DNS code everywhere.
They didn't use the reserved bit, because there's a field that's already meant for this purpose: the next protocol field. Set that to 0x29 and it indicates that the first bytes of the payload contain a v6 address. Every v4 address has a /48 of v6 space tunnelled to it using this mechanism, and any two v4 addresses can talk v6 between them (including to the entire networks behind those addresses) via it.
If doing basically exactly what you suggested isn't enough to stop you from complaining about v6's designers, how could they possibly have done any better?
And what's wrong with a newer version of a thing solving all the problems people had with it...?
There are more people than IPv4 addresses, so the pigeonhole principle says you can't give every person an IPv4 address, never mind when you add servers as well. Expanding the address space by 6% does absolute nothing to solve anything and I'm confused about why you think it would.
The length of the addresses and the clunky nature of their ASCII representation is absolutely the #1 reason the IPv6 has taken this long. User experience is the most powerful force affecting large scale adoption, and IPv6 has poor UX.
I think the UX is partly fixable by creating less horrible ASCII representation, but this would take a lot of coordination that was hard even back then and is virtually impossible now. If someone told me in 500 years we're still running dual-stack IPv4/IPv6 absolutely unchanged, I'd believe it.
E.g. 2600:15a3:7020:4c51::52/64 is not so bad but 2600:15a3:7020:4c51:3268:b4c4:dd7b:789/64 is a monster by unrelated intent of the client.
"Modern" tooling in the consumer space is pretty dire for IPv6 support too. The best you can reasonably get is an IPv6 on the WAN side and then just IPv4 for everything local. At least from the popular routers I've experienced lately.
Of course I know why. If you turn it on it slightly increases edge case issues as complexity always does. Most people don’t actively need it so nobody notices.
Privacy extensions are worthless because there are just sooooo many ways to fingerprint and track you. If you are not at least using a VPN and a jailed privacy mode browser at a bare minimum, you are toast.
V6 privacy extensions are like the GDPR cookie nonsense: ineffective countermeasures with annoying side effects.
SLAAC sucks too. They should have left assignment up to admins or higher level protocols like with V4. It’s better that way.
"But people can NAT the v4 with another router to hide it!" -> sure, and the same crappy solution works with v6.
"But at least prosumers can replace the ONT via cloning the identifiers and certain hardware" -> also no change with v6.
Randomized addresses do have valid use cases though, particularly when connecting to Wi-Fi networks other than your own when set to randomize the MAC per connection (not just the scanning MAC) as well, but I'm just not really convinced this is a realistic example as framed.
Except if you're using a mobile phone, in which case many telcos only hand out IPv6 addresses to handsets. 2018 NANOG presentation "T-Mobile's journey to IPv6":
* https://www.youtube.com/watch?v=d6oBCYHzrTA
From 2014, "Case Study: T-Mobile US Goes IPv6-only Using 464XLAT":
* https://www.internetsociety.org/deploy360/2014/case-study-t-...
But who cares about mobile phones, right? They're only second-grade devices.
I'm used to cablemodems with static ipv4 for months basically until mac changes
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
A few mos back, I booted an LTE router using a T-Mobile SIM. Within an hour I had two different WAN IPs that belong to AS749 DOD NIC (in 33.79.135.0/24 & 21.140.100.0/24). They were cgnat'd behind TMble's advertised bgp.
They're probably using CG-NAT, though IP changes that often is a bit aggressive.
TMobile uses IPv4 addys in DOD's address space. They do change unexpectedly often.
And yeah. Being DOD IPs, they're cgnat'd behind tmobile's public ASN.
Your website will load faster on cellphones if it supports IPv6. This is because the packets take more direct routes (because they don't go to the central CGNAT server) and because less processing is applied to them. Almost all mobile networks are now IPv6-only, with IPv4 traffic tunneled and CGNATted. Apparently T-Mobile is the rare exception.
A full IPv6 address is made of eight 'hextets' (groups of four hexadecimal digits).
In the example (2000::1::1), we know the first and the last (2000 and 0001), meaning the 0001 in the middle can be in any of 6 places. Even if we ruled out the second and second-to-last as not making sense, that still leaves 4 possibilities.
I was reminded of this 2d ago; I was testing one IPv6 WAN from another. DDNS had failed so I didn't have my usual crutch to lean on.
I guess it could be possible to implement sort of mnemonic phrases for addresses, à la bip-39, but it would be just trading one kind of pain for another.
That is only true for autogenerated/SLAAC IPs. In contrast, manually assigned IPs are often much simpler and easier to remember in IPv6 than in IPv4. I have one common subnet prefix that can be uniformly split to end networks and last number in IP address for such network always end with 0 (and therefore the first device is xxx::1). While in IPv4 i had multiple prefixes, each split non-uniformly based on how many devices was expected to be on that end network, and because most end network prefixes were smaller than /24 (say /26-28), the last number of IP address varies between these networks.
Enable IPv6 on a TP-Link Omada router (ER7212PC) and all internal services are exposed to the outside world as there is no default IPv6 deny-all rule and no IPv6 firewall. I get why some people are nervous.
No free upgrade.
A router routing traffic makes people nervous? Isn't that what it's supposed to do? I'd be annoyed if my router did not pass traffic.
Now, if the ER7212PC was a firewall that would be something else.
I am suggesting the ER7212PC is not a home network device, and thus having the two functions glommed together is an anti-feature in its design.
Expecting that a router not-route IPv6 by default is to misunderstand its purpose.
What firewall do you recommend a typical user power their ER7212PC with?
Except the ER7212PC, nor anything else under the Omada (sub-)brand, is not a consumer / household device. The tagline of Omada is "Networks Empower Business":
* https://www.omadanetworks.com
>> And no, I'm not being pedantic
> You very much are.
Expecting a router to not-route IPv6 is the unreasonable thought.
Then buy a device that does default NATing and other consumer-y if you want that. Don't complain that a generic routing system routes IP—whether IPv4 or IPv6—by default.
If you want a firewall buy a firewall. If you want an all-in-one firewall/gateway/AP/whatever, buy it.
In this particular case the "problem" is not in the device but in purchasing the wrong tool for the job at hand. If you want to haul lumber buy a cargo van or pickup truck, not a VW Golf.
Customer edge routers are expected to contain firewall (see RFC 7084 and RFC 6092).
The ER7212PC, nor anything else in the Omada line, is not for residential consumers which is what RFC 6092—"Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service"—refers to.
And RFC 7084 has two instances of the word "firewall", one (§3.1) in reference to IPv4 NAT:
and the other (§4.5) to tunnelling:AFAICT the ER7212PC is not a "NAT router" but just a "router".
Even some switches have ACL functionality for the IP layer, but they're sold as switches and not as firewalls.
I agree that a consumer all-in-one firewall/gateway/AP/whatever should ("MUST"?) have a default-deny rule on incoming connections.
But the original complaint that kicked off this sub-thread is about a particular device, which is not a consumer device but a more generic routing system and not a "firewall" as such.
- My local ISP (US Internet, soon to be part of T-Mobile Fiber) hasn't enabled it, even though the CEO has said on Reddit for years that it's a priority. Now that they've been acquired who knows if it'll ever happen.
- Linode allows transferring v4 addresses between machines, so if I need to rebuild something I can do so without involving my client who usually has control over DNS. They do not support moving v6 addresses, which means that the only sites I have control over that support v6 are the ones that I control DNS.
Making IPv6 a thing seems like it would be super easy if a couple hours could be spent solving a bunch of dumb lazy problems.
Being a priority doesn't mean it's high priority. It could be a priority, but the lowest ranked one, so other stuff always comes first. :P
T-Mobile wireless US is pretty invested on IPv6, so if they take over the network, they may well push it.
It's "T-Mobile Fiber Home Internet" which looks to be a bunch of local ISPs they've been snatching up, so we'll see what happens. USI's customer service and reliability have been amazing so hopefully that doesn't get screwed up.
It’s very unclear to me why people should be able to deterministic reach out to a specific device on my network. It has no value to me unless I run a service.
Also... the ability for people to deterministically reach out to a specific device on your network is the exact same ability you use to deterministically reach out to specific devices on their networks, just viewed from the opposite side. If the Internet wasn't a place where people could decide to run services on their networks and connect to services that other people ran on their networks, what would the point even be?
IPv6 supports customer-controlled prefix rotation. You can select how often it happens by configuring your router to periodically change its DUID. Of course, your ISP can ignore this signal and always assign the same prefix anyway, but you can hardly blame that on IPv6.
Your v6 subnet prefix is no different than whatever WAN-side v4 your NAT had. "Accidental semi-randomization" of the WAN side IP is not something one could reliably count on. Many ISPs just hand over a static-like IP, that is, even when it's supposed to be random the pool of IPs is so constrained that it's usually the same simply through the IP lease surviving power cycling. And that was before CGNAT.
If your concern is being identifiable through your IP then counting on whatever v4 artifact is the wrong move. Use a VPN with randomised exit nodes.
It’s of some practical real world value that people cannot resolve v4 IPs to individual households with certainty. It’s a shame to lose that value.
As far as I know, the majority of websites (about 70%) do not support IPv6.
If you have a mobile device with data, you’re likely already using it.
You can share that IP address by putting multiple hosts on the same local network. NAT was invented because of lacking enough addresses.
It’s a feature.
If I want to send you a message (an email), I have to go through some other party.
If I want to see what my home security cameras show, I have to go though some other party.
Meanwhile closer to the equator, much less progress was needed to live and let live.
In short, Americans are native tribes. we have plentiful IPV4 and couldnt care less about SLAAC or whatever other complex moon sun and seasonal tide gods, salted codfish and salt mining operations. we just dont need to care about long addresses, they're plentiful here.
Most of the figures I see show 60-70% of the top 100 sites do support it. But maybe that does not reflect your usage.
Why do you need it? Maybe you don’t right now since ipv6 only sites are niche. The most tangible advantage I’ve seen is avoiding CGNAT. Gamers in particular don’t like that because it introduces latency. Services like Xbox live definitely do support ipv6 for this reason.
[1] https://www.cac.gov.cn/2025-05/20/c_1749446498560205.htm
https://stats.labs.apnic.net/ipv6/CN
It was a painful experience of trying to work out if I had misconfigured it, if it was something to do with my opensource router software or if it was my ISP or the end services. I didn't get to the end of working this out and reporting issues and I just gave up. Due to the intermittent nature of the issues I was facing I never managed to get a report of issues my ISP would accept.
So I'll give it some time and give it a try after a year and see if things have improved, but it was definitely not ready for prime time.
192 more comments available on Hacker News