Assuming that you can actually come up with one, it could easily be solved with Network Address
Translation, or NAT as it is commonly known.
NAT is a neat concept and solves interesting problems, however it has serious practical shortcomings. As an example there are several incompatibilities between NAT and IPSec, restricting the combined use of the two with the simplest form of NAT and tunneled-mode IPSec (see http://www.ietf.org/internet-drafts/draft-ietf-ips ec-nat-reqts-04.txt)
4. The IPv6 header is too large. An IPv4 header compact at 20 bytes in length, while the IPv6 is bloated at 40 bytes. That's right people, each one of your IP packets has twice as much overhead as before.
Ah, but it is necessary. First, IPv4 defines 8 bits for the "Type of Service", used by some options. We are running short of those bits too, and historically some clashes have already occured where the same bit is used for two different purposes. Second, with IPSec and other IP options, your IPv4 header can already use close to the 40-byte limit for the IPv4 header. So the 2-to-1 "advantage of overhead" of IPv4 is not always present. The IPv4 header is already used up to its full potential. There is no more room.
While this may not sound much, IP networks have a requirement that the minimum MTU supported must be 576 bytes. That means that where you might have got 556 bytes of data in your IP packets, you now get 536 bytes. This means that downloading stuff will take 3.4% longer.
In practice, however, one seldom sees an MTU constraint of 576 bytes. 1500 bytes is the accepted standard in the litterature and seems by far the most common MTU on the Internet.
Slashdot Mirror
Assuming that you can actually come up with one, it could easily be solved with Network Address Translation, or NAT as it is commonly known. NAT is a neat concept and solves interesting problems, however it has serious practical shortcomings. As an example there are several incompatibilities between NAT and IPSec, restricting the combined use of the two with the simplest form of NAT and tunneled-mode IPSec (see http://www.ietf.org/internet-drafts/draft-ietf-ips ec-nat-reqts-04.txt)
4. The IPv6 header is too large. An IPv4 header compact at 20 bytes in length, while the IPv6 is bloated at 40 bytes. That's right people, each one of your IP packets has twice as much overhead as before.
Ah, but it is necessary. First, IPv4 defines 8 bits for the "Type of Service", used by some options. We are running short of those bits too, and historically some clashes have already occured where the same bit is used for two different purposes. Second, with IPSec and other IP options, your IPv4 header can already use close to the 40-byte limit for the IPv4 header. So the 2-to-1 "advantage of overhead" of IPv4 is not always present. The IPv4 header is already used up to its full potential. There is no more room.
While this may not sound much, IP networks have a requirement that the minimum MTU supported must be 576 bytes. That means that where you might have got 556 bytes of data in your IP packets, you now get 536 bytes. This means that downloading stuff will take 3.4% longer.
In practice, however, one seldom sees an MTU constraint of 576 bytes. 1500 bytes is the accepted standard in the litterature and seems by far the most common MTU on the Internet.