4 ms·

Yeah any “solution” to backwards compatibility I have heard involves updating the address scheme. And to get that to work you need to update your networking equ

Yeah any “solution” to backwards compatibility I have heard involves updating the address scheme. And to get that to work you need to update your networking equipment, software, and start redesigning your network to accommodate the new address scheme and guess what, that’s an IPV6 migration.

tsimionescu 2y ago
If you only had to update the software for a new IP version and a longer address, and maybe even a bit of cleanup in the headers, adoption could have been much quicker. As it is, virtually everything about networking is different in the IPv6 world. That has significantly complicated adoption for everyone, arguably needlessly. And not everyone who says they support IPv6 even actually supports everything that the designers expect (e.g. lots of ISPs give you a /64 or even a /128 for your whole network). Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
- justsomehnguy 2y ago
  > If you only had to update the software for a new IP version and a longer address By 2005 all the major 'software' (read: general purpose network operating systems) had the software for IPv6 already. If your application is hardcoded to use IPv4 addresses then you need to rewrite it anyway and no amount of IPv5 would change that. More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work. But the most important part here is what were (and I can bet my pumpkin latte - still are) incapable of anything of not IPv4 - because it's the hardware, which routed, NATed, checksummed all that traffic. You just couldn't slap your IPv5 there by exactly the same reason you couldn't slap IPv6 there - you needed to replace the hardware. > As it is, virtually everything about networking is different in the IPv6 world Sorry, but no. The basics, ie the networking, is exactly the same. Yes, there are some nuances, like using link-local addresses for the gateways, which absolutely, totally, makes sense after a 15 minute reading. But overall it's just another technology, not harder then everything else out there, including IPv4 itself. > That has significantly complicated adoption for everyone, arguably needlessly sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. Every year there is something new and you need to learn it[0]. Sometimes to abandon and forget it after a couple of years.[1] IPv6 is not a rocket-neuroscience, just another set of RFC's and guides. If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.[2] > And not everyone who says they support IPv6 even actually supports everything that the designers expect Now you argue what with 'IPv5' this wouldn't happen. > Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface. I wrote about it - it's the problem of the software. I had multiple IPv4 addresses on the same interface many, many times. If that software breaks with multiple IPv6 addresses on the one interface then it would break the same with mulltiple addresses of IPv4 and 'IPv5'. PS I have a small fleet of PowerConnect 5500 and 8000 switches. They are old, so old 5500 has SSH bolted onto a Telnet server. Yet they did already support IPv6 by 2010. It's already passed more years since the release of 8000 (2010 - 2024) than between IPv6 IETF proposal and release of 8000 (1998 - 2010). Slow adoption has nothing to do with IPv6 itself, and no IPv5 or whatever would made it faster. [0] if anything it's slower now [1] MS Exchange for example. Do you know X.400? I do not, anymore. But for some years I needed to know and I learned it. [2] Take this from someone who did and does both.
  - tsimionescu 2y ago
    > More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work. This is only true if you use DNS for every network request. That has never been realistic for any home network. > sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. This attitude is part of why many people love IPv6 evangelism. > If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement. "Easier than IPSec" is not exactly a ringing endorsement. And note that IPv6 doesn't replace any of this. You still need to know the IPv4 way, and the IPv6 way, and IPSec in both flavors etc. Sure, it's not neuroscience, but it is needlessly more work, and most people like to not fuss with more work if they can avoid it. Especially when it's entirely duplicated, since, again, you can't drop IPv4 support, you still need to do CGNAT and all that, and then add IPv6 management on top.
    - JackSlateur 2y ago
      He is right, tho : many network guys are .. just dumb. And I know what I am talking about: I am one of them :) People who fails to adapt because "it is new" has no place in IT. The only skill required to work in IT is a great ability to adapt.
      - tsimionescu 2y ago
        But that's just it: it's not failing to adapt. It's avoiding doing too much extra work. If IPv6 were a simple replacement for all things IPv4, and you simply had to learn IPv6 instead of IPv4, no one would complain. But you need to learn IPv6 in addition to IPv4, in almost all areas of networking. The complexity adds up, it isn't replaced.
        JackSlateur 2y ago
        Well, yes, just like I learned k8s but still know iproute2 and I still use tcpdump and curl despite knowing how to debug http requests using the web console And I still manage ipsec tunnels and NAT and I still have to know things about OSPF, even tho I learned BGP more than 10 years ago In the real world, you cannot simply replace things in the blink of a eye. This is not possible unless you are working in your own, fully-managed environment, never talking to other people (which is a good but scarse position)
- deleted 2y ago
  [deleted]
