4 ms·

Great example of how fixing things "the correct way" does not seem to work sometimes. They added those new addresses that can store more information.. but thi

by rvba 4mo ago

Great example of how fixing things "the correct way" does not seem to work sometimes. They added those new addresses that can store more information.. but this requires a rewrite of old software to make it work. If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.

noduerme 4mo ago
I never heard this idea before, but more octets would be a lot prettier!!
- BadBadJellyBean 4mo ago
  They added 12 more octets. I mean we could have written IPv6 addresses in the old format but I don't think that 42.0.20.80.64.1.192.15.0.0.0.0.0.0.0.113 is easier to remember than 2a00:1450:4001:c0f::71 (or 2a00:1450:4001:0c0f:0000:0000:0000:0071)
  - rvba 4mo ago
    Tell that via phone to your grandmother.
    - BadBadJellyBean 4mo ago
      Why would I do that?
  - mahboi 4mo ago
    Exactly, it'd be horrible. They picked the right format for v6. The problem isn't the space size, it's the entropy. V6 addrs are randomly spread, but if you were using the most significant bytes first, you could have something like 42.0.20.80.64.
- Hendrikto 4mo ago
  You have not heard if before, because that is the most naive and stupid take imaginable. It is the “let them eat cake” of networking. It does not work like that. Put extra octets where exactly? Where would a hardware router put the extra bytes? Where would software with 32 bit buffers? You would still need to replace all of the software and hardware and have the exact same problem.
  - rvba 4mo ago
    Your hardware can do Natural Address Translation. More octets is basically taking this idea further, to make a "big NAT".
    - BadBadJellyBean 4mo ago
      You are aware that packets don't magically appear at the server side when sent by a client, right? All packets have to be routed to the destination by several routers. All these have to understand the full address to route the packet. The IPv4 header is strictly defined though. It says 32 bits for the source and 32 bits for the target. If you change anything about that all IP parsers will go haywire. If you put the information somewhere else, every router that doesn't understand that will send it somewhere else. Every client, server, and router, every device that uses the address needs to understand where it comes from and where it's going. That means all the software needs to understand the protocol. So instead of having incompatible implementations live within the same protocol and make a lot of chaos it's better to have a new separate protocol that can be implemented gradually. Now the distinction is between having or not having IPv6 connectivity and my package on IPv4 goes no where because it hit a router that doesn't understand the extension.
- inigyou 4mo ago
  Are you just talking about how you write the addresses or are you talking about the actual protocol? The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more. If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.
johannes1234321 4mo ago
Software availability isn't really the problem. For most software there was no change at all ("connect to that host" or "listen to any device" and operating system will handle details), most software which needed adaption had it for a while (picking up a devices explicitly, handling of IPv6 addressees, ...) while maybe not equally good (missing GUI improvements for better handling of IPV6 addresses) The problems, as I observe, are more in network infrastructure, routing, etc.
BadBadJellyBean 4mo ago
There is no space to put the additional octets. Supporting this would have needed a rewrite anyways. Nothing won there. They took that as a chance to improve the protocol overall.
inigyou 4mo ago
Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.
- mkj 4mo ago
  getaddrinfo was added after ipv6. Software had to be rewritten to use getaddrinfo. Prior to that programs used gethostbyname() etc, which only works with ipv4.
