3 ms·

I am not writing socket code. I am trying to get residential customers to the websites they would like to visit. Maybe it wouldn't have made it any better to e

by eppp 3y ago

I am not writing socket code. I am trying to get residential customers to the websites they would like to visit. Maybe it wouldn't have made it any better to expand the header and change the version but then again maybe it would have. Why even have the version value in the header to start with if it is always going to be set to 4? What is the point? I have to keep dealing with ipv4 until companies like amazon and github and every little smb that has a vpn stop. It would have been amazing yes had they designed ipv6 differently and just increased the header and address sizes and added a padding value for the high bits. We could have front padded all of the ipv4 32 bits at the router level and made it almost seamless to the end users.

Dagger2 3y ago
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.

by eppp 3y ago

Dagger2 3y ago

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.