We did expand the header and change the version. That's what v6 does; it's set to 6 in v6 packets. > We could have front padded all of the ipv4 32 bits at the

We did expand the header and change the version. That's what v6 does; it's set to 6 in v6 packets. > We could have front padded all of the ipv4 32 bits at the router level and made it almost seamless to the end users. This is a bit simplistic. You either haven't thought about it in nearly enough detail to figure out how it would work, or at least you haven't explained the detail to us. It's easy to take "192.168.0.1" and write "0.0.0.0" in front of it, but then what? v4 devices don't support any way to do that on the network and v4 software can't handle the extra address length, so... what are you actually suggesting to do here? How can whatever it is be seamless if the devices that end users are using don't support it? I can describe a working scheme that might be what you're thinking of. You could make something that's basically a version of NAT but where the inside addresses are v6. That would allow a v6 client to reach a v4 server by sending packets to a special v6 prefix that represents the v4 space; it would work essentially the same as NAT in v4 but with an extra header conversion step. But... v6 already has this. I'm using this functionality on my desktop, which has no v4 address, and I can get to any website just fine. That includes Amazon and Github, just to be clear. Why do you need to keep dealing with v4 when you can just do what I'm doing but at the ISP level? v6 doesn't need a different design to make this work, because it already works.