On Thu, Jan 6, 2011 at 9:18 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On 1/5/2011 9:39 PM, Cameron Byrne wrote:
I understand my users pretty well, they only go to a few web pages ... its the nature of the net. I assure you, i am not taking any undue risk with regards to web. Try our friendly user trial and give me your feedback, thats why i am running it.
I'm not particularly surprised that a mobile client platform has a different access pattern than desktop users... not a whole lot of mobile BitTorrent clients yet, for instance.
Ah Skype. According to your web page you work at Skype. Skype is a well known IPv6 spoiler application. In fact, in the IETF and many other circles, Skype is the only app that we can't seem to get to work with IPv6. Are you here to help with that or to tell us that we need to keep IPv4 around indefinitely?
Indeed, I work at Skype now and Adobe (developing RTMFP) before that.
At this point (because not everyone has IPv6) this class of applications (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your NAT64 to talk to peers that are IPv4-only. To do that, they need to be able to discover your NAT64 even though they're not doing DNS lookups to find the IPv4 addresses of peers.
This will take 1) a way to do this and 2) upgrades of the apps to take advantage of it. It is impossible to do #2 until #1 is solved.
There's been discussion in BEHAVE about this topic... draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a solution that wasn't raised in that or previous documents here: http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I suppose, since it hasn't been mentioned elsewhere, should be written up as a draft if/when I have some free time)
Skype is not defined in an IETF RFC, so saying you need an RFC to move forward is bit confusing. There are several methods that just work today, I am all for standards, but a closed platforms generally find ways to progress without or in spite of standards. Skype is a closed platform.
Skype should not be the IPv6 spoiler app when NEARLY EVERYTHING ELSE WORKS. Read the thread i mentioned, real users, real developers, real network that is IPv6-only. Notice that things generally work, those folks have hacked their way to perhaps even making Skype work.
There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular.
Please make a list and let us know. Otherwise, this is just hand waving like the IPv4 literals sites. I have had people on various mailing list tell me all things they think won't work, but in my own experience and in the experience of my beta users, who are publicly documenting their efforts on the support boards, things work well. Yes, some things don't work due the fact that it is a beta and something don't work due to the fact that it is IPv6-only, but they are not show stoppers for the business. As a user, i have been using IPv6-only on Symbian for 9 months without an issue. The service works as i would expect it to with IPv4, no user perceived differences. Skype is a squeaky wheel, but most (99%) things users do works fine. As mentioned, in mobile, 95+% of the traffic is web and email. And, most "apps", are also just web and email. My advice to Skype is to come up with a solution to work for IPv6-only clients. That is my advice to all apps and all content. IPv6-only clients are an obvious reality in an IPv4 exhausted world. You cannot seriously come to a network operators support mailing list and say that the network guys have to keep investing in network tweaks while you wait for a standards body to solve a problem for your closed non-standard applications. I won't go into my diatribe about why dual-stack is not an obvious choice in mobile, you can check the video of it at the google IPv6 conference in 2010. If you have further questions, i am glad to help you understand and entertain your ideas off list. The main point is the dual-stack and substantially more expensive and the IPv4 part of dual-stack is run out of addresses....private, public, bogon. http://www.youtube.com/watch?v=1GlRgaFriYU#t=15m38s
Seriously, 95+% of my traffic is web and email, and STUN and ICE don't matter much to grandma as long as m.v6.facebook.com loads.
See my above comment about how I'm not surprised, given the specific client population.
As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....).
Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't require apps to be upgraded to do discovery of the NAT64 prefix(es) (which, for some legacy apps that are no longer under development will never happen).
Dual-stack cost the mobile network operator 2x in the packet core, check the Youtube video. It is not acceptable to ask the network operators to increase their cost by 2x while the apps sit and wait.
NAT64/DNS64 is an interesting experiment that works for >95% of the web. But it isn't really a solution unless "the web" is all you care about.
Experiment? Yes, the experiment part is over. As i mentioned, we are deploying. The 3GPP has adopted IPv6-Only + NAT64 as an official path nearly a year ago. I have tried to make it clear to folks that upgrading to IPv6 is the only way to ensure your apps and content continue to work as you expected. Otherwise, you traverse NAT64 CGN and some things won't work. The same is true for DS-lite and others, but in different ways. To that end, lets partner up and make Skype work with IPv6. I also assure you, many mobile operators are pursuing this NAT64 path for the same reason I am. Cameron
Matthew Kaufman