4 ms·

We should add another 4 bytes to IPv4 which is the internal IP, then AWS f.ex. would only have one public IP per region and the rest would be internal IPs. IPv

by bullen 9y ago

We should add another 4 bytes to IPv4 which is the internal IP, then AWS f.ex. would only have one public IP per region and the rest would be internal IPs. IPv6 is too big and incompatible!

chatmasta 9y ago
If I understand what you're suggesting, this is basically how NAT64 [0] works to provide backwards compatibility to IPv6 (tunneling IPv4 over IPv6). It uses the first 32 bytes of the IPv6 address to store the IPv4 value. [0] https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64
- djrogers 9y ago
  Pedantic comment here, but NAT64 doesn’t involve any tunneling - it’s pure address translation handled by an edge box, whereas tunneling involves encapsulation.
  - chatmasta 9y ago
    True, I should have been more precise. Although there is technically no packet-level encapsulation, from a mathematical perspective you may consider the IPv4 bits "encapsulated" within the IPv6 bits.
cesarb 9y ago
Every time there's a discussion about IPv6, a suggestion like that appears, without fail. Paraphrasing the classic spamsolutions.txt, "Your idea will not work. Here is why it won't work." "Requires immediate total cooperation from everybody at once": every single system which wanted to talk to an AWS host would have to implement that IPv4 extension. "Many server administrators cannot afford to lose business or alienate potential clients": for anyone with a non-upgraded system, the server would be unreachable. Specifically, your plan fails to account for: - Lack of centrally controlling authority for networking - Huge existing software investment in IPv4 - Popularity of NAT and other middleboxes - Users who don't update their operating system ever and the following philosophical objections may also apply: - Ideas similar to yours are easy to come up with, yet none have ever been shown practical - It will work for a while and then we'll get stuck with it - It's an ugly hack "Sorry dude, but I don't think it would work." (I apologize for choosing your comment for this, but this idea of applying the spamsolutions.txt format to the inevitable "extended IPv4" proposals has been in my head for a long time. Someone with more networking experience should be able to present an even more complete list of "extended IPv4 objections".)

by bullen 9y ago

We should add another 4 bytes to IPv4 which is the internal IP, then AWS f.ex. would only have one public IP per region and the rest would be internal IPs. IPv6 is too big and incompatible!

chatmasta 9y ago

If I understand what you're suggesting, this is basically how NAT64 [0] works to provide backwards compatibility to IPv6 (tunneling IPv4 over IPv6). It uses the first 32 bytes of the IPv6 address to store the IPv4 value. [0] https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64

djrogers 9y ago
Pedantic comment here, but NAT64 doesn’t involve any tunneling - it’s pure address translation handled by an edge box, whereas tunneling involves encapsulation.
- chatmasta 9y ago
  True, I should have been more precise. Although there is technically no packet-level encapsulation, from a mathematical perspective you may consider the IPv4 bits "encapsulated" within the IPv6 bits.

cesarb 9y ago

Every time there's a discussion about IPv6, a suggestion like that appears, without fail. Paraphrasing the classic spamsolutions.txt, "Your idea will not work. Here is why it won't work." "Requires immediate total cooperation from everybody at once": every single system which wanted to talk to an AWS host would have to implement that IPv4 extension. "Many server administrators cannot afford to lose business or alienate potential clients": for anyone with a non-upgraded system, the server would be unreachable. Specifically, your plan fails to account for: - Lack of centrally controlling authority for networking - Huge existing software investment in IPv4 - Popularity of NAT and other middleboxes - Users who don't update their operating system ever and the following philosophical objections may also apply: - Ideas similar to yours are easy to come up with, yet none have ever been shown practical - It will work for a while and then we'll get stuck with it - It's an ugly hack "Sorry dude, but I don't think it would work." (I apologize for choosing your comment for this, but this idea of applying the spamsolutions.txt format to the inevitable "extended IPv4" proposals has been in my head for a long time. Someone with more networking experience should be able to present an even more complete list of "extended IPv4 objections".)