Reply in line. On Thu, Dec 3, 2009 at 12:22 PM, Sri Gundavelli <[email protected]> wrote:
> Hi Xiangsong, > > Please see inline for one clarification. > > > > > In this situation, NAT is necessary, I do agree your opinion that PNAT > > is moving NAT function from network to UEs, but this approach may be > > good or bad. > > > > Advantage: it can improve end-to-end transparency and simplify network, > > especially administration, and others. > > The discussion slightly digressed. But, its fine and for this comment, its > not really true that host translation will preserve end-to-end > transparency. > That is a myth. Any time Hui's PNAT host with its IPv6 transport > communicates with an IPv4 host on the internet, Hui will move the IPv6 > packet translated from the IPv4 packet to the NAT64 gateway (to be precise, > PNAT64) anyways, and there the IPv6 to IPv4 packet translation will be > done. > In fact, per Hui its only header translation on the host and the payload > translation is done on the CGN gateway. So, there goes the end-to-end > transparency and the simplified network argument. > [Bo] If in 4-6-4 scenario PNAT goes the E2E transparency argument. I believe DS-lite will goes the argument as well. DS-Lite need the AFTR has the capability of 44 translation, also against the concept of E2E transparency. > > > Disadvantage: it improve the UE cost explicitly, and others. > > > > And exponentially, consider all the OS's and version variants. But, on a > lighter note, there is one more advantage point that you missed, employment > for many folks for years to come for managing the PNAT stack on many OS's > :) > [Bo] If it is true, it is really a good solution not only for the company but also for the global economy crisis. How to encourage company hire more employees is a big headache of governments, like Obama pointed out couple weeks ago. Go back to the earth, I am not sure which solution make more cost, update the host stack by a tiny software upgrade or buy hundreds of hardware equipments which cost hundred million dollars. suppose you can show us some financial validation result as your evidence. if not, please do not make this as a challenge point here. Regards, Bo Regards Sri > > > > > What I am not sure, is this approach easy to implement? > > Is there any cheap middle-ware that UE can implement? if UEs can > > download some middle-ware from their operator, there is no problemt. > > Of course, this requires UEs to support this function. or if UEs like, > they > > can in-build this function when they are manufactured. > > Another case is custom-built UEs, this is a normal case, operator insert > > something in the UEs, all IPv4 applications may be re-used, and IPv6-only > > applications and IPv6-only network are both OK. > > > > Does that make sense? > > > > Regards > > Xiangsong > >> > >> > >> > >>> 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. > >> > >> > > > > [......] > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > -- Regards, Bo Zhou China Mobile
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
