4 ms·

> simply don't because they are lazy and IPv4 works for them Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted

> simply don't because they are lazy and IPv4 works for them Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.

zamadatix 1y ago
Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT64, and others. They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.
- JoshTriplett 1y ago
  > They're almost always deployed though because people end up liking the ideas. Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely. Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
  - zamadatix 1y ago
    Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question. > For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely. On IPv4 I assume you're doing something which boils down to (from whatever network configuration tool you use): ip addr add 192.168.1.100/24 dev eth0 ip route add default via 192.168.1.1 dev eth0 Which maps directly to: ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0 ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0 If you're also doing a static ARP to be "fully" static then you'll also have an additional config which boils down to something akin to: ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent Which maps to this config to statically set the MAC instead of using ND: ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent In both cases you either need to still locally respond to dynamic ARP/ND request or also statically configure the rest of the devices in the subnet (including the router) in a similar fashion, but there's not really much difference beyond the extra bits in the address. > Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6. I have a strong aversion to AWS... but if there is anything more difficult about this for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something. There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.
    - JoshTriplett 1y ago
- yjftsjthsd-h 1y ago
  I'm not convinced that's true in practice. I would like to have an IPv6 network that I can connect Android devices to and on which I can connect to the devices by their host name. Android refuses to support DHCPv6, telling the local DNS server about SLAAC addresses involves awful and unreliable hacks, mDNS requires extra daemons and resolver configuration. I looked at just copying my v4 stack to v6; it doesn't appear possible.
  - zamadatix 1y ago
    Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.
    - yjftsjthsd-h 1y ago
      Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.
      - deleted 1y ago
        [deleted]
      - zamadatix 1y ago
        I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer. To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it. It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.
bigstrat2003 1y ago
I've run IPv6 on both corporate and home networks. Whether or not the additions were merited, they are not a formidable challenge for any reasonably-skilled admin. So no, I don't think that the reason you gave suffices as an excuse for why so many still refuse to deploy IPv6.
- dmitrygr 1y ago
  I'll assume you are speaking in good faith, so i'll reply so as well: I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 checkbox and turn it off, as usual.
  - Dylan16807 1y ago
    That's the fault of whoever designed the router, not IPv6.
    - dmitrygr 1y ago
      As a consumer, I don’t care if it’s Santa Claus’s fault. IPv4: works, IPv6: doesn’t. I don’t even need to know what IPv6 means. I just need to know: Turn it off to make things work. As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.
      - Dylan16807 1y ago
        And I'm not blaming the consumer. If you want to come into a topic and say the problem is that IPv6 did too much, you can't fall back on "it doesn't matter who's at fault". Yes it does matter, that's what this thread is about, that and looking at how technological changes would have affected deployment.
codebje 1y ago
If you "simply" added more bits to IPv4, you'd have a transition every bit (ahaha, ahem, sorry) as complex as the transition to IPv6 anyway, because IPv4+ would be a new protocol in exactly the same way as IPv6. A new DNS response record. Updates to routing protocols. New hardware. New software. And no interoperability between the two without stateful network address translation.
- pavpanchekha 1y ago
  Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.
  - codebje 1y ago
    The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years. Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem. A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise. Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly. We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space. edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.
    - pavpanchekha 1y ago
hinkley 1y ago
If it had been more urgent to move off of IPv4 a lot of those riders would have either been eliminated or not thought of yet. We’d be looking at 54 bit addressing and planning IPv7 to have 108.

> simply don't because they are lazy and IPv4 works for them Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.

zamadatix 1y ago

Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT64, and others. They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.

JoshTriplett 1y ago
> They're almost always deployed though because people end up liking the ideas. Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely. Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
- zamadatix 1y ago
  Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question. > For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely. On IPv4 I assume you're doing something which boils down to (from whatever network configuration tool you use): ip addr add 192.168.1.100/24 dev eth0 ip route add default via 192.168.1.1 dev eth0 Which maps directly to: ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0 ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0 If you're also doing a static ARP to be "fully" static then you'll also have an additional config which boils down to something akin to: ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent Which maps to this config to statically set the MAC instead of using ND: ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent In both cases you either need to still locally respond to dynamic ARP/ND request or also statically configure the rest of the devices in the subnet (including the router) in a similar fashion, but there's not really much difference beyond the extra bits in the address. > Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6. I have a strong aversion to AWS... but if there is anything more difficult about this for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something. There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.
  - JoshTriplett 1y ago
yjftsjthsd-h 1y ago
I'm not convinced that's true in practice. I would like to have an IPv6 network that I can connect Android devices to and on which I can connect to the devices by their host name. Android refuses to support DHCPv6, telling the local DNS server about SLAAC addresses involves awful and unreliable hacks, mDNS requires extra daemons and resolver configuration. I looked at just copying my v4 stack to v6; it doesn't appear possible.
- zamadatix 1y ago
  Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.
  - yjftsjthsd-h 1y ago
    Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.
    - deleted 1y ago
      [deleted]
    - zamadatix 1y ago
      I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer. To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it. It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.

bigstrat2003 1y ago

I've run IPv6 on both corporate and home networks. Whether or not the additions were merited, they are not a formidable challenge for any reasonably-skilled admin. So no, I don't think that the reason you gave suffices as an excuse for why so many still refuse to deploy IPv6.

dmitrygr 1y ago
I'll assume you are speaking in good faith, so i'll reply so as well: I do not want to be a "reasonably-skilled admin". Not my job nor desire. I want DHCP to work and NAT to exist which acts as a de-facto firewall and hides my internal network config from the outside world. All with zero or fewer clicks in my home router's config. With IPv4 this works. With IPv6 it does not. Simple choice for me then: find the IPv6 checkbox and turn it off, as usual.
- Dylan16807 1y ago
  That's the fault of whoever designed the router, not IPv6.
  - dmitrygr 1y ago
    As a consumer, I don’t care if it’s Santa Claus’s fault. IPv4: works, IPv6: doesn’t. I don’t even need to know what IPv6 means. I just need to know: Turn it off to make things work. As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.
    - Dylan16807 1y ago
      And I'm not blaming the consumer. If you want to come into a topic and say the problem is that IPv6 did too much, you can't fall back on "it doesn't matter who's at fault". Yes it does matter, that's what this thread is about, that and looking at how technological changes would have affected deployment.

codebje 1y ago

If you "simply" added more bits to IPv4, you'd have a transition every bit (ahaha, ahem, sorry) as complex as the transition to IPv6 anyway, because IPv4+ would be a new protocol in exactly the same way as IPv6. A new DNS response record. Updates to routing protocols. New hardware. New software. And no interoperability between the two without stateful network address translation.

pavpanchekha 1y ago
Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.
- codebje 1y ago
  The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years. Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem. A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise. Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly. We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space. edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.
  - pavpanchekha 1y ago

hinkley 1y ago

If it had been more urgent to move off of IPv4 a lot of those riders would have either been eliminated or not thought of yet. We’d be looking at 54 bit addressing and planning IPv7 to have 108.