Hacker News Reader

IPv6 is not a "wildly different network stack". It retains almost everything of the IPv4 stack. It replaces some small parts of the stack (e.g., DHCP by stateless auto-configuration, which doesn't affect applications). Updating an application-layer IPv4 program to support IPv6 is usually just a matter of fixing the structs/API calls.

And how is it "much more complicated"? IPv4 with layers of NAT bolted on top of it in an ad-hoc fashion doesn't strike me as a paragon of simplicity. The IPv6 world seems much cleaner to me.

Also, IPv4 addresses absolutely are complicated enough to have warranted their own Wikipedia articles: https://en.wikipedia.org/wiki/Classful_network, https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing. But it doesn't matter - for the most part, applications don't need to care about the structure of an IPv6 address.

> wildly different network stack that happens to offer similar enough TCP-like abstractions that user-level code often is only slightly affected, but everything else in the stack is profoundly affected.

TCP itself hasn't changed. TCP is a protocol that sits on top of IP (version 4 or 6). Same with UDP. Yes the IP stack has changed, that kind of thing happens when you bump the version number ;-)

So from an application standpoint TCP/UDP haven't changed, the only thing that has changed is the structure to set up the IP connection, and even that is hidden away for most users (getaddrinfo() deals with most of the complexities for developers).

Percent signs in an address are only used on link-local segments with link-local addresses, as they are the only way to distinguish what network interface to use. In almost all cases where you are dealing with IPv6 you can completely ignore that aspect because you won't have to deal with it, especially as an application developer trying to make connections to IPv6 hosts, or even starting servers/listening for incoming connections.

> The advantage of the "just extend it" plan is that it would have been that easy.

I disagree. This still requires that the entire IP stack be upgraded to support it, applications still need to update all of their network handling code to deal with the extensions, we'd be in exactly the same boat.

As I said, application programmers just using TCP have way less to deal with than all the other hardware in the stack. The point is all the other hardware has much larger changes to make than just "extending an address". It's a brand new protocol, not an extension.

I've been involved in some relatively trivial extension of application-level network devices to IPv6, and even that was a surprisingly large nightmare because you embed all these assumptions about addresses everywhere without even realizing it. Not just "they're a 4-byte integer"; one big one you embed without even realizing it pretty deeply is that "A network address is one type." In dual-stack code, you no longer have "an address". You have two types. That's just an example of the problem.

I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not, because I've seen even within a network company a lot of severe underestimations of the difficulty. (Some of these things are much easier when you write new code for IPv4+IPv6, which is why I say convert. Of course if you write new code on an abstraction layer that already solved this problem it's easier.) IPv6 is not IPv4, quite profoundly. It's not just addressing changes. Converting to IPv6 is not just "replacing all your gear", it is rewriting foundational aspects of all that gear and a non-trivial amount of the software that uses it. Not mere surface aspects like addressing schemes.

This all looks fine and dandy from 30,000 feet, but when you're on the ground, it's a really hard transition.

> I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not

Yes, to the former, only device updates I've done was for a proprietary appliance and that was mainly get new Linux kernel built and then upgrade software. I have not had to deal with silicon level stuff.

I updated various proprietary applications over the course of a week to bind and function over IPv6. Logging was an issue with the new addresses since assumptions were made about IP length, but those were quickly fixed.

Clients that were using old functions instead of getaddrinfo() were easily updated, and in general my experience is that clients don't really care so much about what IP version they use to connect. Once again logging functions assumed that IP's were only IPv4 structs, so some changes and they could log either one.

Overall the transition was simple, the applications already supported binding to multiple addresses, so having it be dual stack ready (binding both IPv4 and IPv6 was simple), and those that didn't took a little longer but ultimately wasn't that much more difficult to get them upgraded.

I pay my network vendors to get me the latest standards, getting all of this right on their end may have been a lot of work, but ultimately that is a one-time cost of doing business, and in most cases I am paying for them to support my use cases.

I have (worked at a networking equipment company on IPv6 support, briefly).

The few bits that are totally different (ARP-to-ND, for example) are all very small bits of code. The really hairy stuff was always the dual-stack - the assumption of a single IP instance running over any given layer-2 network is baked deeply into most systems, and changing that is a royal pain. That plus the renumbering of constants (ugh ICMPv6).

The way I explained it to people was: IPv6 is exactly the same as IPv4, but with incompatible field sizes and constants, different (but usually MUCH simpler) address configuration, and no hop-by-hop fragmentation (oh frabjous day!).

Be specific. What is the "almost everything else" that so many people have to worry about? People who write IP address parsing libraries have to care about percent signs and formats. People who write DHCP clients have to care about DHCP changes. But neither of these are huge changes that affect everyone.

I've got one- every interface has two ipv6 ips, one real, one link local, which requires a lot of little tweaks in a lot of deployments.

Or if you're doing DSR, the default route ordering rules are different.

Every interface can have 1 or more IPv6 IP's. Link-local and N number of others, where N is 0 or more.

What kind of tweaks have you required in your deployments because of this?

DSR is a special use case, and with each interface having a link-local address means you don't need to provide globally unique addresses, because the source/destination specify their route explicitly, each hop can use their link-local address. DSR would also require modification if it was using an extended version of IPv4...

Link local is by design invisible to normalapplications. You can't even use them in place of routable addresses in applications. (You have to do a special bind() with the right scope id)

