Problems with removing NAT from a network

Thu Jan 6 18:07:16 UTC 2011

On Thu, Jan 6, 2011 at 9:18 AM, Matthew Kaufman <matthew at 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
>
>