Comment by throw0101a
6 days ago
> To answer the last question, routers would need IPv4+ support, just like ipv6 which already happened.
So exactly like IPv6: you need to roll out new code everywhere.
> The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
So exactly like IPv6: you need to roll out new code everywhere.
Would organization have rolled out in IPv4+ any differently than IPv6? Some early, some later, some questioning the need at all. It's the exact same coördination / herding cats problem.
It's a simple toggle on vs asking orgs to redo their entire network. In both cases you need routers and network stacks to support the new packet format, but that isn't the hard part of ipv6, we already got there and people still aren't switching.
Sorry, I'm still not seeing how a IPv4+ would be any less complicated (or as simple) as IPv6. In either case you would still have to:
* roll out new code everywhere
* enable the protocol on your routers
* get address block(s) assigned to you
* put those blocks into BGP
* enable the protocol on middleware boxes
* have translation boxes for new-protocol hosts talk to old-protocol-only hosts
* enable the protocol on end hosts
And just because you do it, does not mean anyone else would do in the same timeframe (or ever). You're back in the chicken-and-egg of whether servers/services do it first ("where are the clients?"), or end-devices ("where are the services?").
Everything you listed was already done for ipv6 or is trivial to enable, but people still aren't switching, because of all the things you didn't list.
2 replies →