Hacker News Reader

I'm just a programmer with a tiny homelab, and it took me less than a week to understand enough to be able to set up an IPv6 LAN. This included learning enough to be diagnosing and fixing routing/DHCP/RA issues in my router OS and all the LAN machines, implementing prefix-delegation to one of the LAN machines to make it a subrouter for Docker containers, and setting up NAT64 and DNS64 on the router so that the LAN machines could even disable IPv4 entirely. And those latter two were just me flexing because it was a homelab; a regular LAN wouldn't go that far.

I'm not sure what this "ton of system administrators that don't understand it" is having difficulty with.

>it took me less than a week to understand enough to be able to set up an IPv6 LAN.

Don't mean to brag but it took the 12 year old me less than an afternoon (armed with a CISCO book) to understand IPv4 syntax/routing/ARP/DHCP + whatever and roll it out to my 2 computers lan.

The difficulty curve jump from IPv4 to IPv6 is humongous (IPv6 + ancillaries took me 2 days to setup in my home, and that's with a decade of IT experience.)

The issue is there are just so many officially right ways to do the same thing. Even assigning 'static' addresses has 3 official methods. Yes I get why there are so many of them (flexibility!) but it's a lot of stuff to learn and put together.

> Don't mean to brag but it took the 12 year old me less than an afternoon (armed with a CISCO book) to understand IPv4 syntax/routing/ARP/DHCP + whatever and roll it out to my 2 computers lan.

Nothing about that is different for IPv6 for your 2 computer lab.

But did you understand how your LAN differs from the internet, how NAT works, all about port-forwards, firewall traversal and why some apps could traverse firewalls (UDP) and some ones not (TCP)? Or did that come later?

IPv4 has tons of hidden complexities people conveniently forget exist when they lament how terribly inaccessible IPv6 "really" is.

Did you misread the 6s in my comment as 4s? I'm not sure why you're telling me that IPv6 is more complex than IPv4 when my comment said nothing to the contrary.

> I'm not sure what this "ton of system administrators that don't understand it" is having difficulty with.

"It's different" is the primary thing I hear. I'm a network guy and I learned rudimentary v6 in college ten years ago. I'll be the first to admit I don't know as much as I should, but give me a day and a good resource and I can easily be back up to speed.

My boss on the other hand....."man, it's just so complicated, I hope we never change".

Maybe it was easy because it was your home lab. System administrators will have to deal with orders of magnitude more complexity and thousands of devices. Even if their home labs are meticulously IPv6, moving a corporation to IPv6 is a major undertaking. How can they justify the effort if IPv4 still works and costs nothing?

> How can they justify the effort if IPv4 still works and costs nothing?

I believe the problem is that IPv4 is no longer costing nothing. It's gradually getting more sparse, and thus more expensive.

Soon only the major data-centers (AWS, Azure, GCP) will be able to afford IPv4 addresses, and you as an IPv4 only company will be forced to use their platform if you want to continue running IPv4 only.

>>>and a ton of system administrators that doesn't understand it (and for a reason, it's too complicated for nothing).

My comment was a response specifically to this.

Sure, Setting it at home, or in lab is easy.

Now do it across complex collapsed core network with 1000's of devices spanning multiple locations with multiple WAN's of differing types that all have to route together

Where do I get a home router that has just a firewall for IPv6, and NAT for IPv4?

My current home router is a cheap Microtik which does exactly what you describe. I also previously had a low end Ubiquiti EdgeRouter with the same setup as I have now. I am pretty sure the free router my ISP supplies does that as well but I have not had the opportunity to test it out.

I'm using an Ubiquity Edgerouter Pro PoE with exactly this configuration. I'm not saying it's the best product for this purpose, but I have used it in this way for several years now.

My main complaint about the model I have is that you only have hardware switching on the first two ports, making the remaining ports somewhat useless as the CPU isn't fast enough to route more than a few hundred Mb/s.

Well, the only one I have ready access to has that.

It's the freebie Technicollr C1100T that you get with a CenturyLink DSL connection.

