6 ms·

Honestly, having worked for a hosting company in the past that was fastidious about IPv6 support, I can say a couple of things: * It is almost definitely not w

by hkt 6y ago

Honestly, having worked for a hosting company in the past that was fastidious about IPv6 support, I can say a couple of things: * It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6 * It is much, much harder to work with than IPv4 and I don't believe this is only a lack of exposure * Dual stacking is expensive and requires staff to pursue training with very uncertain levels of reward IPv4 address space shortages.. could have been addressed by doubling the number of bits in an IPv4 address, rather than throwing out the many tools that already worked. The last point in particular is heresy to network engineers, but perfect sense to commercial types. Adoption should be cheap, if not free. The huge up front human cost of training people to operate IPv6 is uneconomical. A 64bit IPv4.1 would be fine for decades.

throwaway2048 6y ago
There is a weird persistent idea that all anyone really needed to do was "extend ipv4 addresses" and everything ipv4 related would have remained compatible. No, it still absolutely would have completely broken everything and anything that used ipv4, all the tools would still need to be thrown out. There is basically no way such a proposal could work and maintain any sane level of compatibility. Its evident right on its face, how exactly would an ipv4 only tool connect to a 64 bit "ipv4.1 address" ?
- AmericanChopper 6y ago
  Maintaining compatibility was never an option. But the most sensible solution to running out of address space is simply to extend the address space. Instead IPv6 decides to change the format into something which is not really human readable, and decides to kill NAT as well. Which was really a terrible decision imo. I like NAT, I like having addresses that I can remember, and I hate the idea of having a unique globally routable address for every device. The primary argument for adopting IPv6 is that IPv4 will be exhausted. Not that there’s something good about IPv6 that I would want to have. Personally I hope it never succeeds in getting sufficient adoption, so that eventually we can have a good IPv7 that’s just a bigger version of IPv4.
  - privateSFacct 6y ago
    That's not all that IPv6 changed. There is a reason even places like google cloud have not implemented ipv6 (and these are huge scale players). They changed so many things around the protocol that you need new firewall experts, new configuration experts etc etc
    - hkt 6y ago
      That's right: network engineers who speak IPv6 reliably enough to deploy it are rare. Network engineers brave enough to deploy V6 only are even rarer.
  - spacechild1 6y ago
    What do you like about NAT?
- privateSFacct 6y ago
  Do you admin a medium or larger network? Despite the strength of your comment it also illustrates some ignorance. "No way", "weird persistent idea". This despite many reasonable people suggesting it. Deploying IPv6 at scale is deploying a totally different protocal. What is irritating is that it's not just a larger set of bits, everything changed making adoption and tooling MUCH much harder. "All the tools would need to be thrown out" Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them. From address assignment (3 ways now) to the dynamic address privacy extensons (don't actually play well with IPSEC configs) to doing renumberings on prefix changes (100% nightmare) to all the training / learning new things (costs money in bigger orgs) they seem to have purposely made this change extremely hard. Good news, I'm on board more or less with the migration at this point, and if I am a good marker of average reasonable interested in new things but not wasting tons of time then this is a good sign. But boy they could have made this whole thing easier
  - hkt 6y ago
    > "All the tools would need to be thrown out" > Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them. Exactly. ARP64 and DHCP64 etc would be minor modifications and much easier to pick up.
- mprovost 6y ago
  There were proposals for backwards compatible addressing schemes. But they were rejected for a "clean slate" approach. Almost 30 years later, we can see how successful that was... EIP (Extended Internet Protocol) [0] was proposed in 1992 as a replacement for IPv4: "EIP achieves maximum backward compatibility with IP by making the extended space appear to be an IP option to the IP hosts and routers. When an IP host receives an EIP packets, the EIP Extension field is safely ignored as it appears to the IP hosts as an new, therefore an unknown, IP option. As a result, there is no need for translation for in-coming EIP packets destined to IP hosts and there is also no need for subnet routers to be upgraded during the transition period." [0] https://www.rfc-editor.org/rfc/rfc1385.html https://www.rfc-editor.org/rfc/rfc1385.html
  - hkt 6y ago
    I didn't know this was a thing, but it is always a pleasure to know people thought of something like this when I was a toddler.
  - welterde 6y ago
    IPv6 can do that too though! 6in4 is exactly equivalent to the proposed EIP extension. EIP still splits the internet into the old legacy v4 internet and the new EIP internet that cannot communicate with the old internet, since while you can send packets to a v4-only host it won't know what to do with it. You need to preserve this extra information - and IPv4 simply cannot do that. You cannot fit more than 32 bit of information into 32 bit..
  - Dagger2 6y ago
    This proposal essentially ended up as part of v6 in the form of 6to4. 6to4 uses an L4 protocol rather than an IP option, but that's more or less equivalent (and since there are a fair few routers on the internet that drop packets with unknown IP options it ends up working better). But v6 doing something has never stopped people from complaining that v6 sucks for not doing the thing in question...
