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. 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 DS-lite/GI-DS-lite is applied to mobile architectures, we have all the required tools for migration. 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
