12 ms·

If IPv6 would be created with a little bit more care for backward compatibility, it could have been years since last server stopped using IPv4. The whole IPv6 f

If IPv6 would be created with a little bit more care for backward compatibility, it could have been years since last server stopped using IPv4. The whole IPv6 fiasco is self inflicted.

loeg 2y ago
Yes, yes, but at this point those mistakes have been litigated sufficiently and complaining about them doesn't help solve any of the remaining problems.
- b112 2y ago
  Sure it does. We can just move to ipv8, 5 octlets instead of 4. We can give 2.x.x.x.x to 10. to earth, maybe 100 to 110 for moon, mars, etc. 1.x.x.x.x will be for legacy stuff. If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved. edit: I realised people don't see the big picture here. Step 1) We collectively engineer and deploy ipv8, along with RFCs explaining how future expansion works 2) We put all sorts of preparatory work, conversation into the eventual expansion into 6 octlets, from 5. We'll need that once we colonize multiple systems. 3) The RFC will state that "new planetary systems get space on 5th oclet, 1.200.x.x.x.x to 1.250.x.x.x.x. 4) As systems grow to need more than an ipv4 range, we transition them to their own 6th oclet. It's easy for them, because they can retain legacy 5th octlet headers. 5) We then collectively freeze our brains, so that in the future, once interplanetary, faster than light communication exists, we are thawed to deal with the 5 to 6 oclet transition! And we all become immortal. But no, that's fine, think small, stay non-immortal with your ipv6 Flanders!
  - deleted 2y ago
    [deleted]
  - ynik 2y ago
    > If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved. Only for unidirectional UDP. How do you think the other side would be able to respond if it's unaware of the 5th octlet? Basically every protocol in existence requires two-way communication and there's no backward compatible way of providing that.
    - b112 2y ago
      I covered that. Edge routers transition 1.x.x.x.x to x.x.x.x as a default, and x.x.x.x to 1.x.x.x.x. This is an interim change, so that ipv4 can communicate to ipv4 forever. Legacy systems can be supported on ipv4 only, relegating them (just as they are now!) to not having access to that new address space.
      - growse 2y ago
        You realise that this idea of "embedding a smaller, old address space inside a newer bigger one" has existed in IPv6 for a pretty long time now?
        b112 2y ago
        A car and a motorcycle both travel on roads, but they are still not the same. - Henry Perkins
      - tiberious726 2y ago
        You mean this? https://en.m.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.m.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addres...
  - humanfromearth9 2y ago
    1.x.x.x.x -> why not 0.x.x.x.x to represent x.x.x.x ?
  - itchyouch 2y ago
    The dotted quad notation is just a human readable notation. You can’t just add another octet willy nilly. That’s exactly what ipv6 did. They added an extra 12 octets, but used hex notation (0-F) to shorten the number of characters for human readability. Internally, an IP is just a 32bit number. Adding another octet is adding another 8bits to the number. IPv6 merely expands that number to a 128bit number. If you do the math of say converting 8.8.8.8 to 8256^3 + 8256^2 + 8256^1 + 8256^0 and ping the resulting number, it will work.
    - b112 2y ago
      Yes, but this is to aid in a proper transition. All old ipv4 addresses will route fine, using this method.
    - ta1243 2y ago
      > The dotted quad notation is just a human readable notation. You can’t just add another octet willy nilly. That’s exactly what ipv6 did. They added an extra 12 octets, but used hex notation (0-F) to shorten the number of characters for human readability. If that's all IPv6 did that would have been one thing. ipv6 changed tons of things, from arp to nat, dhcp to dns.
      - p_l 2y ago
        And all of them had to change because guess what, they had hardcoded v4 assumptions including "4 octets"
  - eqvinox 2y ago
    Is this genuine or sarcasm? I can't tell.
rcxdude 2y ago
What kind of backward compatibility are you imagining? If you say "with ipv4 addresses", how are you imagining that would work?
- TheLoafOfBread 2y ago
  Keep the structure and services around IP protocol (DNS, DHCP, NAT), just with more bits for address. Do not try to reinvent the wheel and add unnecessary breaking bell and whistles which nobody asked for.
  - jcranmer 2y ago
    All of these things already exist for IPv6, although I don't know how much DHCPv6 is deployed in practice.
    - baq 2y ago
      It should be deployed everywhere where IPv6 is deployed and there's an IT department if only for logging/audit.
      - kccqzy 2y ago
        Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. And I in fact agree with them. And DHCPv6 isn't needed for logging/audit: the router always has an association of MAC addresses and IPv6 addresses even if hosts assign their own addresses with SLAAC.
        bigstrat2003 2y ago
        > Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. Which is absolutely ridiculous. Google should not be trying to dictate to their customers how to run infrastructure. If someone wants to use stateful DHCPv6 for their Android devices, that is their right and Google has no business standing in their way.
