6 ms·

I still curse the IPv6 designers for not making it backward compatible with IPv4. IPv6 is definitely better designed but the lack of backwards compatibility ma

I still curse the IPv6 designers for not making it backward compatible with IPv4. IPv6 is definitely better designed but the lack of backwards compatibility makes moving to it an absolute bear. I know the designers thought the transition would only take a couple of years but almost 30 years later... here we are.

bauruine 3y ago
It is backwards compatible. There are multiple ways to connect to an IPv4 host with an IPv6 only host. Many mobile networks are IPv6 only. If you want it the other way around. How should that work?
- commandersaki 3y ago
  ipv4->ipv6 with anycast tunnelling.
  - p1mrx 3y ago
    https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4
jiggawatts 3y ago
You’re asking for the impossible. “Curse you for not magically squeezing more than 4 billion addresses into 32 bits! Curse you!”
- commandersaki 3y ago
  Though interoperability is possible: https://web.archive.org/web/20021017164820/http://cr.yp.to/proto/ipv6.html https://web.archive.org/web/20021017164820/http://cr.yp.to/p...
  - jiggawatts 3y ago
    That article is from 2002, and arguments like that have been shot down repeatedly since then. It's a bit long-winded, but the essential argument is that IPv6 introduces a breaking change by definition -- more addresses than IPv4 supported. That's the point. Either you abandon this benefit, or break direct compatibility with IPv4. It's possible to proxy, or tunnel over IPv4, and there a few corner cases that "might" work, but the general case simply cannot. E.g.: If you support IPv6 -> IPv4 translation, then this must occur either in the host, or on the first-hop router, which must also become highly stateful so that it can return the traffic to the correct IPv6 host. This essentially means that you have IPv4 + IPv6 coexisting side-by-side either on the host or its immediate upstream. This is literally dual-stack! That's why this is the solution that has been adopted by the industry. It works. Everything else doesn't. Whatever else you're about to suggest has a counter-example where it just won't work. There aren't two toy hosts on the Internet, there are billions. There aren't a couple of routers under your control, there are hundreds of millions, most of which are replaced infrequently. Solutions for migrations must cater for every bizarre scenario, not just simplified ones required to make that solution work. Solutions must not require highly stateful routers, because at telco scale, that just doesn't work. Etc... These ideas have been discussed at length by experts in the field, and have been shot down decades ago.
    - commandersaki 3y ago
      Yet the issues they brought up still persist today and are a sobering indictment why IPv6 (as IPng) fail to reach the objective it originally set forth. Also, the link I posted doesn't involve highly stateful routers. It's talking about getting IPv4 clients that is IPv6 aware being able to IPv6 hosts without the involvement of an IPv6 gateway aside from Anycast gateway that could be outside of the balliwick of the client. Something tells me you don't understand what was being proposed.
- BingSwenSun 3y ago
  Well, IPswen can do this trick in a relatively simple way, and easily "squeezes" the whole IPv4 address space into its shortest length "level 0" base address space. The secret is simple: yes, variable length encoding. You may refer to the above reply for details.
orangeboats 3y ago
I challenge you to send a packet from 256.0.0.0 to any current IPv4 host. "But IPv4 only ranges from 0.0.0.0 to 255.255.255.255"? Then congratulations on getting the point - it's pretty much guaranteed that any IPvNext address will have more bits than IPv4, therefore any IPvNext protocol is pretty much guaranteed to be backwards incompatible with IPv4. IPv4 hosts simply cannot accept a packet nor send back a reply to IPvNext hosts, unless you rely on a middleman that does the translation between the two worlds.
- orangeboats 3y ago
  To really drive the point home, representing an IPv6 address in the same way as an IPv4 address (4 dot-separated numbers) would make it look like this: 536939960.3187088857.1487198345.2501756647 (this is 2001:db8:bdf7:1dd9:58a4:d889:951d:c6e7) You can't even squeeze that into a `sockaddr_in`.
- stonogo 3y ago
  The entirety of ipv4 could have been embedded in ipv6 from the start. Instead the standards were written with no way for the two networks to interconnect, embedding ipv4 addresses into the link-local space within ipv6. This was a ridiculous decision, one of many that disincentivized adoption. ipv6 should have been designed with ease of transition from the beginning, instead of requiring dual-stack with a flag day that may never come.
  - orangeboats 3y ago
    Did you just ignore my comment before making this reply? I already explained why it makes no sense to interconnect those two protocols, when one of them is destined to be unable to speak with the other. Furthermore, depending on your definition of "embedding" you can pretty much already do that now. [::ffff:192.168.0.1] gives you the ability to use a socket for both IPv4 and IPv6 connections. [64:ff9b::192.168.0.1] facilitates the translation from IPv6 to IPv4.
    - stonogo 3y ago
rubatuga 3y ago
Dual stack is better than backwards compatible, in some cases.
BingSwenSun 3y ago
OK. Now there is a compatible "next generation IPv4", nick name IPswen. For details, you may refer to this tweet? https://twitter.com/BingSwenSun/status/1738513794933182671 https://twitter.com/BingSwenSun/status/1738513794933182671 What's notable is that IPswen is bidirectionally compatible with IPv4, meaning the two can interwork when the addresses are limited in the "Base Address Space" (the level 0 subspace of IPswen), much like the back and forward compatibility between color TV vs. black-and-white TV, or monophonic broadcasting vs. stereo broadcasting. IPswen is a relatively new idea and still under development. As the history of networking and communications is replete with failures and technological disasters, it may be quite interesting to see how far it will actually go...

