On Thu, Dec 3, 2009 at 9:16 PM, Xiangsong Cui <[email protected]> wrote: > 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?
As many as the operators wants to turn-on and support. Dual stack is just adding functionality and does not take away functionality. IPv6-only is the end-game we have to work towards (some more long term than others) and the BEHAVE WG members are working on bridging that gap. > > 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
