3 ms·

> wildly different network stack that happens to offer similar enough TCP-like abstractions that user-level code often is only slightly affected, but everything

> wildly different network stack that happens to offer similar enough TCP-like abstractions that user-level code often is only slightly affected, but everything else in the stack is profoundly affected. TCP itself hasn't changed. TCP is a protocol that sits on top of IP (version 4 or 6). Same with UDP. Yes the IP stack has changed, that kind of thing happens when you bump the version number ;-) So from an application standpoint TCP/UDP haven't changed, the only thing that has changed is the structure to set up the IP connection, and even that is hidden away for most users (getaddrinfo() deals with most of the complexities for developers). Percent signs in an address are only used on link-local segments with link-local addresses, as they are the only way to distinguish what network interface to use. In almost all cases where you are dealing with IPv6 you can completely ignore that aspect because you won't have to deal with it, especially as an application developer trying to make connections to IPv6 hosts, or even starting servers/listening for incoming connections. > The advantage of the "just extend it" plan is that it would have been that easy. I disagree. This still requires that the entire IP stack be upgraded to support it, applications still need to update all of their network handling code to deal with the extensions, we'd be in exactly the same boat.

jerf 11y ago
As I said, application programmers just using TCP have way less to deal with than all the other hardware in the stack. The point is all the other hardware has much larger changes to make than just "extending an address". It's a brand new protocol, not an extension. I've been involved in some relatively trivial extension of application-level network devices to IPv6, and even that was a surprisingly large nightmare because you embed all these assumptions about addresses everywhere without even realizing it. Not just "they're a 4-byte integer"; one big one you embed without even realizing it pretty deeply is that "A network address is one type." In dual-stack code, you no longer have "an address". You have two types. That's just an example of the problem. I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not, because I've seen even within a network company a lot of severe underestimations of the difficulty. (Some of these things are much easier when you write new code for IPv4+IPv6, which is why I say convert. Of course if you write new code on an abstraction layer that already solved this problem it's easier.) IPv6 is not IPv4, quite profoundly. It's not just addressing changes. Converting to IPv6 is not just "replacing all your gear", it is rewriting foundational aspects of all that gear and a non-trivial amount of the software that uses it. Not mere surface aspects like addressing schemes. This all looks fine and dandy from 30,000 feet, but when you're on the ground, it's a really hard transition.
- X-Istence 11y ago
  > I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not Yes, to the former, only device updates I've done was for a proprietary appliance and that was mainly get new Linux kernel built and then upgrade software. I have not had to deal with silicon level stuff. I updated various proprietary applications over the course of a week to bind and function over IPv6. Logging was an issue with the new addresses since assumptions were made about IP length, but those were quickly fixed. Clients that were using old functions instead of getaddrinfo() were easily updated, and in general my experience is that clients don't really care so much about what IP version they use to connect. Once again logging functions assumed that IP's were only IPv4 structs, so some changes and they could log either one. Overall the transition was simple, the applications already supported binding to multiple addresses, so having it be dual stack ready (binding both IPv4 and IPv6 was simple), and those that didn't took a little longer but ultimately wasn't that much more difficult to get them upgraded. I pay my network vendors to get me the latest standards, getting all of this right on their end may have been a lot of work, but ultimately that is a one-time cost of doing business, and in most cases I am paying for them to support my use cases.
- azernik 11y ago
  I have (worked at a networking equipment company on IPv6 support, briefly). The few bits that are totally different (ARP-to-ND, for example) are all very small bits of code. The really hairy stuff was always the dual-stack - the assumption of a single IP instance running over any given layer-2 network is baked deeply into most systems, and changing that is a royal pain. That plus the renumbering of constants (ugh ICMPv6). The way I explained it to people was: IPv6 is exactly the same as IPv4, but with incompatible field sizes and constants, different (but usually MUCH simpler) address configuration, and no hop-by-hop fragmentation (oh frabjous day!).

jerf 11y ago

As I said, application programmers just using TCP have way less to deal with than all the other hardware in the stack. The point is all the other hardware has much larger changes to make than just "extending an address". It's a brand new protocol, not an extension. I've been involved in some relatively trivial extension of application-level network devices to IPv6, and even that was a surprisingly large nightmare because you embed all these assumptions about addresses everywhere without even realizing it. Not just "they're a 4-byte integer"; one big one you embed without even realizing it pretty deeply is that "A network address is one type." In dual-stack code, you no longer have "an address". You have two types. That's just an example of the problem. I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not, because I've seen even within a network company a lot of severe underestimations of the difficulty. (Some of these things are much easier when you write new code for IPv4+IPv6, which is why I say convert. Of course if you write new code on an abstraction layer that already solved this problem it's easier.) IPv6 is not IPv4, quite profoundly. It's not just addressing changes. Converting to IPv6 is not just "replacing all your gear", it is rewriting foundational aspects of all that gear and a non-trivial amount of the software that uses it. Not mere surface aspects like addressing schemes. This all looks fine and dandy from 30,000 feet, but when you're on the ground, it's a really hard transition.

X-Istence 11y ago
> I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not Yes, to the former, only device updates I've done was for a proprietary appliance and that was mainly get new Linux kernel built and then upgrade software. I have not had to deal with silicon level stuff. I updated various proprietary applications over the course of a week to bind and function over IPv6. Logging was an issue with the new addresses since assumptions were made about IP length, but those were quickly fixed. Clients that were using old functions instead of getaddrinfo() were easily updated, and in general my experience is that clients don't really care so much about what IP version they use to connect. Once again logging functions assumed that IP's were only IPv4 structs, so some changes and they could log either one. Overall the transition was simple, the applications already supported binding to multiple addresses, so having it be dual stack ready (binding both IPv4 and IPv6 was simple), and those that didn't took a little longer but ultimately wasn't that much more difficult to get them upgraded. I pay my network vendors to get me the latest standards, getting all of this right on their end may have been a lot of work, but ultimately that is a one-time cost of doing business, and in most cases I am paying for them to support my use cases.
azernik 11y ago
I have (worked at a networking equipment company on IPv6 support, briefly). The few bits that are totally different (ARP-to-ND, for example) are all very small bits of code. The really hairy stuff was always the dual-stack - the assumption of a single IP instance running over any given layer-2 network is baked deeply into most systems, and changing that is a royal pain. That plus the renumbering of constants (ugh ICMPv6). The way I explained it to people was: IPv6 is exactly the same as IPv4, but with incompatible field sizes and constants, different (but usually MUCH simpler) address configuration, and no hop-by-hop fragmentation (oh frabjous day!).