11 ms·

> Why isn’t IPv6 more popular? ... and an arguably overly complex design. I really don't know where this ridiculous claim comes from. Yes, IPv6 addresses look

> Why isn’t IPv6 more popular? ... and an arguably overly complex design. I really don't know where this ridiculous claim comes from. Yes, IPv6 addresses look more complicated but various other things about the protocol are drastically simplified — no more on-path fragmentation, simpler header formats and fewer required header fields, correctly implemented link-local scopes, previously separate ICMP+ARP+IGMP protocols consolidated into ICMPv6 (which handles neighbour discovery, router advertisements, path MTU discovery and multicast group membership amongst others), no more broadcast, and in many cases clients will quite happily get along without DHCP. If anything, it is considerably less complex.

l0b0 5y ago
There should be lots of implementations of both protocols by now - could we compare them for length and complexity to determine some sort of objective measure of the difference?
- SSLy 5y ago
  Linux's net/ipv4 is 2.7MiB of code, net/ipv6 is 1.7MiB.
pilif 5y ago
While routing at global scale is much easier, running v6 in a local network has more moving parts than v4 had: - broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly - address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one. - hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts. - for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses (yes, you can of course manually assign addresses in your prefix and you can just make them low numbers and hide everything else behind a ::, but you still have to remember your prefix which still is impossibly hard and there's no cheating there even if you know somebody at your ISP because it's not entirely under their control either) - and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks. - also subnetting: due to many ISPs still doing /64 allocations to their customers, and due to the way how SLAAC works, you often have to decide between subnetting or SLAAC (which still is the default in many OSes). Worse, some ISPs only do a /128 assignment (one address), so now you're back in NAT territory, only that's really, really murky waters because next to nobody is doing this ATM. If your ISP only gives you a single v6 address, you are practically screwed about running v6 internally. If you're given a single v4 address (which is common practice), you can do NAT/RFC1918 addressing and you're fine. - v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways. - in home networks where you want devices to be reachable directly (for P2P usages like video calls or gaming), there's no widely-supported equivalent to UPNP or NAT-PMP yet to punch holes into your firewall to make clients reachable. Yes, you don't have to do NAT any more, so clients are potentially reachable, but you really don't want that, so your firewall is still blocking all incoming connections, but now there's no way for an application to still punch temporary holes through which is a solved problem in v4 (where a hole is punched and a temporary port-mapping is created) There are more issues as your network grows bigger, but this is what I had to deal with in my small networks (<50 hosts) where I can say with certainty that v4 was much more straightforward to get up and running than v6 (though I was much older when I was learning v6 than when I was learning v4, so I might also just be getting old and slow) Yes. These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable ipv6 rather than learning about all these small issues and working around them. So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site, but, the internet is as much about the global scale as it's about the local site and when the new thing is much harder to use than the old thing, inertia is even bigger than in the normal "everything is mostly the same" case (where inertia already feels like an insurmountable problem)
- neilalexander 5y ago
  How switches "handle" multicast is not a new problem — many will treat it as broadcast traffic and flood it across the network segment, leaving clients to work out if they are interested or not. More intelligent switches might perform IGMP snooping to avoid flooding and this will be no more complex with IPv6 than it is with IPv4 today. Multihoming also isn't new and isn't really IPv6-specific. It might be more likely that you'll have multiple IPv6 prefixes but the majority of source address selection rules that you are used to in IPv4 will still apply, and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway. Subnetting is probably not easier or harder. The address length doesn't change how subnetting or how routing tables work and I am not really convinced that an IPv6 addressing plan should really be any worse or better than an IPv4 addressing plan. The minimum prefix size of /64 for a network segment is about the only extra consideration there, but if anything, it should be simpler than having to manage globally routable address space and private address space separately given that you can now manage address space as a true single hierarchy. You're right that SLAAC vs DHCP can add a bit of mental overhead, but for most configurations, configuring DHCP and letting RAs be sent automatically in IPv6 is not much different to configuring a default gateway in DHCP on an IPv4 network. Finally, as for ICMPv6, it has always been bad behaviour to just outright filter ICMP without consideration for what it will break. The stakes are indeed higher than in IPv4, but it seems worth it if we can eliminate two entirely separate protocols in the process and firewall vendors and admins are just going to have to learn that. I get there are a lot of cognitive factors involved in why people resist IPv6 but it really isn't as alien as most people think and most of the concerns are easily answered.
  - pilif 5y ago
    > many will treat it as broadcast traffic and flood it across the network segment and some will silently swallow them until you update their firmware. Broadcasts on the other hand are so common (and required for ipv4 to work) that they are rarely broken. If multicast is treated as broadcast, stuff works "fine", but because of IGMP snooping and additional "intelligence" the switches often employ, unfortunately, the failure modes I have seen tend to be packet loss rather than overeager packet forwarding. And with multicast packets dropped in a v4 network, some niche applications will stop working, but with multicasts packets dropped in a v6 network, your network will stop working. Period. > and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway of course you have. My point isn't that v6 multi-homing is any different from v4 multi-homing. My point is that multi-homing is rare with v4 but very common and required for v6. So what's often not an issue at all on anybodies radar in a v4 network is something everybody has to deal with in a v6 network. > most of the problems can be trivially solved. absolutely. But they don't have to be solved by staying with v4 and thus inertia is even harder to overcome than it normally is. That was my point.