hot_gril 2y ago
Updating the addressing scheme wasn't necessary. If I have 1.2.3.4 and I want to flip on ipv6, I should still be reachable at 1.2.3.4, just using the ipv6 header instead of v4. The hardware/software support is already there too.

tsimionescu 2y ago

If you only had to update the software for a new IP version and a longer address, and maybe even a bit of cleanup in the headers, adoption could have been much quicker. As it is, virtually everything about networking is different in the IPv6 world. That has significantly complicated adoption for everyone, arguably needlessly. And not everyone who says they support IPv6 even actually supports everything that the designers expect (e.g. lots of ISPs give you a /64 or even a /128 for your whole network). Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.

justsomehnguy 2y ago
> If you only had to update the software for a new IP version and a longer address By 2005 all the major 'software' (read: general purpose network operating systems) had the software for IPv6 already. If your application is hardcoded to use IPv4 addresses then you need to rewrite it anyway and no amount of IPv5 would change that. More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work. But the most important part here is what were (and I can bet my pumpkin latte - still are) incapable of anything of not IPv4 - because it's the hardware, which routed, NATed, checksummed all that traffic. You just couldn't slap your IPv5 there by exactly the same reason you couldn't slap IPv6 there - you needed to replace the hardware. > As it is, virtually everything about networking is different in the IPv6 world Sorry, but no. The basics, ie the networking, is exactly the same. Yes, there are some nuances, like using link-local addresses for the gateways, which absolutely, totally, makes sense after a 15 minute reading. But overall it's just another technology, not harder then everything else out there, including IPv4 itself. > That has significantly complicated adoption for everyone, arguably needlessly sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. Every year there is something new and you need to learn it[0]. Sometimes to abandon and forget it after a couple of years.[1] IPv6 is not a rocket-neuroscience, just another set of RFC's and guides. If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.[2] > And not everyone who says they support IPv6 even actually supports everything that the designers expect Now you argue what with 'IPv5' this wouldn't happen. > Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface. I wrote about it - it's the problem of the software. I had multiple IPv4 addresses on the same interface many, many times. If that software breaks with multiple IPv6 addresses on the one interface then it would break the same with mulltiple addresses of IPv4 and 'IPv5'. PS I have a small fleet of PowerConnect 5500 and 8000 switches. They are old, so old 5500 has SSH bolted onto a Telnet server. Yet they did already support IPv6 by 2010. It's already passed more years since the release of 8000 (2010 - 2024) than between IPv6 IETF proposal and release of 8000 (1998 - 2010). Slow adoption has nothing to do with IPv6 itself, and no IPv5 or whatever would made it faster. [0] if anything it's slower now [1] MS Exchange for example. Do you know X.400? I do not, anymore. But for some years I needed to know and I learned it. [2] Take this from someone who did and does both.
- tsimionescu 2y ago
  > More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work. This is only true if you use DNS for every network request. That has never been realistic for any home network. > sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. This attitude is part of why many people love IPv6 evangelism. > If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement. "Easier than IPSec" is not exactly a ringing endorsement. And note that IPv6 doesn't replace any of this. You still need to know the IPv4 way, and the IPv6 way, and IPSec in both flavors etc. Sure, it's not neuroscience, but it is needlessly more work, and most people like to not fuss with more work if they can avoid it. Especially when it's entirely duplicated, since, again, you can't drop IPv4 support, you still need to do CGNAT and all that, and then add IPv6 management on top.
  - JackSlateur 2y ago
    He is right, tho : many network guys are .. just dumb. And I know what I am talking about: I am one of them :) People who fails to adapt because "it is new" has no place in IT. The only skill required to work in IT is a great ability to adapt.
    - tsimionescu 2y ago
      But that's just it: it's not failing to adapt. It's avoiding doing too much extra work. If IPv6 were a simple replacement for all things IPv4, and you simply had to learn IPv6 instead of IPv4, no one would complain. But you need to learn IPv6 in addition to IPv4, in almost all areas of networking. The complexity adds up, it isn't replaced.
      - JackSlateur 2y ago
        Well, yes, just like I learned k8s but still know iproute2 and I still use tcpdump and curl despite knowing how to debug http requests using the web console And I still manage ipsec tunnels and NAT and I still have to know things about OSPF, even tho I learned BGP more than 10 years ago In the real world, you cannot simply replace things in the blink of a eye. This is not possible unless you are working in your own, fully-managed environment, never talking to other people (which is a good but scarse position)
deleted 2y ago
[deleted]

hot_gril 2y ago

Updating the addressing scheme wasn't necessary. If I have 1.2.3.4 and I want to flip on ipv6, I should still be reachable at 1.2.3.4, just using the ipv6 header instead of v4. The hardware/software support is already there too.