4 ms·

> critical flaw of IPv6 being incompatible with IPv4 What other choice do we/did we have? I've responded in the past to a different commenter, who lamented IPv

> critical flaw of IPv6 being incompatible with IPv4 What other choice do we/did we have? I've responded in the past to a different commenter, who lamented IPv6 not being backwards compatible. You can read my response[1] to that comment; essentially, I don't see a way to make IPv6 happen, aside from the introduction of a new, separate network, mostly due to the pigeonhole principle: IPv4 only has 2 ^ 32 addresses, so how do you fit the 2 ^ 128 IPv6 addresses into that scheme? You can introduce a legitimately new protocol, like v6 did. You could perhaps add a special flag, or special block of addresses, or a special option — but whatever mutation you perform on IPv4 packets to "upgrade" them, the intermediate routers would still have to understand that flag in order to properly route packets — no? And thus, since they must understand that flag, you're still upgrading the entire infrastructure, and building out a completely separate network, even if it is just IPv4.1. I do think the IPv4 sunset is far, far out in the future. There will be stragglers for a long time to come, and I'm not sure it's really worth considering when IPv6 isn't deployed to a majority of people yet. But I do think it's possible; at some point, I hope someone realizes that the maintenance of that code is benefiting so few people as to sunset it, perhaps at an ISP-ish level first. No doubt this will break somebody's workflow, though. [1]: https://news.ycombinator.com/item?id=12168656 https://news.ycombinator.com/item?id=12168656

garaetjjte 10y ago
Maybe you could add address extension to IPv4 options field. Routers non aware of this would just route packet normally to IPv4 endpoint, at which would reside gateway which looks on extended address field and routes to destination in internal network. That way upgrades would have been needed in server and client network, but intermediate routers could stay IPv4.
- icebraining 10y ago
  So you'd need to upgrade ISP routers, edge (incl. home) routers, PCs, phones and all IoT devices, along with all their software, but not backbone routers. Would that really have a significant impact? Seems doubtful.
  - catdog 10y ago
    Very doubtful indeed, backbone routers are comparably few and tend to be upgraded more frequently because of the ever rising traffic demand.
drewg123 10y ago
I actually think that a minimally extended v4, with no changes other than a different version number and 64-bit addresses, would have gone a long way towards increasing adoption. Having IPv6 as an entirely new protocol has lead to all kinds of misery. And I'm not even talking about application layer stuff, I'm talking about OSes and hardware. Hardware vendors hate it, because it is another protocol they have to deal with, which doubles ASIC testing matrixes. And don't even get me started on how evil extension headers are from a hardware point of view. The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). This lead to hardware vendors delaying support for V6. V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), and changes are applied unequally. Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I've always said that if I had a time machine, rather than shooting Hilter or John Wilkes Booth, I'd concentrate on trying to make the ethernet header 16 bytes and trying to argue for an IPv5 that was just an extended v4 without all this added complexity.
- catdog 10y ago
  > And don't even get me started on how evil extension headers are from a hardware point of view. > trying to argue for an IPv5 that was just an extended v4 without all this added complexity. > V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), On the other hand that flexibility may save us from going through that "we have to upgrade the whole Internet at once" pain again. In the end widespread v6 adoption is driven mostly by v4 address space exhaustion. At the time this got really severe some years ago the implementations in both hard and software were already pretty reasonable and widespread. Would we really be at a higher adoption rate right now with no additional reason to upgrade? (also IPv5 was already used in RFC 1819 for sth. different, that's why they jumped to 6 ;)) > The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). What about fragmentation which is entirely left to the hosts in v6? > Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I don't think such optimizations coming a bit later had a significant negative impact in v6 adoption (and if v6 adoption would have been higher it would have been implemented more equally). Also bugs get found and sorted out a lot faster if someone is actually using the code.