icedchai 2y ago
Can you describe how you'd make it more backwards compatible? I often see comments like this, yet nobody can work around the fact that you're limited by 32-bit source and destination headers in V4.
- jedberg 2y ago
  It's pretty simple. If IPv6 headers were split into two parts, where the first part was the same as IPv4, and the second part had the rest of the bits, so you had say 8 octets instead of 4. The rest of the header would look like data to an IPv4 router. So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers. Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. Old IPv4 hosts wouldn't be able to talk to IPv6 endpoints, but at least this way the user could upgrade their own stack without having to wait for their ISP, and every network in between, to also upgrade. It's pretty much carrier grade NAT but from client to client without ISP support being necessary, which is the biggest bottleneck right now.
  - andrewshadura 2y ago
    This has been proposed many times already, and it actually wouldn't work.
    - jedberg 2y ago
      Why not?
      - ianburrell 2y ago
        Because the IPv4 host can't talk to new protocol hosts. IPv4 hosts can only do 32-bit addresses and don't know about the wrapping. If they did, they would be new protocol hosts. I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.
Macha 2y ago
Earlier IP migrations were done when the internet was run by universities and government bodies who felt the need to migrate to a newer standard because there was a newer standard. IPv6 took longer because the internet is now run by companies that need to see a return on investment, and as long as IPv4 was working fine for their customers, didn't see a benefit to it. It's why IPv6 adoption only started taking off when the answer to "Our projected customer growth this year is 200,000, can we have 200,000 more IPv4 addresses please?" became "No".
api 2y ago
It was created by people who were used to the Internet being an ultra high trust relatively close knit community of universities, research, government, and industry. Upgrades across the net had happened before just fine. This one should be no problem. This was around 1996, which is when the vertical growth phase took off. Too late.
dboreham 2y ago
This was deliberate: the idea was that IPng wouldn't get adopted, or even traction in the IETF, if it didn't provide additional functionality/fix perceived problems beyond just address space exhaustion. Remember also that NAT wasn't really a thing at that time. It might have existed but wasn't widely used like happened subsequently. Source: was there.
- JoshTriplett 2y ago
  I can certainly understand that perspective. But from today's perspective, it seems like IPv6 adoption was slowed by ideological arguments like "people should use SLAAC, not DHCP". By all means introduce a new means of obtaining addresses, but let it live or (preferably) die on its own merits, rather than attaching it and a dozen other albatrosses around IPv6's neck. If IPv6 had started from day one by saying "just add an IPv6 block to your DHCP server and let any client that understands IPv6 get an IPv6 address", that would have been an easier sell.

If IPv6 would be created with a little bit more care for backward compatibility, it could have been years since last server stopped using IPv4. The whole IPv6 fiasco is self inflicted.

loeg 2y ago

Yes, yes, but at this point those mistakes have been litigated sufficiently and complaining about them doesn't help solve any of the remaining problems.

b112 2y ago
Sure it does. We can just move to ipv8, 5 octlets instead of 4. We can give 2.x.x.x.x to 10. to earth, maybe 100 to 110 for moon, mars, etc. 1.x.x.x.x will be for legacy stuff. If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved. edit: I realised people don't see the big picture here. Step 1) We collectively engineer and deploy ipv8, along with RFCs explaining how future expansion works 2) We put all sorts of preparatory work, conversation into the eventual expansion into 6 octlets, from 5. We'll need that once we colonize multiple systems. 3) The RFC will state that "new planetary systems get space on 5th oclet, 1.200.x.x.x.x to 1.250.x.x.x.x. 4) As systems grow to need more than an ipv4 range, we transition them to their own 6th oclet. It's easy for them, because they can retain legacy 5th octlet headers. 5) We then collectively freeze our brains, so that in the future, once interplanetary, faster than light communication exists, we are thawed to deal with the 5 to 6 oclet transition! And we all become immortal. But no, that's fine, think small, stay non-immortal with your ipv6 Flanders!
- deleted 2y ago
  [deleted]
- ynik 2y ago
  > If anything is trying to route to only 4 octlets, routers add a 1. in front of it. Bam, legacy solved. Only for unidirectional UDP. How do you think the other side would be able to respond if it's unaware of the 5th octlet? Basically every protocol in existence requires two-way communication and there's no backward compatible way of providing that.
  - b112 2y ago
    I covered that. Edge routers transition 1.x.x.x.x to x.x.x.x as a default, and x.x.x.x to 1.x.x.x.x. This is an interim change, so that ipv4 can communicate to ipv4 forever. Legacy systems can be supported on ipv4 only, relegating them (just as they are now!) to not having access to that new address space.
    - growse 2y ago
      You realise that this idea of "embedding a smaller, old address space inside a newer bigger one" has existed in IPv6 for a pretty long time now?
      - b112 2y ago
        A car and a motorcycle both travel on roads, but they are still not the same. - Henry Perkins
    - tiberious726 2y ago
      You mean this? https://en.m.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.m.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addres...
