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. If this is not migration what is it ? Now, if the technology is also 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. 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 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. 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. 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. 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
