Dear Cameron,
I agree IPv6 only client is no problem, but how about dual stack?
I am wondering at the dual stack issue, in my question 1).
Most application servers are still IPv4 only now,
so how many UEs turn on their IPv6 or Dual Stack?
Regards
Xiangsong
----- Original Message -----
From: "Cameron Byrne" <[email protected]>
To: "Xiangsong Cui" <[email protected]>
Cc: "Nick Heatley" <[email protected]>; "Hui Deng" <[email protected]>; "Sri Gundavelli" <[email protected]>;
<[email protected]>; <[email protected]>
Sent: Friday, December 04, 2009 12:58 PM
Subject: Re: [Softwires] Transition roadmap // Re: Host based translation: v4-v6
On Thu, Dec 3, 2009 at 7:05 PM, Xiangsong Cui <[email protected]> wrote:
Dear Nick,
Thank you very much for your detailed clarification!!
Your comment raises more requirements/assumptions that need to be
established.
OMG, I just wanted to simplify the discussion, that is not my intention :)
Since our discussion goes to another direction now, I would rename the
subject.
I do agree that the pace is very important, and in my understanding, you
mean
transition mainly starts from UEs, then bearer network, then App Server, is
that correct?
follow this rule, I have some additional questions,
1) for UEs, do you mean Dual Stack is very necessary? or recommended?
2) for bearer network, is it possible that IPv4 only network changes to IPv6
only network
directly? if DS bearer network is taken as a middle phase, may DS
functionality only be
provided by some key gateways?
3) for the App Servers, is the exhaustion of IP address a severe issue?
In this roadmap, the key point is the UE, UEs need to support more function.
But, in fact, if the UEs do that, the price will be increased, it seems that
the users and
UE vendors don't like that, so the transition goes slowly?
Many UEs from many vendors support IPv6 today (Nokia, Windows Mobile,
...). If you include netbooks as UEs, those support IPv6 too a la
windows 7 or Linux. UE is not the road block, the road block is the
network operator driving the change. But, i assure you, that is
changing.
That said, solution that don't add yet another variable into the UE
environment (18 month development cycle) are considered good.
In my mind, I am thinking another roadmap,
transition starts from the bearer network, and then UEs, and then App
Servers.
As you said, the main driver for IPv6 transition is the exhaustion of IP
address,
operator is the most related player on this issue.
And since the bearer network has to go to IPv6 in any approaches, why not do
it firstly?
In this approach, UEs maybe get benefits after the bearer network has
already been IPv6,
For example, if the users can reduce the traffic amount, comparing to first
approach, tunnel is
reduced, so the traffic amount may also be reduced, this can save users'
money, so users
would like to pay a bit more money for these updated UEs, and the UE vendors
would
like to accept this roadmap, too. So IPv6 transition would goes easier.
Maybe operators
may also get additional benefit from this fast IPv6 transition.
I am not sure is that correct, because it depends on accounting and other
aspects.
What do you think about that?
Thanks and regards
Xiangsong
----- Original Message ----- From: "Nick Heatley"
<[email protected]>
To: "Xiangsong Cui" <[email protected]>; "Hui Deng"
<[email protected]>; "Sri Gundavelli" <[email protected]>;
<[email protected]>
Cc: <[email protected]>
Sent: Thursday, December 03, 2009 7:26 PM
Subject: RE: [Softwires] Host based translation: v4-v6
Dear Xiangsong,
Your comment raises more requirements/assumptions that need to be
established.
There seems to be two sets of drivers:
1) exhaustion of IP addressing for UEs only
2) exhaustion of IP addressing for UEs and Servers
1) could be exhaustion of private addressing or public addressing.
2) leads to an additional focus on supporting the IPv6-only App server,
where as 1) does not.
I would suggest that currently operators may be in different positions
in relation to these drivers. This really drives whether they wish to go
straight to IPv6-only bearer networks (potentially higher demand for
IPv6 content) or go through a phase of dual stack bearer network
support.
(Does Gateway-Initiated Dual Stack-lite stop the move to IPv6? IMHO the
answer is NO, but it is not an aggressive move to IPv6-only. P-NAT is an
aggressive move to IPv6-only bearer network.)
A second assumption for an operator - will the operator provide access
to IPv6-only Apps via an IPv4-only bearer network? My opinion: I expect
many operators will not. This is my assumption. (IMHO this decision
ensures there remains a valid reason for every operator to move to
support IPv6, with the Content Providers setting the pace. But if
IPv6-only content is niche in your market, then it may not happen at the
same pace as UE address exhaustion.)
My opinions: As a mobile operator I suggest that both "user" and
"carrier" drivers (as you state) are somewhat in my control.
I have a lot of control over the UEs and what they support.
My primary goal: I must guarantee the user experience. And yes I agree,
the end customer mainly does not care for IPv6 or IPv4, just good
service, right?
So points of interest in the App Server debate are these use cases:
A) IPv4 only-app -> Dual Stack UE -> IPv6-only bearer -> IPv6 only
server
B) IPv4 only-app -> Dual Stack UE -> IPv6 only bearer -> IPv4 only
server
If the bearer network is dual-stacked then B) is trivial.
If you believe your eco-system follows drivers in 1) then you can dual
stack your server and network and A) becomes simple. Or in other words
IPv6-only App servers are niche.
But if you follow drivers 2) then you expect IPv6-only servers to be
common place for your mass-market.
To summarise, operators need to think about whether they go for an
aggressive move to an IPv6-only bearer network approach or not. To make
that decision I would say one of the factors is about content provider
networks and the relative pace at which IPv6-only content is appearing
compared to UE IP address exhaustion. (UEs functionality plays a massive
part as well!).
I welcome further discussion :-)
Regards,
Nick
T-Mobile
-----Original Message-----
From: Xiangsong Cui [mailto:[email protected]]
Sent: 03 December 2009 02:03
To: Nick Heatley; Hui Deng; Sri Gundavelli;
[email protected]
Cc: [email protected]
Subject: Re: [Softwires] Host based translation: v4-v6
Hi all,
I have some comments on this topic, please see inline.
If I have some mistakes please let me know, thanks!
Regards
Xiangsong
----- Original Message ----- From: "Nick Heatley"
<[email protected]>
To: "Hui Deng" <[email protected]>; "Sri Gundavelli"
<[email protected]>;
<[email protected]>
Cc: <[email protected]>
Sent: Thursday, December 03, 2009 12:40 AM
Subject: Re: [Softwires] Host based translation: v4-v6
Hi, Good day to you all.
I hope you don't mind me commenting in your discussion.
[Xiangsong] +1
Could I ask you please to clarify whether you are discussing UE to UE
applications or UE application to hosted App servers?
If it is UE to App server, then surely the App server will need to be
dual
stacked as a prerequisite?
[Xiangsong] I don't think so, for the case IPv4 UE => IPv6 App server,
I think it fits section 2.2 of
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03
in this scenario, IVI stateless translation may be considered, but the
address space of
the IPv6 App server is limited. of course, DS App is better :)
More question is who is pushing IPv6 transition? although we are
studying
the solutions.
In my understanding, there are three players in this field, user,
carrier
and ISP,
#1 USER is the driving power? This seems what we are doing now, many
UE&PC
OS
can support IPv6, but IP service is few, sorry I only know Google
on
IPv6 service.
In this case, stateful translation is the most important candidate
solution.
But in my mind, Users do not care IPv4 or IPv6, they are invisible
to
users.
#2 CARRIER is the driving power? This is also an important direction,
especially for the IPv4 address shortage issue, I think DS lite is
for
this case,
many other tunnel solution may be considered.
#3 ISP is the driving power? I think ISP's involvement will quicken the
transition procedure.
But maybe we have not pay enough attention to this case? I don't
know
well the reason.
Is that because ISP is marketing driven but not technology driven?
ISP would more care what benefits they can get during the IPv6
transition?
In http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework-03,
it
is looked hard case,
and only IVI translation is mentioned (with some limitation), shall
we
pay more attention
on this item? Does Hui's approach cover this case?
Because these three players are independent, IMHO, two-players-drivern
transition is more
complex. As to UE to UE scenario, I have no idea.
Regards
Xiangsong
IMHO the reasons for why an app server can be IPv6-only are similar
reasons
to why IPv4 Port Address Translation breaks services - the need for nice
unique realms of IP addressing - does that make the use case of IPv4
legacy
UE to IPv6 only App server academic (assuming all GI-DSL and P-NAT
ultimately require some flavour of port address translation)? I doubt
anyone
in the operator's network or externally will create an IPv6 only App
server
just for the sake of it; which I guess supports Alain's and Sri's
conclusion
previously.
UE to UE is a little different I guess, so is this the driver Hui?
Hui, if you are considering UE to UE do you know of any UE to UE
applications implemented today?
Is the key use case (and differentiator) the UE to UE use case with
mixed
IPv6 and legacy IPv4-bound apps?
To be honest my personal thought is that we could drive UE to UE to be
via
IPv6 Apps at the UE and an IPv6 bearer only; is this wrong?
Thanks and Regards,
Nick
T-Mobile
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Hui Deng
Sent: 02 December 2009 15:36
To: Sri Gundavelli
Cc: [email protected]
Subject: Re: [Softwires] Host based translation: v4-v6
we have multiple reasons to do this,
there are lots of operator are planning to do IPv6 only, most of
people already see that.
one key point, we are doing IPv6, not IPv4,
you are proposing that let's support IPv4, and assign them unlimited
IPv4 address.
finally nobody use IPv6.
Thanks
-Hui
2009/12/2 Sri Gundavelli <[email protected]>:
I agree. When there is a case of v4 legacy app unable to use IPv6
transport
for what ever reasons, its rather better to go enable IPv4 on the
peer,
still supporting IPv6-only network over dual-stack lite network. Or,
modify
the app to use IPv6 transport and avoid the huge cost and management
of
dealing with a modified stack and on all OS variants. We are mainly
mixing
a
true legacy requirement with new requirements which are debatable.
Sri
On 12/1/09 9:04 AM, "Durand, Alain" <[email protected]>
wrote:
Why go through all that trouble when you could make the server app
dual-stack capable in the first place?
That could be done with or without assigning a unique v4 address to
it,
simply running v4 over v6...
Not you'd be back to a v4 app talking to a v4 app on hosts only having
v6
addresses configured natively.
- Alain.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
T-Mobile (UK) Limited
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield,
Hertfordshire,
AL10 9BW
Registered in England and Wales
NOTICE AND DISCLAIMER
This email (including attachments) is confidential. If you are not the
intended recipient, notify the sender immediately, delete this email
from
your system and do not disclose or use for any purpose.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
T-Mobile (UK) Limited
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire,
AL10 9BW
Registered in England and Wales
NOTICE AND DISCLAIMER
This email (including attachments) is confidential. If you are not the
intended recipient, notify the sender immediately, delete this email from
your system and do not disclose or use for any purpose.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