Any home router that supports IPv6 would include this.

My fairly recent D-Link DIR-882 supports IPv6, and isn't even able to bring the IPv6 that the ISP modem router provides onto the LAN in any way.

The Zyxel router my ISP issued me does exactly this.

IPv6 isn't all that difficult, insomuch as IPv4 is not basic itself. In fact it's probably easier to teach someone with no prior knowledge IPv6 instead of IPv4. "What's the netmask" isn't a question for user endpoints, it's /64. You can still DHCP, you can still hardcode, but the replacement for ARP can also assign you an IP without having to configure external services to make that happen.

The IPv4 header and the way routers work wouldn't allow for a variable address. The source/destination sit in front of variable length extensions and the actual payload. Not to mention it'd be god awful to implement that kind of thing in non programmable level hardware. You could always implement it as an option header but then you've basically invented "v6 over v4" which is already a thing. Of course there is always NAT which v4 endpoints are already used to so this is a non-problem anyways, I've run v6 only at home for years at this point.

A lot of applications break on it sure but that's because a lot of applications are hardcoded with the assumptions about how big the address is not because the address gets put into a container named "v6" instead of "v4 version 2" by the OS.

> Not to mention it'd be god awful to implement that kind of thing in non programmable level hardware.

Not to disagree with you, but to emphasise this - a lot of stuff in v6 is intentionally easy to implement in hardware. Stuff like the 64/64 address split, fixed-length headers. The only benefit to fixing head length / next header at 40 bytes is to enable zero-knowledge hardware accel.

Essentially similar to people describing one of the benefits to pipelining on the M1 being fixed instruction length - you can pipeline a packet/instruction without parsing it.

For home users and non-professionals, IPv6 is simpler than IPv4. Every device autoconfigs selecting its own address via SLAAC. No DHCP needed. No need to understand NAT and no dealing with subnets.

Especially when mDNS is in the mix and every device gets its own .local domain, which already happens with iOS, macOS and Windows devices (plus Linux with avahi), it is dead simple to have a very reliable local network.

Ditching Ethernet broadcast that hit every single interface on a network when you only wanted to communicate with a single device on a specific protocol is a big win. Getting rid of Subnets by making the smallest possible subnet infinitely large eliminated 90% of network confusion around subnets. Privacy based IP addresses also a nice addition. After working with IPv6 for 10 or so years, you really grew to appreciate what an architectural advantage it has over IPv4. As for deploying it? I dunno - I just plug my Ubuntu laptop into a WiFi Network and it just seems to work. I'm pretty sure the comcast routers I've connected to have had zero configuration beyond what they can pick up connecting to comcast. In the future - people (other than say Network Engineers working for IT) probably won't even discuss things like "IP" addresses.

So, a common home setup is to plug a fancy router behind the ISPs useless modem router.

What happens is, IPv4 works out of the box. IPv6 doesn't work, because the fancy router doesn't get a big enough subnet from the useless ISP modem.

My piece of shit useless ISP modem/router (from Spectrum, one step sideways from Comcast in quality) supports IPv6 out of the box. 0 effort.

Getting it to stay working for an entire week without a reboot? Seems to be impossible. But IPv6 just works.

Yeah. My useless ISP router supports it as well here. But it doesn't work when there's a second router in between. Something to do with Prefix Delegation not working, supposedly. And the ISP router by itself has zero controls for IPv4 DHCP, and so on, so it's absolutely useless by itself.

My ISP just rolled out IPv6 a couple of weeks ago. I was pretty excited until I learned WSL2 doesn’t support IPv6.