- humanfromearth9 2y ago
  1.x.x.x.x -> why not 0.x.x.x.x to represent x.x.x.x ?
- itchyouch 2y ago
  The dotted quad notation is just a human readable notation. You can’t just add another octet willy nilly. That’s exactly what ipv6 did. They added an extra 12 octets, but used hex notation (0-F) to shorten the number of characters for human readability. Internally, an IP is just a 32bit number. Adding another octet is adding another 8bits to the number. IPv6 merely expands that number to a 128bit number. If you do the math of say converting 8.8.8.8 to 8256^3 + 8256^2 + 8256^1 + 8256^0 and ping the resulting number, it will work.
  - b112 2y ago
    Yes, but this is to aid in a proper transition. All old ipv4 addresses will route fine, using this method.
  - ta1243 2y ago
    > The dotted quad notation is just a human readable notation. You can’t just add another octet willy nilly. That’s exactly what ipv6 did. They added an extra 12 octets, but used hex notation (0-F) to shorten the number of characters for human readability. If that's all IPv6 did that would have been one thing. ipv6 changed tons of things, from arp to nat, dhcp to dns.
    - p_l 2y ago
      And all of them had to change because guess what, they had hardcoded v4 assumptions including "4 octets"
- eqvinox 2y ago
  Is this genuine or sarcasm? I can't tell.

rcxdude 2y ago

What kind of backward compatibility are you imagining? If you say "with ipv4 addresses", how are you imagining that would work?

TheLoafOfBread 2y ago
Keep the structure and services around IP protocol (DNS, DHCP, NAT), just with more bits for address. Do not try to reinvent the wheel and add unnecessary breaking bell and whistles which nobody asked for.
- jcranmer 2y ago
  All of these things already exist for IPv6, although I don't know how much DHCPv6 is deployed in practice.
  - baq 2y ago
    It should be deployed everywhere where IPv6 is deployed and there's an IT department if only for logging/audit.
    - kccqzy 2y ago
      Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. And I in fact agree with them. And DHCPv6 isn't needed for logging/audit: the router always has an association of MAC addresses and IPv6 addresses even if hosts assign their own addresses with SLAAC.
      - bigstrat2003 2y ago
        > Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. Which is absolutely ridiculous. Google should not be trying to dictate to their customers how to run infrastructure. If someone wants to use stateful DHCPv6 for their Android devices, that is their right and Google has no business standing in their way.

icedchai 2y ago

Can you describe how you'd make it more backwards compatible? I often see comments like this, yet nobody can work around the fact that you're limited by 32-bit source and destination headers in V4.

jedberg 2y ago
It's pretty simple. If IPv6 headers were split into two parts, where the first part was the same as IPv4, and the second part had the rest of the bits, so you had say 8 octets instead of 4. The rest of the header would look like data to an IPv4 router. So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers. Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. Old IPv4 hosts wouldn't be able to talk to IPv6 endpoints, but at least this way the user could upgrade their own stack without having to wait for their ISP, and every network in between, to also upgrade. It's pretty much carrier grade NAT but from client to client without ISP support being necessary, which is the biggest bottleneck right now.
- andrewshadura 2y ago
  This has been proposed many times already, and it actually wouldn't work.
  - jedberg 2y ago
    Why not?
    - ianburrell 2y ago
      Because the IPv4 host can't talk to new protocol hosts. IPv4 hosts can only do 32-bit addresses and don't know about the wrapping. If they did, they would be new protocol hosts. I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.

Macha 2y ago

Earlier IP migrations were done when the internet was run by universities and government bodies who felt the need to migrate to a newer standard because there was a newer standard. IPv6 took longer because the internet is now run by companies that need to see a return on investment, and as long as IPv4 was working fine for their customers, didn't see a benefit to it. It's why IPv6 adoption only started taking off when the answer to "Our projected customer growth this year is 200,000, can we have 200,000 more IPv4 addresses please?" became "No".

api 2y ago

It was created by people who were used to the Internet being an ultra high trust relatively close knit community of universities, research, government, and industry. Upgrades across the net had happened before just fine. This one should be no problem. This was around 1996, which is when the vertical growth phase took off. Too late.

dboreham 2y ago

This was deliberate: the idea was that IPng wouldn't get adopted, or even traction in the IETF, if it didn't provide additional functionality/fix perceived problems beyond just address space exhaustion. Remember also that NAT wasn't really a thing at that time. It might have existed but wasn't widely used like happened subsequently. Source: was there.

JoshTriplett 2y ago
I can certainly understand that perspective. But from today's perspective, it seems like IPv6 adoption was slowed by ideological arguments like "people should use SLAAC, not DHCP". By all means introduce a new means of obtaining addresses, but let it live or (preferably) die on its own merits, rather than attaching it and a dozen other albatrosses around IPv6's neck. If IPv6 had started from day one by saying "just add an IPv6 block to your DHCP server and let any client that understands IPv6 get an IPv6 address", that would have been an easier sell.