Hi Hui,
On 12/2/09 7:20 AM, "Hui Deng" <[email protected]> wrote: > Hi, Sri, > > inline please, > > 2009/12/2 Sri Gundavelli <[email protected]>: >> Hi Hui, >> >> Now, we are closing down on identifying the gap. >> >> 1.) IPv6 App communicating with an IPv6 App >> 2.) IPv4 App communicating with an IPv4 App >> 3.) IPv6 App communicating with a legacy IPv4 App >> 4.) IPv4 legacy App communicating with a future IPv6 App >> >> Mainly, the gap seems to be #4 and you want to do host translation for that >> scenario. I agree, we do not support that scenario at this point. Surely, >> host translation is one option if you want to support that case. Or, one can >> do implicit tunnels (Per Alain/Dan's approach). But, I'm not convinced about >> that use-case. Your network is IPv6-only network, your host has IPv6-only >> transport, but why IPv6 cant be used ? If you give the legacy argument, that >> you cannot modify the application, its fine, but this is the case of a >> legacy app requiring to talk to a future IPv6 app. You will have to justify >> this requirement, given that there are no host to host applications (IPv4 to >> IPv6) deployed today. You can off course, simple add IPv4 support to the >> peer and done with it and that is a simple solution. > Thanks for your clear statement, not support the case, > I understand that you are not familiar with operation and application. Fine. Explain why you need to support the case of a legacy IPv4 application communicating with a IPv6 future application. This scenario is not there today. And, why in such scenario you cannot enable IPv4 on the peer ? Or, simply use IPv6. No matter what, you are supporting dual-stack terminals as well, you may forward a translated IPv6 packet on the air interface and on the access and core, but you are supporting IPv4 application and allowing them to communicate with IPv4 internet and so you are leading those packets to the NAT64 gateway. > There are > several reasons which have happened such as platform upgrading issue, > host application upgrading issues. > This is the fundamental driving force for us to do it. > May be in your PS document, you need to provide a detailed explanation for this. As far I see, no one is convinced about this argument, but I could be wrong. Enlighten me please. >> So, the motivation for that is not convincing and you end up modifying the >> entire host architecture, take the burden of ALG management and stack >> management on million operating systems for years to come. But, why and what >> cost ? > I read throught today DS-Lite and NAT64, none of them support > explicitly ALG, and how does it work. > you would better argue them other than here. > What ever you do on the host, they tunnel it and just do it at the gateway. I don't see the difference, and they don't change the host stack. > -Hui > >> >> >> Sri >> >> >> >> On 12/1/09 7:21 AM, "Hui Deng" <[email protected]> wrote: >> >>> Dear Alain and Sri, >>> >>> Based on previous discussion with you two, >>> I found there is a fundamental mis-understanding about our requirement. >>> >>> Back to last Behave working group meeting, I personally think that I >>> presented clearly about our >>> scenario and requirement about host to host communication is about v4 >>> appliation (host A) talk with v6 application (host B). >>> >>> I try to figure out what you would like to propose about v4-v4 during >>> that meeting with you in this list. >>> But anyhow, could you help to explain how your proposal could work in >>> our requirement and scenarios, >>> >>> Many thanks >>> >>> -Hui >> >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