- p_l 6y ago
  A huge part of that is due to BSD Sockets, which require in-depth application support for any difference in connection parameters.
Thiez 6y ago
Where would these extra 32 bits come from? This simple IPv4.1 would still require all networking hardware and software to be updated. The protocol would also not be backwards compatible and people would still want dual stack. I imagine adoption would not be that much easier than IPv6 adoption, while missing out on the additional improvements that come with IPv6.
- oarsinsync 6y ago
  > while missing out on the additional improvements that come with IPv6. Can you give some examples of what these additional improvements are?
  - caf 6y ago
    One is a much smaller full global routing table.
  - crooked-v 6y ago
    Well, the obvious one is having 2^128 addresses instead of just 2^64 addresses.
  - hkt 6y ago
    There are a few. Things like the way addresses are given out (appending your Mac address to the local prefix), large address spaces (IPv6 could number every atom in existence and then some) which then permits getting rid of NAT, and especially CGNAT (carrier grade NAT). Generally speaking the administrative hacks which enable the internet to keep going as-is can go away. NAT in particular breaks lots of applications which is why STUN/TURN servers are needed for many VoIP applications today, so that two NATed clients can talk directly. The address space issues mean that even if the registry gives out silly allocations (like the UK's MoD having a /8) the space is so near infinite that it won't matter. Even the most incompetent governance can't exhaust the address space.
    - adriancr 6y ago
      Appending MAC to address is a privacy nightmare and is going away with privacy extensions. (I dont want people to know what NIC i have and potentially track me by looking up who bought it). Because of that DHCP may be needed and ARP as well... nice right? Getting rid of NAT is also questionable and there are now tools to do NAT with IPv6. So common sense and learned practices win. (I still prefer NAT and firewall, dedicated servers can have port forwarding or separare ip allocated) Address space is the only feature worth anything as original poster mentioned. This is a nice read on needless issues due to redesign of working protocol: https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ https://blog.bimajority.org/2014/09/05/the-network-nightmare...
dylz 6y ago
I'm sorry, what? Extending the bits in IPv4 will break compatibility completely. Everything will need upgrades just the same as to support IPv6, so you might as well go all the way at that point. How is it much harder to work with?
- galvin 6y ago
  It's a minor detail, but an IPv4 address is easier for humans to use. It's easier to read, type, remember, share over the phone or even just plan with in a spreadsheet.
  - Symbiote 6y ago
    My Danish phone number is 10 digits, including the +45. It would be pretty ridiculous to limit the number of phone connections in Japan by forcing them to use Danish-style 8-digit numbers, but that is the situation with IPv4.
    - galvin 6y ago
      I'm not arguing against IPv6, just explaining how IPv4 can be easier to use.
toast0 6y ago
> It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6 I mean if you're addressing mobile, IPv6 hosting means skipping carrier NAT64 for at least t-mobile and jio. Probably other carriers too.
- p_l 6y ago
  Generally high chances you'll get better connection with any LTE network, as having only v6 to the mobile terminal (phone/modem) is much cheaper - which drove v6 adoption heavily.
mprovost 6y ago
The extension to a 64 bit address with few other changes was called SIP and was proposed in 1992 (!). https://tools.ietf.org/html/draft-historic-simple-ip-03 https://tools.ietf.org/html/draft-historic-simple-ip-03
- p_l 6y ago
  TUBA, which used existing technology and tools to support 18-20 byte addresses (yes, byte, not bit) was ready and implemented on two different platforms by ~1991.
prussian 6y ago
Funny enough, to the last point, someone drafted an IPv4+ spec that does something like that. see https://tools.ietf.org/html/draft-tang-ipv4plus-03 https://tools.ietf.org/html/draft-tang-ipv4plus-03 Basically adds an optional area code to encode more addressable bits.

by hkt 6y ago

throwaway2048 6y ago

There is a weird persistent idea that all anyone really needed to do was "extend ipv4 addresses" and everything ipv4 related would have remained compatible. No, it still absolutely would have completely broken everything and anything that used ipv4, all the tools would still need to be thrown out. There is basically no way such a proposal could work and maintain any sane level of compatibility. Its evident right on its face, how exactly would an ipv4 only tool connect to a 64 bit "ipv4.1 address" ?

AmericanChopper 6y ago
Maintaining compatibility was never an option. But the most sensible solution to running out of address space is simply to extend the address space. Instead IPv6 decides to change the format into something which is not really human readable, and decides to kill NAT as well. Which was really a terrible decision imo. I like NAT, I like having addresses that I can remember, and I hate the idea of having a unique globally routable address for every device. The primary argument for adopting IPv6 is that IPv4 will be exhausted. Not that there’s something good about IPv6 that I would want to have. Personally I hope it never succeeds in getting sufficient adoption, so that eventually we can have a good IPv7 that’s just a bigger version of IPv4.
- privateSFacct 6y ago
  That's not all that IPv6 changed. There is a reason even places like google cloud have not implemented ipv6 (and these are huge scale players). They changed so many things around the protocol that you need new firewall experts, new configuration experts etc etc
  - hkt 6y ago
    That's right: network engineers who speak IPv6 reliably enough to deploy it are rare. Network engineers brave enough to deploy V6 only are even rarer.
- spacechild1 6y ago
  What do you like about NAT?
privateSFacct 6y ago
Do you admin a medium or larger network? Despite the strength of your comment it also illustrates some ignorance. "No way", "weird persistent idea". This despite many reasonable people suggesting it. Deploying IPv6 at scale is deploying a totally different protocal. What is irritating is that it's not just a larger set of bits, everything changed making adoption and tooling MUCH much harder. "All the tools would need to be thrown out" Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them. From address assignment (3 ways now) to the dynamic address privacy extensons (don't actually play well with IPSEC configs) to doing renumberings on prefix changes (100% nightmare) to all the training / learning new things (costs money in bigger orgs) they seem to have purposely made this change extremely hard. Good news, I'm on board more or less with the migration at this point, and if I am a good marker of average reasonable interested in new things but not wasting tons of time then this is a good sign. But boy they could have made this whole thing easier
- hkt 6y ago
  > "All the tools would need to be thrown out" > Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them. Exactly. ARP64 and DHCP64 etc would be minor modifications and much easier to pick up.
