3 ms·

There is no such space in the IPv4 header. And even if it were possible and you could specify an IPv4+, you’d run into the exact same problem: people would stil

by irdc 3y ago

There is no such space in the IPv4 header. And even if it were possible and you could specify an IPv4+, you’d run into the exact same problem: people would still insist on an IPv4 address to talk to whoever still is in the IPv4 world.

api 3y ago
Extend the address space to the right. All V4 addresses become /32 prefixes in a /48 space. 48-bit addresses ending in .0.0 are semantically identical to 32-bit addresses and may in fact be sent as classical 32-bit addressed packets or converted to such in flight to support old devices. Use the IP options facility for additional address bits, or alternately use the identification field and deprecate fragmentation at the IP level which is often broken anyway and is obviated by path MTU discovery. Routers would still have to be updated, but only close to or at the edge for quite some time. Could have been done that way but water under the bridge.
- lmm 3y ago
  If you'd got that standardised before CIDR then it might've worked, but there's no way to make it happen now; the IPv4 routing table is hopelessly fragmented and getting worse every day. New ISPs would be doomed to be forever second- or third-class citizens - there are no new class A or B blocks to hand out.
- Dagger2 3y ago
  We already have v6 addresses that are semantically equivalent to v4 ones: ::ffff:a.b.c.d. You could put extra address bits into option headers instead of expanding the address fields, but... what do you do then? How do you make things work? No existing OS, software or hardware device knows how to use them, and you have to go around and update those in exactly the same way you have to on v6. None of what you've suggested here would have allowed us to finish in the mid 2000s.
Ekaros 3y ago
There is the Options field, it could have been theoretically used. But that would have made the whole routing and decoding even more inefficient and messy...

by irdc 3y ago

api 3y ago

Extend the address space to the right. All V4 addresses become /32 prefixes in a /48 space. 48-bit addresses ending in .0.0 are semantically identical to 32-bit addresses and may in fact be sent as classical 32-bit addressed packets or converted to such in flight to support old devices. Use the IP options facility for additional address bits, or alternately use the identification field and deprecate fragmentation at the IP level which is often broken anyway and is obviated by path MTU discovery. Routers would still have to be updated, but only close to or at the edge for quite some time. Could have been done that way but water under the bridge.

lmm 3y ago
If you'd got that standardised before CIDR then it might've worked, but there's no way to make it happen now; the IPv4 routing table is hopelessly fragmented and getting worse every day. New ISPs would be doomed to be forever second- or third-class citizens - there are no new class A or B blocks to hand out.
Dagger2 3y ago
We already have v6 addresses that are semantically equivalent to v4 ones: ::ffff:a.b.c.d. You could put extra address bits into option headers instead of expanding the address fields, but... what do you do then? How do you make things work? No existing OS, software or hardware device knows how to use them, and you have to go around and update those in exactly the same way you have to on v6. None of what you've suggested here would have allowed us to finish in the mid 2000s.

Ekaros 3y ago

There is the Options field, it could have been theoretically used. But that would have made the whole routing and decoding even more inefficient and messy...