lisivka 10y ago
We need compatibility of nextgen IP with IPv4 in same way as 10Mb Ethernet is compatible with 100Mb Ethernet, i.e. IPv6 networks must be transparent for unmodified IPv4 traffic, without of encapsulation of any kind, to share investments, not to compete on them.
raattgift 10y ago
> What other choice do we/did we have ? Being more deliberate and serious about NAT, rather than taking the position that "NAT is evil". In particular, this would mean throwing away four assumptions about IP addresses: -- non-ephemerality (an IP address survived for long periods of time, often not even changing across reboot) -- global uniqueness (your IP address is in use only by you) -- isotropy (what you think your IP address is, is what all the parties you communicate with think your IP address is) -- non-overloading (one IP address per host, or at most one address per interface) In the years since the early 1990s when IPv6 was still being decided, the first assumption was weakened by DHCP, the second by RFC 1918, and the third by NAT. The fourth is somewhat weakened by Dual Stack IPv4 and IPv6. If instead of dealing with issues like https://www.wikiwand.com/en/Happy_Eyeballs https://www.wikiwand.com/en/Happy_Eyeballs under Dual Stack it were applied in IPv4-only settings where a host would acquire and use different addresses with different prefixes & masks, multihoming and mobility would have gotten easier faster. However, application layers that embed IPv4 addresses into them were commonplace and even today when a smartphone can swap addresses rapidly (disconnect from wifi, fall-back through 4g or the like, connect to new wifi) causing user-noticeable disruptions. IPv6 does not help in this situation because the same assumptions are in the way: addresses are long-lived, a host uses approximately one globally unique address at a time, and IPv6's "NAT is evil" foundations make using NAT more bug-prone -- and NAT involving IPv6 on at least one side of the NAT is in widespread use. CATNIP was one IPng proposal wherein there would be canonical translations among various protocols, with extensibility to add yet more protocols, that would face these problems and more like them head-on. It was rejected because the compromise SIP+PIP was "more ready" to be rolled out immediately, and taking the time to get the details of CATNIP right (or do it iteratively) would mean a delay in standardization and thus deployment. That was more than twenty years ago. Standardization was done pretty fast for IPv6... The lessons of slow and reluctant IPv6 deployment have been mis-learnt as, "we can never introduce a new network layer protocol in less than twenty years". Because (in part) isotropy and global uniqueness are taken to mean that there's no protocol translation "in the middle" or "at the edges" allowing completely uncoordinated deployment by any size site (from a backbone ISP to an individual household). That is, as with IPv6, the expectation is dual stack with one stack doing the heavy lifting, and with the other stack used only in coordination with some "upstream" or "peer" network. Finally, I think the wish to sunset IPv4 is backwards. IPv4ever should be embraced, with IPv4-only devices never needing to upgrade to talk to the parts of the Internet that no longer talk IPv4 themselves. Protocol translation and Application Layer Gatwaying are things that should be made to work well, rather than things to be called "evil". The lessons learned in doing that should be applied to progressing beyond IPv6, too.

garaetjjte 10y ago

Maybe you could add address extension to IPv4 options field. Routers non aware of this would just route packet normally to IPv4 endpoint, at which would reside gateway which looks on extended address field and routes to destination in internal network. That way upgrades would have been needed in server and client network, but intermediate routers could stay IPv4.

icebraining 10y ago
So you'd need to upgrade ISP routers, edge (incl. home) routers, PCs, phones and all IoT devices, along with all their software, but not backbone routers. Would that really have a significant impact? Seems doubtful.
- catdog 10y ago
  Very doubtful indeed, backbone routers are comparably few and tend to be upgraded more frequently because of the ever rising traffic demand.

drewg123 10y ago

I actually think that a minimally extended v4, with no changes other than a different version number and 64-bit addresses, would have gone a long way towards increasing adoption. Having IPv6 as an entirely new protocol has lead to all kinds of misery. And I'm not even talking about application layer stuff, I'm talking about OSes and hardware. Hardware vendors hate it, because it is another protocol they have to deal with, which doubles ASIC testing matrixes. And don't even get me started on how evil extension headers are from a hardware point of view. The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). This lead to hardware vendors delaying support for V6. V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), and changes are applied unequally. Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I've always said that if I had a time machine, rather than shooting Hilter or John Wilkes Booth, I'd concentrate on trying to make the ethernet header 16 bytes and trying to argue for an IPv5 that was just an extended v4 without all this added complexity.

