Hi Sri, I found the difference between your WG mailing list response and offline response, during offline, you agreed that other opeartor also agree me there are the same problem that they have diffculty to update their applications.
but anyway, I think you agreed now. thanks -Hui 2009/12/6 Sri Gundavelli <[email protected]>: > Hi Hui, > > As I said and to repeat one more time, I'm not convinced about that > use-case. This is not a legacy issue, there are no deployed applications > currently operating in that mode. We talked to many operators, every one is > planning to use IPv6 transport for the UE to UE scenario. This argument that > both the hosts are IPv6-only capable, but they cant use IPv6 transport is > not going to go any where. > > We are talking about four lines of code change to use an IPv6 socket. As > some one pointed out, when Apple released the new 3GS, all most 80K > applications required a re-compile. I don't get the point that you have an > IPv4 app, binaries only, but that will run on some future platform with out > recompile and talk to a future IPv6 application. May be your app development > process is broken, this is not a technical or a industry problem. > > I'm not deviating from this point, as I said many times, we don't deal with > this case, its not realistic and there is a work around. If you have any > advantages in the host-based translation approach that help in IPv6 > migration besides this artificial use-case, let me know. > > > Regards > Sri > > > > On 12/5/09 6:39 AM, "Hui Deng" <[email protected]> wrote: > >> Hi Sri, >> >> 2009/12/5 Sri Gundavelli <[email protected]>: >>> Hi Hui, >>> >>> >>>>> >>>>> 1. DS-lite has an important property, making IPv4 address some what >>>>> irrelevant in the context of IP routing and just make it a simple state in >>>>> two places, the mobile node and the NAT44 gateway. Its allowing the >>>>> network >>>>> to migrate to IPv6 day-1, remove traces of IPv4 in the core and access >>>>> network, but continue to offer IPv4 services. >>>> DS-Lite is providing unlimited IPv4 address to the UE, partly modify >>>> the small part of the bear network >>>> which could be constructed by multiple technologies such as GRE, L2TP, >>>> IPv6 tunnel. I don't see >>>> those tunnels have big difference. >>>> >>>>> If this is not migration what is it ? Now, if the technology is also >>>> It is "Save IPv4" as Bo said before, >>> >>> Hmm ... I cant beat this defense. >>> >>> I don't see you disagreeing with my technical points and the similarities I >>> have shown in both the approaches. But, I see that you do not want to agree >>> and so you summarize it to say, its still just a solution for IPv4-exhaust >>> and not a step towards migration, with no backing by any technical >>> arguments. That is fine. We agree or not, its just translation vs., >>> tunneling, a scheme that was adopted in the earlier versions of DS-lite and >>> made a conscious decision not to go with host-based translation scheme. >> We are discussing 4-6 scenario here, it sounds strange that it is >> always deviated to another direction. >> I don't see how it is related to translation vs tunneling. >> >>> >>> Bottom line, we touched about the core aspects and also one use-case that >>> you say is the key motivation for your chosen approach, which the use-case >>> itself is debatable and a clear solution exists as many folks pointed out, >>> enable dual-stack on the server, or use IPv6. We also talked about the key >>> resulting benefits in each of the solutions. As far I see it, when >> As far as I can see, the technical argument about our motivation >> hasn't been questioned any more. >> And for solutions, you already agreed that you are no supporting that. >> >>> DS-lite/GI-DS-lite is applied to mobile architectures, we have all the >>> required tools for migration. >> I guess that this is only said by one people, every other people has >> different opinion on this. >> >> -Hui >> >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >>> On 12/4/09 6:46 AM, "Hui Deng" <[email protected]> wrote: >>> >>>> Hi, Sri, >>>> >>>> Thanks for the discussion, inline please >>>> >>>> 2009/12/4 Sri Gundavelli <[email protected]>: >>>>> Hi Hui: >>>>> >>>>> You and Bo touched a very important point. Your point is that DS-lite is >>>>> just about IPv4 address exhaust and not about migration. You already heard >>>>> from Alain and that's the best source. But, I'll comment in the context of >>>>> mobile architectures and application of GI-DS-lite. >>>>> >>>>> 1. DS-lite has an important property, making IPv4 address some what >>>>> irrelevant in the context of IP routing and just make it a simple state in >>>>> two places, the mobile node and the NAT44 gateway. Its allowing the >>>>> network >>>>> to migrate to IPv6 day-1, remove traces of IPv4 in the core and access >>>>> network, but continue to offer IPv4 services. >>>> DS-Lite is providing unlimited IPv4 address to the UE, partly modify >>>> the small part of the bear network >>>> which could be constructed by multiple technologies such as GRE, L2TP, >>>> IPv6 tunnel. I don't see >>>> those tunnels have big difference. >>>> >>>>> If this is not migration what is it ? Now, if the technology is also >>>> It is "Save IPv4" as Bo said before, >>>> >>>>> allowing multiplicity assignment of the same IPv4 address to all mobile >>>>> nodes (since, the address is just a state on the gateway and is not used >>>>> for >>>>> IP routing), that's a side affect and solves the address exhaust problem >>>>> to >>>>> some extent. But, there is still limitation w.r.t the public address usage >>>>> on the NAT44 gateway. >>>> yes, this is really a smart technology which could save IPv4. >>>> >>>>> >>>>> 2. Lets look at PNAT. Your single biggest motivation is to allow your >>>>> legacy >>>>> IPv4 applications to work on an IPv6 host that has only IPv6 transport and >>>>> on IPv6-only core network. How are you achieving this ? Your IPv4 >>>> It has already happened, and you already see our slides. >>>> >>>>> application is using an IPv4 address (valid or invalid) and there is a >>>>> socket and translation state that is getting created on the host and on >>>>> the >>>>> NAT44 gateway, your routing is all based on IPv6. You are making IPv4 just >>>>> a >>>>> state in the host and on the gateway. >>>>> >>>>> What is the difference between #1 and #2 ? PNAT is solving all that >>>>> DS-lite >>>>> solves and also has an indirect property of solving the IPv4 address >>>>> exhaust >>>>> issue. But, its coming at a huge cost and baggage i.e., Host changes. >>>> We spend two weeks here, and you admit that you don't support our >>>> first scenario. >>>> do u need I point out the mailing list link about what you said? >>>> everybody is changing his host everyday by installing new software, >>>> you may be scared to change your laptop, but I am not that afraid. >>>> >>>>> 3. When I apply DS-lite to mobile architectures which already have good >>>>> support for dual-stack and the ability to carry both IPv4 and IPv6 on >>>>> mobility tunnels, its allowing an operator to migrate their network to >>>>> IPv6-only and is also solving the address exhaust issue. >>>>> >>>>> - No changes to UE >>>>> - UE can be IPv4-only or IPv6-only >>>>> - Access network can IPv6-only >>>>> - Core network (PGW-CGN) can be IPv6-only >>>>> - Allow IPv6 for UE to UE communication. Allow IPv4 to IPv4 UE to >>>>> communication when using non-overlapping IP addresses. Allow IPv6 >>>>> applications to communicate with IPv4 end node using NAT64. >>>>> - Allow access network and core network to migrate to IPv6 at different >>>>> point of time. >>>> I would say that you made a fantastic invention which really saves >>>> IPv4, good work. >>>> I come out of a good idea that during next IETF, we would better to >>>> propose a BoF about "Save IPv4" >>>> Bo could become the BoF chair (if AD allows), then invite >>>> GW-Init-DS-Lite ... to join. >>>> >>>>> But, its missing one hypothetical case, which the scenario is not >>>>> realistic >>>>> and even otherwise, one can always enable dual-stack on the other peer, or >>>>> use IPv6 transport. >>>>> >>>>> So, my friend, Dear Hui, there is no difference between what you want to >>>>> solve and what is on the table. Tell me, what I'm missing. >>>> Dear Sri, I really don't want to point to that link where you said a >>>> few days ago that you don't support it. >>>> >>>> Thanks >>>> >>>> -Hui >>>> >>>>> >>>>> >>>>> Regards >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12/3/09 4:43 AM, "Hui Deng" <[email protected]> wrote: >>>>> >>>>>> Hi, Sri, >>>>> >>>>>>> But, don't deal with the case of IPv4 legacy application communicating >>>>>>> with >>>>>>> a IPv6 future application using IPv4. By allowing that one case which >>>>>>> has >>>>>>> no >>>>>>> justification, you have to deal with the resulting baggage of host >>>>>>> translation and UE changes. Instead use IPv6 for host to host as you >>>>>>> say. >>>>>>> This is not a legacy issue. >>>>>> You are making two different seperated world, it won't success. >>>>>> You didn't answer my previous two emails in seperated line. >>>>>> I could ask here again, you are assigning unlimited IPv4 address to the >>>>>> host, >>>>>> and encouraging me to install IPv4 appliation server, I feel what you >>>>>> proposed >>>>>> is more like prolong IPv4 world and solveing the problem of IPv4 >>>>>> address exhaustion but not IPv6 migration. >>>>>> Based on your proposal, IETF would better to setup a working group about >>>>>> IPv4 address exhaustion about it, other than IPv6 migration. >>>>>> >>>>>> thanks >>>>>> >>>>>> -Hui >>>>>> >>>>> >>>>> >>> >>> > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