I'll bite. How can you have more than one "default" route without PBR on the host? That's breaking the meaning of default.

Why does link local need to be complicated? Router interfaces facing clients should be fe80::1. That way, every client knows it's default route is fe80::1%eth0 (or similar). Works great for multiple addresses from different networks on the same host, too.

This isn't new. Your interface could have more than one ipv4 IP also. If two ipv6 addresses are throwing something off that means it wasn't properly handling this case before.

> Just look at this page: https://en.wikipedia.org/wiki/IPv6_address

> By contrast, I can't link you to the "Wikipedia page on IPv4 addresses", because it doesn't rate its own page. It just gets rolled into a single section on the IPv4 page in general: https://en.wikipedia.org/wiki/IPv4#Addressing

The above neatly encapsulates my problem with IPv6. I feel IPv6 would have much more widely adopted by now if people like myself—who have spent nominal time setting up small computer networks such as their home network—could more readily grok the deltas between v4 and v6. With the reality of v6 being so dramatically different, I have on about three separate occasions sat down to try to understand what I need to do in order to have v6 on my home network and each time I just give up after a few hours of reading.

It's just so much more complicated for the amateur network operators out there.

Additionally, it instills fear that if I turn on v6, I will inevitably have my home network in some tragically vulnerable state.

> With the reality of v6 being so dramatically different, I have on about three separate occasions sat down to try to understand what I need to do in order to have v6 on my home network and each time I just give up after a few hours of reading.

I don't mean to offend you, but I think that that suggests that you don't understand IPv4 either.

IPv6 isn't really all that different from IPv4--with one major exception: All of the workarounds for the shortcomings of IPv4 that dominate local networks nowadays are not needed anymore, actually making networks so much simpler again.

Now, many people who have learned IP networking in such environments in the last ten years or so (and I suspect you are one of those) seem to think that those workarounds are what defines IPv4 and then are confused by IPv6's lack of those workarounds, thinking that those are missing features.

Maybe you think that your "internal network" is in some way fundamentally different from "the internet" and that a router is a device that connects those two to give your local network "access to the internet"? That is a common misunderstanding caused by NAT. The internet without NAT, be it IPv4 or IPv6, doesn't know any distinction between "internal" or "external" networks. It is all one network, the internet. Your LAN is not somehow "connected to the internet", it is itself part of the internet. Your home router (without NAT) is no different in function than any other router on the internet: It is connected to more than one transmission medium and thus allows devices on one medium to reach devices connected to another medium, possibly transitively through yet another (series of) routers. And it's completely symmetrical in that regard: It allows devices on your LAN to send packets to devices outside your LAN (say one of Google's webservers), but equally allows devices outside your LAN to send packets to devices on your LAN (say a webserver on your laptop).

So, the most important thing you may have to completely unlearn is the idea of "private addresses" and "NAT" and "port forwarding". You don't get one address from your provider, you get a huge subnet with quadrillions of addresses that you can use to assign addresses to your devices, similar to the early days of IPv4. Your laptop gets an IPv6 address that is no different in function than the IPv6 address of Google's webserver.

Other than that, details and terms differ, but the general concepts of IPv6 aren't all that different from IPv4. ARP is now NDP, DHCP is now SLAAC (or maybe still DHCPv6 if you like), ...

Now, if you think that it seems problematic to have "public addresses" on your "private network": It's not, that's purely psychology. Yes, a stateful packetfilter at boundaries to other, non-trustworthy, networks might still be a good idea, just as with IPv4, whether you were using NAT or not. If anything, having one global address space makes things much less complicated, and thus more difficult to screw things up.

Once you get the hang of it, you will love it and start wondering why you ever considered NAT a reasonable idea. Ever had the problem that you had multiple machines behind a NAT offering the same service that you needed to access from the outside, so you had to put one of them on a different port on "the public address"? Ever tried to access a port-forwarded service from the network behind the NAT and had it either fail because of lack of hairpin NAT, or it was slow because of the bottleneck that was the hairpin NAT? All those problems simply vanish, never to return.

Your comment gave me yet another reason to feel lucky to have learned about the Internet in the early 90’s, just before the boom. I agree with your comment enormously, and I regret that I have only one upvote to give.

Thanks for taking the time to write a very thoughtful reply. You've given me some motivation to take another look into it!

Arguably, it deserves a page because it provides more features.

The fact that it "deserves" its own page is precisely my point. "It has more features" -> "it takes more implementation work than just replacing all addresses". Even ignoring the base work of making things dual-stack you have fundamental rewrites of base assumptions about addresses to take into account.

Actually, ipv6 takes less implementation work from a network operations standpoint. Every site gets a fixed size network, every building gets a fixed size network, every vlan gets a fixed size network. No more IP budgeting and wrangling nabout justifying IP allocations. "Is that worthy of a /18 or should it be a /20?" That's all gone. Every vlan with people gets a /64 and your router interface to them is fe80::1. Turn on SLAAC and let it run. No more NAT pools and rules. It's great!

I've been pushing this idea at work lately. We've got a whole network of /28's in IPv4. Provisioning new servers is a nightmare.

I'd highly suggest you follow the NANOG BCOP. There's a site for it: http://nabcop.org/index.php/IPv6_Subnetting

Here's where I got the idea of using fe80::1 everywhere for the link-local gateway: https://www.edge-cloud.net/2013/08/ipv6-link-local-addresses...