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
