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. > 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 :) 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