api 5y ago
It’s less complex in many ways for machines but the long addresses make it unwieldy for human beings.
- aaaaaaaaaaab 5y ago
  If only we could attach names to IP addresses somehow!
  - api 5y ago
    ... and have it work reliably ...? The real problem is standing up DNS on local or enclave networks with zero effort. Right now setting up DNS is a pain, configuring DNS is a pain, and mDNS doesn't scale and is slow.
- e2le 5y ago
  At least in local network environments, using mdns (avahi) to discover other hosts is preferable and possibly more user friendly for less knowledgeable users.
phicoh 5y ago
In my experience, IPv6 is often more complex. The main exception is that by and large IPv6 doesn't have NAT, so that saves a few headaches in that area. No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. Moving fragmentation to an extension header similarly creates problems. Dealing with extension headers is just more code complexity. Link local does not work (reliably) in browsers: https://[fe80::1]/ https://[fe80::1]/ doesn't work on most platforms. ICMP, ARP, and IGMP perform completely separate functions. Putting then all in ICMPv6 doesn't help. In contrast, having ND in ICMPv6 leads to code complexity. In IPv4, ICMP logically uses IP to send packets with uses ARP. In IPv6, ICMPv6 logically uses IPv6 to send packets, which uses ICMPv6 for neighbour discovery. IPv6 created a lot of flexibily by having multiple addresses per interface created automatically from router advertisements. And multiple routers on a subnet that can each support different prefixes (poor man's multihoming). Net result, certainly with devices that frequently connect to different networks, such as phones and laptops), is way too complex. That said, the only way forward is IPv6. Putting everything behind multiple layers of NAT is ultimately going to fail.
- HALtheWise 5y ago
  I'm curious what you see as the reason that putting everything behind multiple layers of nat can't work? It seems to me like it has worked pretty well so far, and we're nowhere close to running out of (ip, port, ip, port) tuples.
  - zamadatix 5y ago
    1 layer of nat on each side hasn't bad, the 2 layers of nat on each side carriers have been moving to has been a godawful mess of complexity for any conversation where at least one side isnt a public IP (e.g. p2p chat/calls).
- zamadatix 5y ago
  > No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. I thought this was the other way around, IPv4 only guarantees reassembly up to 576 bytes so DNS avoided issues with split UDP datagrams by limiting the payload to 512. Ends stuff got added on once the defacto internet mtu became 1500 and there was more room. Things like 4G have a 1482 MTU though so it may seem frag!mentation helps but in reality most IPv4 routers don't fragment and reassemble anymore they just drop. In practice with DNS this has meant either keeping the packet size closer to 1k or using TCP which negotiates miss and handles correcting/merging lost split payloads. If anything IPv6 has made the situation cleaner with a minimum supported MTU of 1280 vs IPv4s 68 guaranteeing the 1kish UDP DNS payloads can make it through without relying on pmtud.