> I would have preferred an IPv4 version 2, and extension to the address space of IPv4, possibly in a backward compatible way, so that applications, routers and equipment not built for the new protocol can continue to work, of course considering only a part of the address (e.g. if the network passes trough some old routers, it's not a problem since they only have to look at the most significant part of the address that is in the same place of the IPv4 address) and can ignore the extension.

This gets suggested all the time, but it's a fundamentally broken idea that could never work. What happens when one router uses the "extension" and the next one doesn't? You get a routing loop, so your packets get dropped. This would happen approximately 100% of the time when using this kind of "extension".

> And if you have to choose between two, you will choose the easier one, or the one you know, that is IPv4. A simple extension would have been far more easier to rollout.

Lol no it wouldn't. If you think people are dragging their feet on IPv6, that's nothing to how long it takes them to roll out an "extension" that's even less visible.

>> I would have preferred an IPv4 version 2, and extension to the address space of IPv4, possibly in a backward compatible way

> This gets suggested all the time, but it's a fundamentally broken idea

Agreed. It needs to be 100% backwards compatible, or else it's going to break havoc on the internet.

And there's no such extension which can be made. Otherwise it would have been made by now.

So if you're going to break compatibility anyway, you might do so in a way which is clearly signaled and doesn't allow for the myriad of "undefined" failure modes that a theoretical IPv4.1 is going to have.

I’m having a hard time thinking of what kind of network topology would result in a routing loop. Can you elaborate?

It seems like the first router would have to be forwarding only a subset of a /32 to the second router; if the second router was responsible for the whole /32 (or more), then it would have no reason to send packets back to the first router even if it didn’t know about the extension. But forwarding a subset of a /32 to a router that doesn’t know about the extension is clearly a misconfiguration.

Two different /48s might be on two different sides of the world; the first router has no idea what the full path from it to either of them is (and of course the path shifts dynamically because that's how internet routing works) so it has no idea which paths might have IPv4-only routers on.

If you have to advocate addresses in IPv4-routable blocks (/32s, or I think /30s in practice because of needing a broadcast address etc.) then your protocol doesn't fix the address exhaustion problem and you still have to make a clear distinction between the parts of your network that are running "v4.1" and the parts that are running "v4". You'd end up with something like 6to4/6rd but running that way forever, with no prospect of ever improving, and the IPv4 address space fragmentation issues would get worse and worse. So there's not really any practical advantage over CGNAT.

The only reasonable way I can see to do this, would be to have an IPv4v2 packet within an IPv4v1 packet. So the v4v1 packet is delivered to its endpoint then stripped and the v4v2 packet traverses onwards to its destination.

This doesn't solve the dual-stack issues, as either the endpoint needs both v4v1 and v4v2 stacks, or it needs to be offloaded at the router - essentially re-inventing NAT.

What v6 has done, is essentially say there's no way to do this without breaking things, so we might as well break everything at once. So a lot of things that were optional, hacky bolt-ons in v4 have been adopted properly, because if we're going to add a 2nd stack, we might as well make the effort worth it - because lets face it, we're not going to have another chance to make a 20+ year transition any time soon.

> IPv6 is a disaster. It's too difficult to understand or configure properly, and it's too different from IPv4. There is a ton of software that breaks with IPv6, and a ton of system administrators that doesn't understand it (and for a reason, it's too complicated for nothing).

Now consider other tech that's even more different and how we jumped on it over the last decade. Anything related to mesh / overlay networks is just as complicated in practice and we learned how to use it just fine. People are capable of learning and lots of public traffic already goes over IPv6. And if they cannot learn about IPv6 given all the time we had available... maybe they should be replaced with people who can learn? We managed to move from IPX to IPv4 in the past and that was a bigger change.

> possibly in a backward compatible way

Pre-IPv6 all IP code had 32 bits reserved for addresses. For more addresses, you would need >32 bits.

How do you squeeze >32 bits of data into 32 bit data structures?

You would need to touch every bit of IP code out there to expand the corresponding address filed (e.g., in a struct in_addr)—which is what had to be done for IPv6.

I'd argue that that's in essence what NAT (especially CGNAT) does by abusing the 16 bit port number: extend the 32-bit assessing space to ~48 bits. And it pretty much works just fine for many many use cases.

Because a whole suite of protocols had to be invented:

* https://en.wikipedia.org/wiki/STUN

* https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...

* https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...

See also "NAT Issues when playing games":

* https://support.plume.com/hc/en-us/articles/360035745134-NAT...

Certainly we'd need hole punching protocols (UPnP/PCP) because IPv6 firewalls would be default deny on incoming connections, but the addressing issue introduces a bunch of things on top of that. The fact that these kludges are considered 'normal' and/or 'okay' is kind of sad.

And how do you hole punch through CGNAT? (AFAIK there is no way.)

Everything is being crammed into HTTP/QUIC/whatever because of all of these limitations: what applications could have been designed better if bits flowed more freely? (SCTP and DCCP died because of limited middleware network boxes.)

As the TRUN article says, only the symmetric NAT is impregnable, you can punch holes through other types on NAT.

Because NAT is really pervasive basically only the use cases that work with it survived.

* https://en.wikipedia.org/wiki/Survivorship_bias

IPv6 is no more difficult to understand than IPv4. In many ways it is easier since there are fewer legacy RFCs pertaining to it. System administrators don't understand it because they have not been forced to learn about it yet the same way they were forced to learn about IPv4.

Backwards compatibility would have made it far more complex.

If you sit down to look at IPv6 it's really quite straightforward. I think a lot of network admins are secretly hoping to retire before they have to learn a new technology though.

> IPv6 is a disaster. It's too difficult to understand or configure properly

That's not really true. If you put a minimum of effort, you should be able to setup a local-only IPv6-subnet quite easily. And going from there to internet routable IPv6 takes almost no effort at all.

Yes. There are things which are different from IPv4. But it's not rocket-surgery. If you had any genuine interest in understanding it and put in some effort, you would find most of the "difficulties" are not really all that difficult.

If we were to start with a "from scratch" mindset, I would argue it's rather IPv4 which is hard to understand:

- subnetting? how? why?

- NAT?

- port-forwards?

- upnp assisted firewall traversal?

- upnp UN-assisted firewall traversal?

- Forcing app-developers to use UDP over TCP because... lack of end-to-end connectivity and ... again firewall traversal often only being possible with UDP.

- And what about carrier grade NATs?

And all other kinds of stuff we've just gotten used to being that way.

IPv6 solves most of those things right away... So the only thing you have to learn is the addressing-scheme... And that's about it.

I think everyone who complains about how IPv6 is "hard" has honestly just forgotten just how terrible hacky (and thus complex!) our IPv4 everyday situation really is.

IPv4 is a disaster, when you consider what you need to use it in a modern day system. IPv6 is far simpler in nature, and doesn't require many of hacks that have plagued enterprise networks like SD-WAN, NAT and NAT copium.

It's far easier to learn IPv6 from scratch than to learn IPv4, and then also learn the hacks underneath it, it's miserable.

I am not aware of the reason they went to such a high-complexity setup. They could have simply added a 4 or 6 digit hex code prefix to the IP addresses and figured a way to geographically lock that code.

Sure, that wouldn't give you the 340 trillion trillion trillion IPv6 addresses, but it would have turned 4,294,967,296 IPv4 addresses into 281,474,976,710,656 ipv? addresses and been easy enough to remember that on your local "block" you use idk, "AF09" as the prefix or whatever, and every person on the planet would have about 35 ip addresses (or ~9,000 with a 6 digit prefix) available to them on the new setup not even accounting for NAT

I'm not looking forward to asking my parents to visit http://[fe80::abcd:whatever] to access their router interface when something goes wrong. Hopefully they'll be able to use basic numeric IPs for the rest of their lives.

fe80::1 on link-local is/should almost always be configured as your gateway route. Works very well in corporate setups, too.

Interestingly Firefox does not seem to accept that as a valid address. It will force a a search for 'fe80::1' or even 'http://fe80::1'. Is it just me?

http://[fe80::1]

That doesn't work either. Does it work for you?

Depending on OS, you might need to actually put the interface name in there? As you can have fe80::1 on multiple interfaces...it being link-local. Maybe browsers are holding it back?

My ISP provided router responds to homerouter.cpe with both IPv6 and IPv4 address of its router webui.