4 ms·

> 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 / proba

> 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.
mahboi 4mo ago
Yes, we want ipv5 that just does 1, 2, 3 instead of ipv6 which does the most complicated variants of those and more. We didn't have requirements 4. change all the pre-existing addresses 5. make addresses randomly assigned 6. make routers accept inbound connections by default 7. give every device its own public IP by default. Ipv6 did those anyway. Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.
- tolien 4mo ago
  > 5. make addresses randomly assigned and > 7. give every device its own public IP by default. Both of these are optional. Don’t want them? Don’t use them - if you don’t configure them, it won’t happen. > 6. make routers accept inbound connections by default That’s not a new feature with v6. > Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me. Now you (and everything in between) have to be able to handle packets addressed to 8.8.8.8 and 8.8.8.8.0.0.0.0, so you’ve done point 4 without knowing it.
  - mahboi 4mo ago
    No I know it's point 4, that was the point. You can do forwards compatibility that way.
    - tolien 4mo ago
      > We didn't have requirements 4. change all the pre-existing addresses So your alternative does something you said you didn’t want, while being worse than the original?
      - mahboi 4mo ago
        Oh I mixed it up with 3. Yes you don't need #4. I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1, so it's 1:1 but not onto. Instead v6 did completely new /64s with random addrs inside, no association with the v4 addrs. About the others being optional, no they aren't really, because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway. Ipv6 spec also says that a router could either default allow in or not via its firewall. In reality it's usually default deny, but not always, hence the freakouts people have about security in v6. V4 spec doesn't know about NAT, but in real life the answer is no you don't get inbound connections or even a publicly routable address unless you deliberately configured that.
tolien 4mo ago
If anything demonstrates the Dunning-Kruger effect on this forum, it’s the “just add more bits” crowd.

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.

mahboi 4mo ago

Yes, we want ipv5 that just does 1, 2, 3 instead of ipv6 which does the most complicated variants of those and more. We didn't have requirements 4. change all the pre-existing addresses 5. make addresses randomly assigned 6. make routers accept inbound connections by default 7. give every device its own public IP by default. Ipv6 did those anyway. Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.

tolien 4mo ago
> 5. make addresses randomly assigned and > 7. give every device its own public IP by default. Both of these are optional. Don’t want them? Don’t use them - if you don’t configure them, it won’t happen. > 6. make routers accept inbound connections by default That’s not a new feature with v6. > Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me. Now you (and everything in between) have to be able to handle packets addressed to 8.8.8.8 and 8.8.8.8.0.0.0.0, so you’ve done point 4 without knowing it.
- mahboi 4mo ago
  No I know it's point 4, that was the point. You can do forwards compatibility that way.
  - tolien 4mo ago
    > We didn't have requirements 4. change all the pre-existing addresses So your alternative does something you said you didn’t want, while being worse than the original?
    - mahboi 4mo ago
      Oh I mixed it up with 3. Yes you don't need #4. I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1, so it's 1:1 but not onto. Instead v6 did completely new /64s with random addrs inside, no association with the v4 addrs. About the others being optional, no they aren't really, because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway. Ipv6 spec also says that a router could either default allow in or not via its firewall. In reality it's usually default deny, but not always, hence the freakouts people have about security in v6. V4 spec doesn't know about NAT, but in real life the answer is no you don't get inbound connections or even a publicly routable address unless you deliberately configured that.

tolien 4mo ago

If anything demonstrates the Dunning-Kruger effect on this forum, it’s the “just add more bits” crowd.