Re: [v6ops] Worse than NATed IPv4? [was IPv6 for mobile]

[Cameron Byrne <[e-mail]>]

On Fri, Dec 24, 2010 at 5:29 AM, Hesham Soliman
<[e-mail]> wrote:
>
>
>
>>>
>>>> How is pushing dual-stack going to work now when it has not worked for
>>>> 10+ years?
>>>
>>> => ?? Why not? Works fine on my linux and Mac.
>>>
>>
>> As another has stated, the issue is that after 10 years,
>
> => I think you're confused about  what happened over the last 10 years. 10
> years ago (year 2000 in my calendar) where was IPv6 supported? Which os?
> Let's consider facts.
>

Yep, calendar still says 2010, and Nokia is the only vendor that ships
IPv6 handsets.  And, there is ZERO commitment from any other handset
vendor to support IPv6.

RFC2460 shows the date of 1998 on it.  Pretty sure 3GPP release 99 had
support for IPv6, so that was about the year 2000 ....

So, i am not confused about what happened in mobile with IPv6 in the
last 10 years.  Nothing happened, because the economics did not move
it.

Regarding non-mobile, i remember installing Solaris 8 with IPv6 around
2002.  About the same time frame i remember tunneling my home RedHat 7
system to the 6bone .... so that was maybe 8 years ago.

I know "Grandma" does not run Linux, but the point is that the
technology and specs have been around for a long time and we still
don't have a whole lot to show for it except new lines of CGN/LSN
being installed in networks all around the world.

>> Further more, dual stack is just a transition mechamism like NAT64.
>> Dual stack is not a destination.  And, like any other transition
>> mechanisms, dual stack has a lot of caveats on when it will work and
>> when it will NOT work.
>
> => Yes obviously it's a transition mechanism and not a goal, no one suggests
> otherwise.
>

So, explain to me how dual-stack leads to transition, where transition
means IPv4 is turned off?  As far as i can tell, we are talking about
plans to turn on IPv6 (or LSN NAT444444), but there are still no plans
to address turning off IPv4 for the growing network edge of
subscribers and cloud nodes.  I understood how dual-stack is supposed
to work, but the economics lead to an inertia problem.... and that
problem has not yet been solved.


>>
>> The brokeness with dual stack is MAJOR reason content, a big part of
>> the chicken and egg problem, will not move to dual-stack or ipv6
>
> => What is this "brokenness"? Can you please try to justify these opinions
> with some fact?
>
>>
>> Here are 2 more drafts to help solve the problems with dual stack
>>
>> http://tools.ietf.org/html/draft-wing-http-new-tech-01
>> http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications-01
>
> => that's good. There is happy eyeballs as well, so what's the issue?

You're right.  Happy eyeballs fixes all this.  Roll that out to all
your subscribers before IPv4 exhaust.  Different strokes for different
folks.

> In the absence of dual stack what are your plans in your IPv6-only network
> when I connect my XP machine to my mobile phone? Or when I use it at home?
> Are you going to ban legacy devices?
>

IPv4-only device will not go away for 10+ years.  I am only trying to
match technology opportunities with business problems.  Some devices
work well with v6, others do not.  Where i can deploy v6, i must.
Where i cannot deploy v6, v4 will have to do.  There is no benefit to
the network or the user in having dual-stack from my perspective.
IPv4 will work and must always work because it is what we have today.
IPv6 will emerge as working in more and more scenarios, i building to
take advantage of that.

>>
>>>  And, any flavor of dual stack does not solve the address
>>>> exhaustion problem that i face with all public, private, and now bogon
>>>> address exhausted ... Granted, this not the problems all operators
>>>> face. But, large mobile in the usa has been out of ipv4 for many
>>>> years.
>>>
>>> => Right, same here in Australia, so they'll use v4 NATs as a temp approach.
>>> It's safer than the alternative.
>>>
>>
>> This may work well in fixed line,
>
> => This has nothing to do with the access technology. The concept works
> regardless.
>

It's my understanding that some landline technologies and deployments
don't support IPv6, so they have no choice to go to native IPv6.  3GPP
does have the choice, i am doing it today....hence, access networks
matter in determining a pathway to transition.  It is also true that
in-home networks are much more complicated than simple mobile
handsets.

Technology happens in a context.

>> assuming the various management
>> folks are ok  with the additional support cost.  But, if dual-stack
>> cost more than single stack to support and average customers do not
>> get a real benefit, how does management justify taking on the new
>> costs?  My guess is that they dont .... and ipv6 continues to not be
>> deployed.
>
> => That's not true. The additional management cost is insignificant to even
> bring up as an issue. Can you quantify it?
>

I cannot quantify for you, each operator has do that for themselves.
Understanding what it takes  to do happy eyeballs and what the impact
will be on your network is likely a good start.