bauruine 3y ago

It is backwards compatible. There are multiple ways to connect to an IPv4 host with an IPv6 only host. Many mobile networks are IPv6 only. If you want it the other way around. How should that work?

commandersaki 3y ago
ipv4->ipv6 with anycast tunnelling.
- p1mrx 3y ago
  https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4

jiggawatts 3y ago

You’re asking for the impossible. “Curse you for not magically squeezing more than 4 billion addresses into 32 bits! Curse you!”

commandersaki 3y ago
Though interoperability is possible: https://web.archive.org/web/20021017164820/http://cr.yp.to/proto/ipv6.html https://web.archive.org/web/20021017164820/http://cr.yp.to/p...
- jiggawatts 3y ago
  That article is from 2002, and arguments like that have been shot down repeatedly since then. It's a bit long-winded, but the essential argument is that IPv6 introduces a breaking change by definition -- more addresses than IPv4 supported. That's the point. Either you abandon this benefit, or break direct compatibility with IPv4. It's possible to proxy, or tunnel over IPv4, and there a few corner cases that "might" work, but the general case simply cannot. E.g.: If you support IPv6 -> IPv4 translation, then this must occur either in the host, or on the first-hop router, which must also become highly stateful so that it can return the traffic to the correct IPv6 host. This essentially means that you have IPv4 + IPv6 coexisting side-by-side either on the host or its immediate upstream. This is literally dual-stack! That's why this is the solution that has been adopted by the industry. It works. Everything else doesn't. Whatever else you're about to suggest has a counter-example where it just won't work. There aren't two toy hosts on the Internet, there are billions. There aren't a couple of routers under your control, there are hundreds of millions, most of which are replaced infrequently. Solutions for migrations must cater for every bizarre scenario, not just simplified ones required to make that solution work. Solutions must not require highly stateful routers, because at telco scale, that just doesn't work. Etc... These ideas have been discussed at length by experts in the field, and have been shot down decades ago.
  - commandersaki 3y ago
    Yet the issues they brought up still persist today and are a sobering indictment why IPv6 (as IPng) fail to reach the objective it originally set forth. Also, the link I posted doesn't involve highly stateful routers. It's talking about getting IPv4 clients that is IPv6 aware being able to IPv6 hosts without the involvement of an IPv6 gateway aside from Anycast gateway that could be outside of the balliwick of the client. Something tells me you don't understand what was being proposed.
BingSwenSun 3y ago
Well, IPswen can do this trick in a relatively simple way, and easily "squeezes" the whole IPv4 address space into its shortest length "level 0" base address space. The secret is simple: yes, variable length encoding. You may refer to the above reply for details.

orangeboats 3y ago

I challenge you to send a packet from 256.0.0.0 to any current IPv4 host. "But IPv4 only ranges from 0.0.0.0 to 255.255.255.255"? Then congratulations on getting the point - it's pretty much guaranteed that any IPvNext address will have more bits than IPv4, therefore any IPvNext protocol is pretty much guaranteed to be backwards incompatible with IPv4. IPv4 hosts simply cannot accept a packet nor send back a reply to IPvNext hosts, unless you rely on a middleman that does the translation between the two worlds.

orangeboats 3y ago
To really drive the point home, representing an IPv6 address in the same way as an IPv4 address (4 dot-separated numbers) would make it look like this: 536939960.3187088857.1487198345.2501756647 (this is 2001:db8:bdf7:1dd9:58a4:d889:951d:c6e7) You can't even squeeze that into a `sockaddr_in`.
stonogo 3y ago
The entirety of ipv4 could have been embedded in ipv6 from the start. Instead the standards were written with no way for the two networks to interconnect, embedding ipv4 addresses into the link-local space within ipv6. This was a ridiculous decision, one of many that disincentivized adoption. ipv6 should have been designed with ease of transition from the beginning, instead of requiring dual-stack with a flag day that may never come.
- orangeboats 3y ago
  Did you just ignore my comment before making this reply? I already explained why it makes no sense to interconnect those two protocols, when one of them is destined to be unable to speak with the other. Furthermore, depending on your definition of "embedding" you can pretty much already do that now. [::ffff:192.168.0.1] gives you the ability to use a socket for both IPv4 and IPv6 connections. [64:ff9b::192.168.0.1] facilitates the translation from IPv6 to IPv4.
  - stonogo 3y ago

rubatuga 3y ago

Dual stack is better than backwards compatible, in some cases.

BingSwenSun 3y ago

OK. Now there is a compatible "next generation IPv4", nick name IPswen. For details, you may refer to this tweet? https://twitter.com/BingSwenSun/status/1738513794933182671 https://twitter.com/BingSwenSun/status/1738513794933182671 What's notable is that IPswen is bidirectionally compatible with IPv4, meaning the two can interwork when the addresses are limited in the "Base Address Space" (the level 0 subspace of IPswen), much like the back and forward compatibility between color TV vs. black-and-white TV, or monophonic broadcasting vs. stereo broadcasting. IPswen is a relatively new idea and still under development. As the history of networking and communications is replete with failures and technological disasters, it may be quite interesting to see how far it will actually go...