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