mprovost 6y ago
There were proposals for backwards compatible addressing schemes. But they were rejected for a "clean slate" approach. Almost 30 years later, we can see how successful that was... EIP (Extended Internet Protocol) [0] was proposed in 1992 as a replacement for IPv4: "EIP achieves maximum backward compatibility with IP by making the extended space appear to be an IP option to the IP hosts and routers. When an IP host receives an EIP packets, the EIP Extension field is safely ignored as it appears to the IP hosts as an new, therefore an unknown, IP option. As a result, there is no need for translation for in-coming EIP packets destined to IP hosts and there is also no need for subnet routers to be upgraded during the transition period." [0] https://www.rfc-editor.org/rfc/rfc1385.html https://www.rfc-editor.org/rfc/rfc1385.html
- hkt 6y ago
  I didn't know this was a thing, but it is always a pleasure to know people thought of something like this when I was a toddler.
- welterde 6y ago
  IPv6 can do that too though! 6in4 is exactly equivalent to the proposed EIP extension. EIP still splits the internet into the old legacy v4 internet and the new EIP internet that cannot communicate with the old internet, since while you can send packets to a v4-only host it won't know what to do with it. You need to preserve this extra information - and IPv4 simply cannot do that. You cannot fit more than 32 bit of information into 32 bit..
