On Sep 11, 2012, at 8:58 PM, Pars Mutaf <[email protected]> wrote:
> By "translation" I mean something completely new. It is written in the paper: > > Splitting the path to two (or more) parts. One part is IPv4, the other part > is IPv6. > > Source IPv4 <-> Translator IPv4 > Translator IPv6 <-> Destination IPv6 > > We take the data found in the IPv4 packet, we put it in an IPv6 packet (and > vice versa). Addressed to where? The translator needs the state - like a nat would - to map packets it receives to destinations. The ipv4 destination is what - the translator itself? Or some alias for the ipv6 destination? The former cant work because the translator can't know where to send the packet. The latter can't work because ipv4 addresses aren't large enough to support aliases for all of ipv6. > By translation, I do not mean translating the information found the in the > headers. We only copy data. (from IPv4 packet to IPv6 packet and vice versa). > See the paper for illustration (Figure 2). > > How TCP works on this, I don't know yet. I don't have to know it right now. Yes you do. .... > Sending a packet from an IPv4 host to an IPv6 host, connected using such a > translator, is a routing problem. The problem is that TCP assumes same IP > version for source and destination. We need another type of identifier, > perhaps. Yes you do. But that would render ipv4 and ipv6 into link layers over which your new packets with their addresses would traverse. > Such proposals exist already. But again, what is important here is not the > solution. What is important is "What we want". What is important is whether you have a solution. This is not a research venue. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
