5 ms·

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.

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.