- Dagger2 6y ago
  This proposal essentially ended up as part of v6 in the form of 6to4. 6to4 uses an L4 protocol rather than an IP option, but that's more or less equivalent (and since there are a fair few routers on the internet that drop packets with unknown IP options it ends up working better). But v6 doing something has never stopped people from complaining that v6 sucks for not doing the thing in question...
p_l 6y ago
A huge part of that is due to BSD Sockets, which require in-depth application support for any difference in connection parameters.

Thiez 6y ago

Where would these extra 32 bits come from? This simple IPv4.1 would still require all networking hardware and software to be updated. The protocol would also not be backwards compatible and people would still want dual stack. I imagine adoption would not be that much easier than IPv6 adoption, while missing out on the additional improvements that come with IPv6.

oarsinsync 6y ago
> while missing out on the additional improvements that come with IPv6. Can you give some examples of what these additional improvements are?
- caf 6y ago
  One is a much smaller full global routing table.
- crooked-v 6y ago
  Well, the obvious one is having 2^128 addresses instead of just 2^64 addresses.
- hkt 6y ago
  There are a few. Things like the way addresses are given out (appending your Mac address to the local prefix), large address spaces (IPv6 could number every atom in existence and then some) which then permits getting rid of NAT, and especially CGNAT (carrier grade NAT). Generally speaking the administrative hacks which enable the internet to keep going as-is can go away. NAT in particular breaks lots of applications which is why STUN/TURN servers are needed for many VoIP applications today, so that two NATed clients can talk directly. The address space issues mean that even if the registry gives out silly allocations (like the UK's MoD having a /8) the space is so near infinite that it won't matter. Even the most incompetent governance can't exhaust the address space.
  - adriancr 6y ago
    Appending MAC to address is a privacy nightmare and is going away with privacy extensions. (I dont want people to know what NIC i have and potentially track me by looking up who bought it). Because of that DHCP may be needed and ARP as well... nice right? Getting rid of NAT is also questionable and there are now tools to do NAT with IPv6. So common sense and learned practices win. (I still prefer NAT and firewall, dedicated servers can have port forwarding or separare ip allocated) Address space is the only feature worth anything as original poster mentioned. This is a nice read on needless issues due to redesign of working protocol: https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ https://blog.bimajority.org/2014/09/05/the-network-nightmare...

dylz 6y ago

I'm sorry, what? Extending the bits in IPv4 will break compatibility completely. Everything will need upgrades just the same as to support IPv6, so you might as well go all the way at that point. How is it much harder to work with?

galvin 6y ago
It's a minor detail, but an IPv4 address is easier for humans to use. It's easier to read, type, remember, share over the phone or even just plan with in a spreadsheet.
- Symbiote 6y ago
  My Danish phone number is 10 digits, including the +45. It would be pretty ridiculous to limit the number of phone connections in Japan by forcing them to use Danish-style 8-digit numbers, but that is the situation with IPv4.
  - galvin 6y ago
    I'm not arguing against IPv6, just explaining how IPv4 can be easier to use.

toast0 6y ago

> It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6 I mean if you're addressing mobile, IPv6 hosting means skipping carrier NAT64 for at least t-mobile and jio. Probably other carriers too.

p_l 6y ago
Generally high chances you'll get better connection with any LTE network, as having only v6 to the mobile terminal (phone/modem) is much cheaper - which drove v6 adoption heavily.

mprovost 6y ago

The extension to a 64 bit address with few other changes was called SIP and was proposed in 1992 (!). https://tools.ietf.org/html/draft-historic-simple-ip-03 https://tools.ietf.org/html/draft-historic-simple-ip-03

p_l 6y ago
TUBA, which used existing technology and tools to support 18-20 byte addresses (yes, byte, not bit) was ready and implemented on two different platforms by ~1991.

prussian 6y ago

Funny enough, to the last point, someone drafted an IPv4+ spec that does something like that. see https://tools.ietf.org/html/draft-tang-ipv4plus-03 https://tools.ietf.org/html/draft-tang-ipv4plus-03 Basically adds an optional area code to encode more addressable bits.