On 1/6/2011 9:28 PM, Dan Wing wrote:
-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP.
Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach the IPv4 Internet".
Skype can still make this work by relaying, Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64. That's the case we're discussing here. It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. Matthew Kaufman