catdog 10y ago
> And don't even get me started on how evil extension headers are from a hardware point of view. > trying to argue for an IPv5 that was just an extended v4 without all this added complexity. > V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), On the other hand that flexibility may save us from going through that "we have to upgrade the whole Internet at once" pain again. In the end widespread v6 adoption is driven mostly by v4 address space exhaustion. At the time this got really severe some years ago the implementations in both hard and software were already pretty reasonable and widespread. Would we really be at a higher adoption rate right now with no additional reason to upgrade? (also IPv5 was already used in RFC 1819 for sth. different, that's why they jumped to 6 ;)) > The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). What about fragmentation which is entirely left to the hosts in v6? > Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I don't think such optimizations coming a bit later had a significant negative impact in v6 adoption (and if v6 adoption would have been higher it would have been implemented more equally). Also bugs get found and sorted out a lot faster if someone is actually using the code.

lisivka 10y ago

We need compatibility of nextgen IP with IPv4 in same way as 10Mb Ethernet is compatible with 100Mb Ethernet, i.e. IPv6 networks must be transparent for unmodified IPv4 traffic, without of encapsulation of any kind, to share investments, not to compete on them.

raattgift 10y ago

> What other choice do we/did we have ? Being more deliberate and serious about NAT, rather than taking the position that "NAT is evil". In particular, this would mean throwing away four assumptions about IP addresses: -- non-ephemerality (an IP address survived for long periods of time, often not even changing across reboot) -- global uniqueness (your IP address is in use only by you) -- isotropy (what you think your IP address is, is what all the parties you communicate with think your IP address is) -- non-overloading (one IP address per host, or at most one address per interface) In the years since the early 1990s when IPv6 was still being decided, the first assumption was weakened by DHCP, the second by RFC 1918, and the third by NAT. The fourth is somewhat weakened by Dual Stack IPv4 and IPv6. If instead of dealing with issues like https://www.wikiwand.com/en/Happy_Eyeballs https://www.wikiwand.com/en/Happy_Eyeballs under Dual Stack it were applied in IPv4-only settings where a host would acquire and use different addresses with different prefixes & masks, multihoming and mobility would have gotten easier faster. However, application layers that embed IPv4 addresses into them were commonplace and even today when a smartphone can swap addresses rapidly (disconnect from wifi, fall-back through 4g or the like, connect to new wifi) causing user-noticeable disruptions. IPv6 does not help in this situation because the same assumptions are in the way: addresses are long-lived, a host uses approximately one globally unique address at a time, and IPv6's "NAT is evil" foundations make using NAT more bug-prone -- and NAT involving IPv6 on at least one side of the NAT is in widespread use. CATNIP was one IPng proposal wherein there would be canonical translations among various protocols, with extensibility to add yet more protocols, that would face these problems and more like them head-on. It was rejected because the compromise SIP+PIP was "more ready" to be rolled out immediately, and taking the time to get the details of CATNIP right (or do it iteratively) would mean a delay in standardization and thus deployment. That was more than twenty years ago. Standardization was done pretty fast for IPv6... The lessons of slow and reluctant IPv6 deployment have been mis-learnt as, "we can never introduce a new network layer protocol in less than twenty years". Because (in part) isotropy and global uniqueness are taken to mean that there's no protocol translation "in the middle" or "at the edges" allowing completely uncoordinated deployment by any size site (from a backbone ISP to an individual household). That is, as with IPv6, the expectation is dual stack with one stack doing the heavy lifting, and with the other stack used only in coordination with some "upstream" or "peer" network. Finally, I think the wish to sunset IPv4 is backwards. IPv4ever should be embraced, with IPv4-only devices never needing to upgrade to talk to the parts of the Internet that no longer talk IPv4 themselves. Protocol translation and Application Layer Gatwaying are things that should be made to work well, rather than things to be called "evil". The lessons learned in doing that should be applied to progressing beyond IPv6, too.