On 1/6/2011 9:28 PM, Dan Wing wrote:
-----Original Message-----
From: Matthew Kaufman [mailto:matt...@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
