> -----Original Message----- > From: Sri Gundavelli > 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.
Hi, Sri, I believe you have talked to many operators and understand their requirements. But I am also sure you have NOT talked with EVERY operators and understand ALL requirements. From this thread, what I read is an operator is taking about its requirement scenario, then you guys tried to say there are different solutions meet other different requirements. For my understanding, you can not shrug off the requirement from legacy applications as easy as you said. Apple may be able to put considerable efforts to update and recompile all there legacy applications since they are in a walled garden and most of their applications are under their direct development. That's not a general case. Actually, apple is so special, we should consider it the last. Here, we are talking about thousands different applications from thousands different ICPs. Could you make sure they all have the extra budget for IPv6? I cannot. So, there are such reality requirements. Host-based translation approach actually helps these legacy applications be able to extend their services to IPv6 network. It helps to convence people IPv6 does not hurt you, it only brings you advantages. Eventually, it makes IPv6 migration smoother. BTW, this discuss should mainly be in behave wg, so I cc to both behave and softwire. Cheers, Sheng > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
