4 ms·

No, we keep being required to have ipv4 so our customers can reach the sites they are trying to get to. If it was just as simple as deploying ipv6 and retiring

by eppp 3y ago

No, we keep being required to have ipv4 so our customers can reach the sites they are trying to get to. If it was just as simple as deploying ipv6 and retiring ipv4 we would have done it already. But someone just had to make them not interoperable.

Dagger2 3y ago
They're not non-interoperable though? My desktop has no v4 and it has no trouble reaching any sites.
- eppp 3y ago
  There are still massive amounts of consumer grade equipment that have no ability to deal with ipv6 addresses. How much modern iot stuff even supports it?
  - Dagger2 3y ago
    Yes, and that's unfortunate, but it's not because "someone just had to make them not interoperable", it's because v6 addresses are bigger than v4 addresses and so can't fit into the same APIs/fields/data types, which means new APIs etc are required. It's not v6's fault that people refuse to stop using the old ones.
    - eppp 3y ago
      No its the fault of the architectural astronauts that decided to reinvent the whole thing instead of slowly phasing in the changes needed to add more addresses.
      - Dagger2 3y ago
        But they didn't reinvent the whole thing? v6 mostly works the same as v4. There's not even really anything new in it; the biggest new thing is probably SLAAC, which isn't exactly complicated. IPsec was bigger, but immediately backported to v4 and nobody uses it anyway, so I'm not sure it counts. v6 is already designed to be slowly phased in, by allowing deployment of updated software/OSs/devices that support the new addresses in parallel with the old and gradually moving things over. If anything, the reason people can still use the old APIs is because of the approach of slowly phasing it in. That's what you wanted, and it's still not good enough for you?
        eppp 3y ago
        That is a pretty simplistic way of looking at it. If it worked the same then why do I have to duplicate all layers of the stack to make it work? And even if I did, I still have to maintain the ipv4 stuff functionally forever. That's why they should have gradually expanded the existing header and we would be done by now instead of making a competing standard.
        Dagger2 3y ago
        You don't have to; you can make a single IP implementation that handles both. AF_INET6 sockets can handle v4 and v4 can be translated to run over v6. What do you mean by "gradually expand the existing header"? I assume you don't mean "keep making new header versions that increase the address length by one byte until we reach 16 bytes", but I can't think of anything that could be described like that which would have made adoption any quicker or easier. > I still have to maintain the ipv4 stuff functionally forever Consider why this is. What's stopping you from just not doing that -- and would a different design of v6 help at all with this?
        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.
SAI_Peregrinus 3y ago
IPv4 didn't provide a variable-length header, so the number of address bits is fixed. Any extension to add more addresses is inherently going to break interoperability.
- eppp 3y ago
  It didnt 20 years ago. That spec could have been changed and on routers added a default padding for the devices that didn't understand the new variable length. 0.0.0.0.192.168.0.1 or whatever for the legacy ipv4 devices. Im sure there was all kinds of hemming and hawing about why it would be difficult to do on the current hardware of the time and none of that equipment even exists anymore. So instead we decided to reinvent the wheel and make it a major pain instead.

by eppp 3y ago

Dagger2 3y ago

They're not non-interoperable though? My desktop has no v4 and it has no trouble reaching any sites.

eppp 3y ago
There are still massive amounts of consumer grade equipment that have no ability to deal with ipv6 addresses. How much modern iot stuff even supports it?
- Dagger2 3y ago
  Yes, and that's unfortunate, but it's not because "someone just had to make them not interoperable", it's because v6 addresses are bigger than v4 addresses and so can't fit into the same APIs/fields/data types, which means new APIs etc are required. It's not v6's fault that people refuse to stop using the old ones.
  - eppp 3y ago
    No its the fault of the architectural astronauts that decided to reinvent the whole thing instead of slowly phasing in the changes needed to add more addresses.
    - Dagger2 3y ago
      But they didn't reinvent the whole thing? v6 mostly works the same as v4. There's not even really anything new in it; the biggest new thing is probably SLAAC, which isn't exactly complicated. IPsec was bigger, but immediately backported to v4 and nobody uses it anyway, so I'm not sure it counts. v6 is already designed to be slowly phased in, by allowing deployment of updated software/OSs/devices that support the new addresses in parallel with the old and gradually moving things over. If anything, the reason people can still use the old APIs is because of the approach of slowly phasing it in. That's what you wanted, and it's still not good enough for you?
      - eppp 3y ago
        That is a pretty simplistic way of looking at it. If it worked the same then why do I have to duplicate all layers of the stack to make it work? And even if I did, I still have to maintain the ipv4 stuff functionally forever. That's why they should have gradually expanded the existing header and we would be done by now instead of making a competing standard.
        Dagger2 3y ago
        You don't have to; you can make a single IP implementation that handles both. AF_INET6 sockets can handle v4 and v4 can be translated to run over v6. What do you mean by "gradually expand the existing header"? I assume you don't mean "keep making new header versions that increase the address length by one byte until we reach 16 bytes", but I can't think of anything that could be described like that which would have made adoption any quicker or easier. > I still have to maintain the ipv4 stuff functionally forever Consider why this is. What's stopping you from just not doing that -- and would a different design of v6 help at all with this?
        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.

SAI_Peregrinus 3y ago

IPv4 didn't provide a variable-length header, so the number of address bits is fixed. Any extension to add more addresses is inherently going to break interoperability.

eppp 3y ago
It didnt 20 years ago. That spec could have been changed and on routers added a default padding for the devices that didn't understand the new variable length. 0.0.0.0.192.168.0.1 or whatever for the legacy ipv4 devices. Im sure there was all kinds of hemming and hawing about why it would be difficult to do on the current hardware of the time and none of that equipment even exists anymore. So instead we decided to reinvent the wheel and make it a major pain instead.