On Apr 19, 2011, at 4:06 PM, Alain Durand wrote: > > On Apr 12, 2011, at 4:03 PM, Mark Townsley wrote: > >> >> Hello Dmitry, >> >> My view is that 4rd is most easily understood if and only if it connects to >> a CE function that is performing NAPT. The CE function may be in what is >> traditionally considered a host, or in what is clearly a router. >> >> More specifically, a device that is forwarding packets from one interface >> (virtual or otherwise) to another through a NAPT that has one interface with >> IPv6 configured (via DHCPv6 or otherwise) as performing 4rd (which enables >> dual-stack via a port-restricted IPv4 address for the NAPT using IPv6 as the >> transport) then you a have a 4rd CE. That could be a "host" in that it is a >> Windows PC with internet connection sharing for IPv4 turned on and hence >> forwards packets between interfaces with a NAPT due to the IPv4-enabled >> interface created when 4rd is configured. >> >> I would avoid anything that requires the host forwarding table to be altered >> to accommodate 4rd. Instead, the NAPT function that is already present in a >> small router or host configured to look like a router is modified to use a >> set of ports that it is allowed to use when 4rd is enabled. > > > Mark: > > How would an app running on a 4rd CPE communicate in IPv4 to another app > running on another 4rd CPE?
First, by definition any 4rd CPE has IPv6. So, if your application works with IPv6. 4rd-to-4rd is as easy as knowing two IPv6 addresses and not having a simple-minded firewall between the two blocking traffic. For IPv4, in the model I describe above, all applications are sitting behind the NAPT within the CPE bound to the 4rd tunnel. End-to-end looks just about as desperate and ugly as it does today between any series of NAPTs and firewalls. Skype will make its way through, I suspect with no modifications. - Mark > > - Alain. > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
