Relay nodes are always protecting themselves by rate-limiting, aren't they? Yes. And isn't most media traffic relayed? No, not at all. Almost all media traffic goes directly end-to-end by using really good NAT traversal. I'm not seeing how the NAT64 scenario would *dramatically* increase Skype's global relay traffic. NAT64 would currently be a very small percentage of all Skype traffic. The relay issue isn't about that. If you can't discover the NAT64 and you can't discover the mapping algorithm, then you can't use IPv4
On 1/8/2011 3:22 PM, Frank Bulk wrote: literal addresses. If you can and the application is changed to use the discovery mechanism, then the traffic flows through the NAT64 and relay nodes aren't an issue. But if you can't then the only way for a future IPv6-enabled Skype client that has IPv6 + NAT64 to (not) reach the IPv4 Internet can talk to another Skype client that has IPv4 only would be to go through the relay node. That means that people who are on ISPs that use native IPv4 dual-stack, and people who are on ISPs that use CGN NAT44 to dual-stack both get the direct end-to-end experience when calling IPv4-only clients... but people who are on ISPs that use NAT64 instead of dual-stack end up having to go through (rate limited) relays to call IPv4-only clients. That means they'd have an excellent reason to choose an ISP that uses a different technology. Which they'll need to do to make their BitTorrent and everything else that uses IPv4 literals work anyway.
We can always find examples of where things will break with v6. While the v6-only world is still very small, let's *start* somewhere, where intelligent clients like Skype can always "fall back" to v4. Lots of time to figure out the corner cases. The point is that NAT64 creates a huge additional set of corner cases (all of the cases where IPv4 literal addresses are transported by anything other than DNS lookups) that none of the other transition choices do. (NAT64 has all the problems of CGN *plus* this issue, for instance.)
Matthew Kaufman