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. 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 ? 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
