Hi Xiangsong, Please see inline.
On 12/2/09 6:03 PM, "Xiangsong Cui" <[email protected]> wrote: > 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 :) I agree, generally for this scenario of IPv4 UE to IPv6 App server, the stateless IVI can be used, or simply enable dual-stack on the server. But, bringing this to the context of the discussion, the host in this scenario is not a legacy IPv4 host, but has only IPv6 transport. So, for all practical purposes, the host can simply initiate an IPv6 session. The discussion was a very specific case, a legacy IPv4 application running on a IPv6-only transport platform and establishing an IPv6 session, which is the only standing case for supporting a host based translation solution. > 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. > Good points. The motivation for the discussion is to identify the key UE to UE scenarios, validate them to see what are the real requirements and note the available solutions for those cases. I listed the scenario's in my earlier mail, I'm hesitant to agree with one case, which is the only standing point for the entire PNAT solution. Regards Sri > 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