crawshaw 5y ago
Because it wasn't designed as a drop-in replacement, so using ipv6 necessarily means using ipv4+ipv6 for a time. That time is now twenty years and counting.
benttoothpaste 5y ago
I tried to set up IPv6 a while ago, and it looked simple at first. After configuring the router - just flipping "enable ipv6" in gui - my machine got 10 IPv6 addresses (why this many? I don't know). Cool. I then set up the firewall to expose one of these addresses and I could ssh to my machine from the outside world. A win! Unfortunately the win was short lived. Eventually I lost the ability to ssh in. It turned out that the 10 IPv6 addresses were replaced by a different bunch of 10 addresses. So I would have to reconfigure the firewall again. I decided it was too much work for me and disabled IPv6. Maybe some other time.
- kaba0 5y ago
  How is that the fault of IPv6 over eg. your internet provider?
  - benttoothpaste 5y ago
    I did not blame anyone, just shared why it is not great for me.
- BruiseLee 5y ago
  Believe it or not this feature is intentional. It is for your privacy so you cannot be tracked by your IP address...
- jppittma 5y ago
  This is what dynamic dns is for. Your isp should have you covered there, and if not there are other free ones.
  - magicalhippo 5y ago
    How does dynamic DNS help change his firewall rules?

l0b0 5y ago

There should be lots of implementations of both protocols by now - could we compare them for length and complexity to determine some sort of objective measure of the difference?

SSLy 5y ago
Linux's net/ipv4 is 2.7MiB of code, net/ipv6 is 1.7MiB.

pilif 5y ago

While routing at global scale is much easier, running v6 in a local network has more moving parts than v4 had: - broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly - address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one. - hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts. - for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses (yes, you can of course manually assign addresses in your prefix and you can just make them low numbers and hide everything else behind a ::, but you still have to remember your prefix which still is impossibly hard and there's no cheating there even if you know somebody at your ISP because it's not entirely under their control either) - and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks. - also subnetting: due to many ISPs still doing /64 allocations to their customers, and due to the way how SLAAC works, you often have to decide between subnetting or SLAAC (which still is the default in many OSes). Worse, some ISPs only do a /128 assignment (one address), so now you're back in NAT territory, only that's really, really murky waters because next to nobody is doing this ATM. If your ISP only gives you a single v6 address, you are practically screwed about running v6 internally. If you're given a single v4 address (which is common practice), you can do NAT/RFC1918 addressing and you're fine. - v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways. - in home networks where you want devices to be reachable directly (for P2P usages like video calls or gaming), there's no widely-supported equivalent to UPNP or NAT-PMP yet to punch holes into your firewall to make clients reachable. Yes, you don't have to do NAT any more, so clients are potentially reachable, but you really don't want that, so your firewall is still blocking all incoming connections, but now there's no way for an application to still punch temporary holes through which is a solved problem in v4 (where a hole is punched and a temporary port-mapping is created) There are more issues as your network grows bigger, but this is what I had to deal with in my small networks (<50 hosts) where I can say with certainty that v4 was much more straightforward to get up and running than v6 (though I was much older when I was learning v6 than when I was learning v4, so I might also just be getting old and slow) Yes. These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable ipv6 rather than learning about all these small issues and working around them. So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site, but, the internet is as much about the global scale as it's about the local site and when the new thing is much harder to use than the old thing, inertia is even bigger than in the normal "everything is mostly the same" case (where inertia already feels like an insurmountable problem)

neilalexander 5y ago
How switches "handle" multicast is not a new problem — many will treat it as broadcast traffic and flood it across the network segment, leaving clients to work out if they are interested or not. More intelligent switches might perform IGMP snooping to avoid flooding and this will be no more complex with IPv6 than it is with IPv4 today. Multihoming also isn't new and isn't really IPv6-specific. It might be more likely that you'll have multiple IPv6 prefixes but the majority of source address selection rules that you are used to in IPv4 will still apply, and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway. Subnetting is probably not easier or harder. The address length doesn't change how subnetting or how routing tables work and I am not really convinced that an IPv6 addressing plan should really be any worse or better than an IPv4 addressing plan. The minimum prefix size of /64 for a network segment is about the only extra consideration there, but if anything, it should be simpler than having to manage globally routable address space and private address space separately given that you can now manage address space as a true single hierarchy. You're right that SLAAC vs DHCP can add a bit of mental overhead, but for most configurations, configuring DHCP and letting RAs be sent automatically in IPv6 is not much different to configuring a default gateway in DHCP on an IPv4 network. Finally, as for ICMPv6, it has always been bad behaviour to just outright filter ICMP without consideration for what it will break. The stakes are indeed higher than in IPv4, but it seems worth it if we can eliminate two entirely separate protocols in the process and firewall vendors and admins are just going to have to learn that. I get there are a lot of cognitive factors involved in why people resist IPv6 but it really isn't as alien as most people think and most of the concerns are easily answered.
- pilif 5y ago
  > many will treat it as broadcast traffic and flood it across the network segment and some will silently swallow them until you update their firmware. Broadcasts on the other hand are so common (and required for ipv4 to work) that they are rarely broken. If multicast is treated as broadcast, stuff works "fine", but because of IGMP snooping and additional "intelligence" the switches often employ, unfortunately, the failure modes I have seen tend to be packet loss rather than overeager packet forwarding. And with multicast packets dropped in a v4 network, some niche applications will stop working, but with multicasts packets dropped in a v6 network, your network will stop working. Period. > and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway of course you have. My point isn't that v6 multi-homing is any different from v4 multi-homing. My point is that multi-homing is rare with v4 but very common and required for v6. So what's often not an issue at all on anybodies radar in a v4 network is something everybody has to deal with in a v6 network. > most of the problems can be trivially solved. absolutely. But they don't have to be solved by staying with v4 and thus inertia is even harder to overcome than it normally is. That was my point.

api 5y ago

It’s less complex in many ways for machines but the long addresses make it unwieldy for human beings.

aaaaaaaaaaab 5y ago
If only we could attach names to IP addresses somehow!
- api 5y ago
  ... and have it work reliably ...? The real problem is standing up DNS on local or enclave networks with zero effort. Right now setting up DNS is a pain, configuring DNS is a pain, and mDNS doesn't scale and is slow.
e2le 5y ago
At least in local network environments, using mdns (avahi) to discover other hosts is preferable and possibly more user friendly for less knowledgeable users.

phicoh 5y ago

In my experience, IPv6 is often more complex. The main exception is that by and large IPv6 doesn't have NAT, so that saves a few headaches in that area. No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. Moving fragmentation to an extension header similarly creates problems. Dealing with extension headers is just more code complexity. Link local does not work (reliably) in browsers: https://[fe80::1]/ https://[fe80::1]/ doesn't work on most platforms. ICMP, ARP, and IGMP perform completely separate functions. Putting then all in ICMPv6 doesn't help. In contrast, having ND in ICMPv6 leads to code complexity. In IPv4, ICMP logically uses IP to send packets with uses ARP. In IPv6, ICMPv6 logically uses IPv6 to send packets, which uses ICMPv6 for neighbour discovery. IPv6 created a lot of flexibily by having multiple addresses per interface created automatically from router advertisements. And multiple routers on a subnet that can each support different prefixes (poor man's multihoming). Net result, certainly with devices that frequently connect to different networks, such as phones and laptops), is way too complex. That said, the only way forward is IPv6. Putting everything behind multiple layers of NAT is ultimately going to fail.

