Here is another thing I think we should agree on. This only applies to translation schemes where the translation is done by a router, rather than be upgraded facilities in the hosts themselves (such as SHIM6 or Six/One - not Six/One Router). In other messages I argue that trying to solve the routing scaling problem with host upgrades is never going to work, not least due to the difficulty or impossibility of upgrading all hosts and to the difficulty of securely managing their behavior in the centralised manner that most end-user networks would require.
Map-encap systems add extra data to each packet in order to transport it across the DFZ without routing scaling problems, and so that the receiving router (the ETR) can figure out how to handle the packet. This is done by the full packet being sent verbatim, and the outer header existing purely to get the inner packet to the ETR. A translation scheme does not make packets any longer, which might avoid some nasty problems map-encap schemes face with Path MTU Discovery, overly large packets getting dropped or fragmented in the tunnel etc. A translation scheme involves one router (R1 in what follows) changing the destination address of the packet so that it can be transported across the DFZ, without routing scaling problems, to a second router (R2), near the real destination host. R2 then has the task of figuring out the proper destination address of this packet, so it can forward it correctly. For multihoming (portability as well?) one way of doing this for an address space X is to have two or more address spaces Y and Z of the same length as X, and have R2 receive all packets addressed to those Y and Z spaces. When the sending host (near R1) generates a packet addressed to some destination host at (X + N), R1 rewrites the address to (Y + N) or (Z + N). Then R2 has no difficulty reconstituting the original packet by altering its destination address to (X + N). This may be a practical approach in IPv6, since there is plenty of address space. However, in the context of the IPv4 address shortage, it is completely impractical in IPv4. For a router-based address translation scheme (such as Six/One Router) to work without duplicate address ranges, there needs to be a practical method of R2 reconstituting the packet it receives. Without duplicate address spaces, R1 will send all packets to R2's hosts by changing the destination address to that of R2. There is no "N" in this, so R2 has no way of knowing from the packet itself which host it needs to be forwarded to. The following scenario exemplifies the problem which such a scheme faces. Host A in R1's network sends a packet to host B and an identical packet to host C. Both B and C are in R2's network. R1 rewrites the destination address of both packets to R2's address. What would the scheme have to do in order to enable R2 to know how to reconstitute the destination address? All the options seem so onerous and troublesome that I argue that this is completely impractical. For instance, R1 could send a separate "info" packet for each of these traffic packets, telling R2 the B or C address, and somehow enabling R2 to unambiguously identify which incoming packet the information applies to. This raises problems of reliability and packet loss/delay. It also raises some security problems, since an attacker could spoof the info packet, making it get to R2 before the real info packet from R1. To prevent this, there would have to be some fancy authentication arrangements - but how could this be done without PKI or without multi-packet exchanges of nonces etc.? Such arrangements would also delay initial packets in a new communication flow, and further contribute to vulnerability of the system to packet loss. This approach and its required authentication arrangements also involves R2 storing a large amount of state and doing many complex operations. This looks like a robust theoretical argument why a router-based translation scheme can never be efficient or robust unless it uses duplicate address space - which means such an approach cannot be practical for IPv4. - Robin http://www.firstpr.com.au/ip/ivip/ -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
