Brace yourself, IPv6 is coming(supabase.com)
supabase.com
Brace yourself, IPv6 is coming
https://supabase.com/blog/ipv6
25 comments
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.
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.
"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.
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)
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.
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.
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.
That 'one of them is destined to be unable to speak with the other' is true no matter what you do, but my point (which I here note that you seem to have ignored) is that with the method of implementation selected, there is no reason to give a shit about ipv6 unless you're a network operator, and network operators don't write client or server software. ipv6 is still a ghetto for this reason. Forcing them into one stack would have resulted in application developers having to address this or face their software stop working. Breaking ipv4 should have been the point.
> Forcing them into one stack would have resulted in application developers having to address this or face their software stop working
And what would be your solution for achieving that? Given the distributed nature of the web, it's hard to see how one can force other people to do something. They will just ignore this IPvForced6 just like how they ignored IPv6 (until they see the IPv4 address bills arriving).
Furthermore, "easing the transition to IPv6" isn't plausible IMO no matter how much you do. Just the mere fact that IPv6 addresses are larger than IPv4 addresses already set that in stone, since it necessitates the upgrade of software and hardware - and good luck convincing the programmers and netengs to update those.
And what would be your solution for achieving that? Given the distributed nature of the web, it's hard to see how one can force other people to do something. They will just ignore this IPvForced6 just like how they ignored IPv6 (until they see the IPv4 address bills arriving).
Furthermore, "easing the transition to IPv6" isn't plausible IMO no matter how much you do. Just the mere fact that IPv6 addresses are larger than IPv4 addresses already set that in stone, since it necessitates the upgrade of software and hardware - and good luck convincing the programmers and netengs to update those.
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
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...
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...
You’re asking for the impossible.
“Curse you for not magically squeezing more than 4 billion addresses into 32 bits! Curse you!”
“Curse you for not magically squeezing more than 4 billion addresses into 32 bits! Curse you!”
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.
Though interoperability is possible:
https://web.archive.org/web/20021017164820/http://cr.yp.to/p...
https://web.archive.org/web/20021017164820/http://cr.yp.to/p...
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.
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.
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.
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.
Dual stack is better than backwards compatible, in some cases.
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?
This is like "Year of Linux". Any day now it'll happen
Unlike Linux which has never gotten any significant foothold in any market so far, IPv6 is already deployed in many parts of the world[0]. In quite a few countries it is already the majority internet protocol, servicing >50% of the traffic. It is the enterprise world that is mostly lagging behind.
I don't see how they are comparable.
[0] https://stats.labs.apnic.net/ipv6
I don't see how they are comparable.
[0] https://stats.labs.apnic.net/ipv6
IPv6 doesn't really solve the problem of address exhaustion until IPv6 addresses are first class citizens which will only happen when we do not need to rely on IPv4 addresses anymore.
I was expecting this article to be from 2010 or something.
I was just going to comment, I have heard this before in a decade far far away
If only v6 wasnt so ugly to look at :(
My Chrome/Firefox extension makes IPv6 look nice: https://github.com/pmarks-net/ipvfoo