On Sat, Jan 8, 2011 at 10:55 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 1/8/2011 3:22 PM, Frank Bulk wrote:
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 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.)
1. The companies that have selected NAT64 as a tool for rolling out IPv6 to address the IPv4 exhaustion business risk are aware of the various application trade offs. They select NAT64 because it makes business sense to aggressively go after IPv6 as the end-state and not provide patches and work-arounds in their network to make dual-stack work, which is not an end-state, it is a transition mechanism on the path to ipv6. Also, as i mentioned for mobile, dual-stack is MUCH more expensive. And ipv6-only works for the vast majority of my user and my traffic. 2. You can pass this FUD around about people leaving networks so that skype and bittorrent work. Last time i checked, many mobile network operators and handsets only begrudgingly supported skype and bittorent if at all. In fact, many networks spend considerable time and money to stop them. I also know that Skype has some mobile partners. I am not here to say if this is right or wrong, but i do not expect network providers to alter their ipv6 strategy of business decisions to accommodate Skype and Bittorrent. These applications have shown amazing resiliency over the years to bust through firewalls and NATs, and i am really amazed at how much opposition Skype is providing to the IPv6 transition. I imagine Skype would have a better hand if Skype was IPv6 enabled a long time ago and pushing dual-stack and waiting on the carriers, but Skype is IPv4-only just like all the rest of the slow moving world. If dual-stack had worked, we would not be here talking about NAT64. But, dual-stack did not work. We are out of IPv4 and the network still has to grow, hence IPv6-only + NAT64. And again, dual-stack is much more expensive in mobile networks than single stack so it won't happen with the Ipv4 side being endless duplication of RFC 1918 and bogon space. 3. I am just here to create awareness of this technology that the IETF as the protocol standardizer and the 3GPP as the mobile architecture standardizer have accepted and are moving forward. I want all applications to work with IPv6 and NAT64. In every email i have sent on this topic and off-list to Matthew, i have made the call to action to support ipv6 and to work together. From the network side, i am willing partner. But, not supporting IPv6 is not an option in my mind. That is where Skype stands today. IPv4 is really not a strategic path for any network, especially a mobile network that has a large and growing edge. There are several ways to work through making NAT64 work, as Matthew has acknowledge, and even hinted at having a better proprietary way. I am open to new ways and new partnerships to make this work. When you are ready to talk about moving forward, i am all ears. Until then, you can keep posturing while the clock ticks on committed deployments. If you know it's coming and don't have a solution, if you strategically choose to play that game of chicken, thats fine too, it's a calculated risk that my business has made. Cameron
Matthew Kaufman