>>
>> Here is some simple fake math, more ">" indicates a greater magnitude of
>> change
>>
>> 1. profit today >> profit today - risk of address exhaustion
>>
>> 2. profit today >>> profit today - risk of address exhaustion - cost
>> of deploying dual-stack
>>
>> 3.  profit today >>>> profit today - risk of address - cost of ds -
>> cost of NAT44
>>
>> 4. profit today > profit today - cost of NAT44
>>
>> 5. profit today > profit today - cost of NAT64
>>
>> In mobile, i have #4 today and am moving to #5.  #5 is strategically
>> superior to #4 because it has an end-game the results in everything
>> being native IPv6.  #4 has no end game, the end game is more and more
>> NAT.
>
> => It's fine if you came up with numbers that work for you, I'm not trying
> to force anyone to use DS, I just think the numbers don't exist for your
> examples above. Just out of curiosity, what are you planning for legacy
> devices whether they sit behind a mobile or CPE? Or whether they are the
> mobile itself?
>

As i mentioned above, ipv6 will only be deployed where it make sense.
I am starting with the low hanging fruit and simple situations, and i
plan to build on those lessons learned and move up the stack from
there.  In my mobile network, ipv6 will be introduced 1 handset model
at a time.  monitor. tweak, apply lessons learned and increase the
scope.

Like many engineering problems, this problem, for me, is best solved
by breaking the problem up into smaller problems and solving the
smaller problems one by one while keeping a mindful eye on how they
fit into the big picture.

That said, i can roll out a simple IPv6-only handset in 2011.  In
2012, i can increase the scope.  In 2013, even more.  The key, for me,
is to make incremental progress towards the end state goal we all want
to be at, ipv6-only end to end, while making this transition a
non-issue for the customer.

This is just my approach, if something else works for you, great.  I
appreciate the feedback you have provided in this conversation.

Cameron

> Hesham
>
>>
>> cb
>>
>>> Hesham
>>>
>>>>
>>>> Cb
>>>>
>>>> On 12/23/10, Hesham Soliman <[e-mail]> wrote:
>>>>> You'll only achieve that when the handset o/s, firmware and the plaftorm
>>>>> running on top of the o/s (e.g. S60) provide IPv6 support to the apps in a
>>>>> seamless manner. We're not far from this, maybe a year. I don't think there
>>>>> is much you can do to prep the 100,000s of app developers for various
>>>>> platforms.
>>>>> That's why I'm recommending to the operator(s) I deal with to run v4 NAT
>>>>> and
>>>>> enable dual stacks in the network, keep pushing the handset vendors and
>>>>> wait
>>>>> for things to naturally move towards v6. It's the only reliable way for an
>>>>> operator to provide the same service. It's not good enough to tell them
>>>>> that
>>>>> some popular apps will break and those users will have to suffer for a
>>>>> little while. At least not for the operators I work with.
>>>>>
>>>>> Hesham
>>>>>
>>>>>
>>>>> On 24/12/10 8:16 AM, "Cameron Byrne" <[e-mail]> wrote:
>>>>>
>>>>>> I don't think any network operator supports 3rd party apps from any
>>>>>> app store, it is the apps that have to evolve with the network and
>>>>>> changing landscape of the internet as we know it. Period.
>>>>>>
>>>>>> Some glass will break, i have been trying to prep app makers and
>>>>>> content owners  for nearly a year.  we cannot have yet another chicken
>>>>>> and egg stalemate, addresses are really exhausted now. When we
>>>>>> introduce v6 only phones, content and apps folks will have had a full
>>>>>> 18 months of warning made at nanog lists, ietf list, isoc meetings,
>>>>>> and google meetings. I have also made calls and sent emails ... Alas
>>>>>> ... Some will be unhappy about how things unfold and they will
>>>>>> scramble, i keep tabs on the risks of fall out, and to date, the risk
>>>>>> of inaction is higher than the risk of action.
>>>>>>
>>>>>> I thought i made it clear that 'get by' is not my goal, that is the
>>>>>> reality of users on the defunct maemo platform.  my goal is the same
>>>>>> experience on v4 or v6, and that is achievable on symbian today and my
>>>>>> best guess is that it will be achievable on android and ios when the
>>>>>> radio part is worked out, their sdks are address version agnostic ...
>>>>>> Not like qt in maemo.
>>>>>>
>>>>>> I have an open beta to make things move forward and to extend the hand
>>>>>> of partnership to the app and content folks.
>>>>>>
>>>>>> Cb
>>>>>>
>>>>>> On 12/23/10, Mikael Abrahamsson <[e-mail]> wrote:
>>>>>>> On Thu, 23 Dec 2010, Cameron Byrne wrote:
>>>>>>>
>>>>>>>> Another data point is that over 100 of the users in my beta are using
>>>>>>>> n900 and they get by well enough...
>>>>>>>
>>>>>>> "get by"?
>>>>>>>
>>>>>>> Am I the anomaly with messenger/skype not working, or are you saying
>>>>>>> you'd
>>>>>>> be comfortable releasing a service where such applications do not work?
>>>>>>>
>>>>>>> --
>>>>>>> Mikael Abrahamsson    email: [e-mail]
>>>>>>> _______________________________________________
>>>>>>> v6ops mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>