throw0101a 4mo ago
> If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work. In every fucking IPv6 thread this "just add more addresses" idea comes up. There is no "just" in expanding the address space: """ Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately: 1. You have to change the version number. 2. You have to add new code to handle the new version. Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So, 3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introduction%20and%20Foreword/Why%20IPv6%20is%20so%20complicated.md https://github.com/becarpenter/book6/blob/main/01.%20Introdu... Any IPv4+ idea that "just" adds more address bits will same issues we've faced with IPv6.
- CableNinja 4mo ago
  The issue the GP is making is that rather than devising a whole new protocol altogether, including resolution and assignments, other things like that, adoption likely would have been much faster and wider. Had the original plan been simply "extend address space" instead of "extend address space and while we are at it revamp and rewrite every part of the whole scheme including assignment, discovery, and everything else we see wrong with ipv4"; we would be in a much better place. Adding extra address bytes would of course require new changes across the internet, but that change would be easier to swallow compared to having to rip and replace large swaths of processes to make ipv6 work because of all of the other changes that came with ipv6. Also, the stupid idea of turning addresses to hex as the default, and more specifically the dumb :: shortening methods really made it confusing for everyone and didnt help at all in the efforts.

by rvba 4mo ago

noduerme 4mo ago

I never heard this idea before, but more octets would be a lot prettier!!

BadBadJellyBean 4mo ago
They added 12 more octets. I mean we could have written IPv6 addresses in the old format but I don't think that 42.0.20.80.64.1.192.15.0.0.0.0.0.0.0.113 is easier to remember than 2a00:1450:4001:c0f::71 (or 2a00:1450:4001:0c0f:0000:0000:0000:0071)
- rvba 4mo ago
  Tell that via phone to your grandmother.
  - BadBadJellyBean 4mo ago
    Why would I do that?
- mahboi 4mo ago
  Exactly, it'd be horrible. They picked the right format for v6. The problem isn't the space size, it's the entropy. V6 addrs are randomly spread, but if you were using the most significant bytes first, you could have something like 42.0.20.80.64.
Hendrikto 4mo ago
You have not heard if before, because that is the most naive and stupid take imaginable. It is the “let them eat cake” of networking. It does not work like that. Put extra octets where exactly? Where would a hardware router put the extra bytes? Where would software with 32 bit buffers? You would still need to replace all of the software and hardware and have the exact same problem.
- rvba 4mo ago
  Your hardware can do Natural Address Translation. More octets is basically taking this idea further, to make a "big NAT".
  - BadBadJellyBean 4mo ago
    You are aware that packets don't magically appear at the server side when sent by a client, right? All packets have to be routed to the destination by several routers. All these have to understand the full address to route the packet. The IPv4 header is strictly defined though. It says 32 bits for the source and 32 bits for the target. If you change anything about that all IP parsers will go haywire. If you put the information somewhere else, every router that doesn't understand that will send it somewhere else. Every client, server, and router, every device that uses the address needs to understand where it comes from and where it's going. That means all the software needs to understand the protocol. So instead of having incompatible implementations live within the same protocol and make a lot of chaos it's better to have a new separate protocol that can be implemented gradually. Now the distinction is between having or not having IPv6 connectivity and my package on IPv4 goes no where because it hit a router that doesn't understand the extension.
inigyou 4mo ago
Are you just talking about how you write the addresses or are you talking about the actual protocol? The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more. If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.

johannes1234321 4mo ago

Software availability isn't really the problem. For most software there was no change at all ("connect to that host" or "listen to any device" and operating system will handle details), most software which needed adaption had it for a while (picking up a devices explicitly, handling of IPv6 addressees, ...) while maybe not equally good (missing GUI improvements for better handling of IPV6 addresses) The problems, as I observe, are more in network infrastructure, routing, etc.

BadBadJellyBean 4mo ago

There is no space to put the additional octets. Supporting this would have needed a rewrite anyways. Nothing won there. They took that as a chance to improve the protocol overall.

inigyou 4mo ago

Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.

mkj 4mo ago
getaddrinfo was added after ipv6. Software had to be rewritten to use getaddrinfo. Prior to that programs used gethostbyname() etc, which only works with ipv4.

throw0101a 4mo ago

> If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work. In every fucking IPv6 thread this "just add more addresses" idea comes up. There is no "just" in expanding the address space: """ Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately: 1. You have to change the version number. 2. You have to add new code to handle the new version. Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So, 3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introduction%20and%20Foreword/Why%20IPv6%20is%20so%20complicated.md https://github.com/becarpenter/book6/blob/main/01.%20Introdu... Any IPv4+ idea that "just" adds more address bits will same issues we've faced with IPv6.

CableNinja 4mo ago
The issue the GP is making is that rather than devising a whole new protocol altogether, including resolution and assignments, other things like that, adoption likely would have been much faster and wider. Had the original plan been simply "extend address space" instead of "extend address space and while we are at it revamp and rewrite every part of the whole scheme including assignment, discovery, and everything else we see wrong with ipv4"; we would be in a much better place. Adding extra address bytes would of course require new changes across the internet, but that change would be easier to swallow compared to having to rip and replace large swaths of processes to make ipv6 work because of all of the other changes that came with ipv6. Also, the stupid idea of turning addresses to hex as the default, and more specifically the dumb :: shortening methods really made it confusing for everyone and didnt help at all in the efforts.