HALtheWise 5y ago
I'm curious what you see as the reason that putting everything behind multiple layers of nat can't work? It seems to me like it has worked pretty well so far, and we're nowhere close to running out of (ip, port, ip, port) tuples.
- zamadatix 5y ago
  1 layer of nat on each side hasn't bad, the 2 layers of nat on each side carriers have been moving to has been a godawful mess of complexity for any conversation where at least one side isnt a public IP (e.g. p2p chat/calls).
zamadatix 5y ago
> No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems. I thought this was the other way around, IPv4 only guarantees reassembly up to 576 bytes so DNS avoided issues with split UDP datagrams by limiting the payload to 512. Ends stuff got added on once the defacto internet mtu became 1500 and there was more room. Things like 4G have a 1482 MTU though so it may seem frag!mentation helps but in reality most IPv4 routers don't fragment and reassemble anymore they just drop. In practice with DNS this has meant either keeping the packet size closer to 1k or using TCP which negotiates miss and handles correcting/merging lost split payloads. If anything IPv6 has made the situation cleaner with a minimum supported MTU of 1280 vs IPv4s 68 guaranteeing the 1kish UDP DNS payloads can make it through without relying on pmtud.

crawshaw 5y ago

Because it wasn't designed as a drop-in replacement, so using ipv6 necessarily means using ipv4+ipv6 for a time. That time is now twenty years and counting.

benttoothpaste 5y ago

I tried to set up IPv6 a while ago, and it looked simple at first. After configuring the router - just flipping "enable ipv6" in gui - my machine got 10 IPv6 addresses (why this many? I don't know). Cool. I then set up the firewall to expose one of these addresses and I could ssh to my machine from the outside world. A win! Unfortunately the win was short lived. Eventually I lost the ability to ssh in. It turned out that the 10 IPv6 addresses were replaced by a different bunch of 10 addresses. So I would have to reconfigure the firewall again. I decided it was too much work for me and disabled IPv6. Maybe some other time.

kaba0 5y ago
How is that the fault of IPv6 over eg. your internet provider?
- benttoothpaste 5y ago
  I did not blame anyone, just shared why it is not great for me.
BruiseLee 5y ago
Believe it or not this feature is intentional. It is for your privacy so you cannot be tracked by your IP address...
jppittma 5y ago
This is what dynamic dns is for. Your isp should have you covered there, and if not there are other free ones.
- magicalhippo 5y ago
  How does dynamic DNS help change his firewall rules?