Hi Sri, GW-Init-DS-Lite is the DS-Lite with only home gateway mode. Access mode is taken out on the grounds that it requires host modification. As such, GW-Init-DS-Lite seems to be aligned with or almost the same as PMIPv6 mobility solution described in Section 3 of draft-sarikaya-softwire-dslitemobility-01 where the gateway is LMA which is located at GGSN (we can say it is the AR) and home gateway is MAG which is located at SGSN. Of course the above could accomodate GTP by removing LMA or MAG terminology. Do you agree?
The other observation I have is that there are merits in the access mode of DS-Lite. Access mode of DS-Lite matches well with DSMIPv6 where the host has exactly the same functionality of encapsulating v4 in v6. This is explained as DSMIPv6 mobility solution in Section 4 of the above draft. Regards, Behcet ----- Original Message ---- > From: Sri Gundavelli <[email protected]> > To: Hui Deng <[email protected]> > Cc: [email protected] > Sent: Mon, November 30, 2009 9:38:46 PM > Subject: Re: [Softwires] Summary of the discussion Host based translation > forv4-v4 within the same network. > > Hi Hui: > > > > On Sun, 29 Nov 2009, Hui Deng wrote: > > > Dear Alain and Sri, > > > > Please allow me try to summarize the discussion about v4-v4 communication > > within the same sub-network. > > > > Please see below. > > > > > > GW-Init-DS-Lite > > Several thing not yet clear, it depends on what kind of PDP (v6/v4v6)? > > > > I dont see response to my specific questions in this email. > > Not sure, what scenario you are refering to. Overlapping or > non-overlapping ? I already explained how it works for non-overlapping > IP and about the use of IPv6 for UE to UE in general. > > > 1. The UE is assigned a v4v6 PDP context. > 2. The access network from SGSN to GGSN can be IPv6-only network. > The network can carry both IPv4 and IPv6 UE traffic over this > mobility tunnel. > 3. The tunnel from GGSN and CGN can be IPv6-only transport. > This leaves the access network and the core to IPv6-only, with > traces of IPv4 only on the UE, CGN and GGSN. We just have a > dual-stack UE and with the ability to carry the UE's IPv4 and IPv6 > traffic on the IPv6 network. > 4. Any UE to UE traffic, can always use IPv6. For legacy applications > and when non-overlapping IPv4 addresses are in use, all the UE packets > will hit the mobility tunnel and will arrive at the GGSN. For local > destinations, the GGSN can simply tunnel them to the correct > mobility tunnel, or to the CGN for internet destinations. > 5. For UE to UE over IPv4 and when overlapping addresses are in use, there > is no justification for this case. There is not a single legacy > application that supports this case today. So, it makes more sense to > use IPv6 for this case. Even otherwise, if there are clear requirements > to support UE to UE over IPv4-only and the justification is valid, it > can solved in couple of ways, per Alain's/Dan's draft, using implicit > tunnels. > > > > 1) definition of sub-network > > one example could be A: 10.1.1.2 and B: 10.1.1.3, then A knows > > he is in the same sub-network as B. > > > > 2) IPv4 address: Layer 2/v6PDP/v4v6PDP > > Issue 1: In the IPv6 only network, how could it happen? > > > > Your definition of the IPv6 network is the problem. When I say, > IPv6 only network, the UE is dual-stacked and the radio link can > carry both IPv4 and IPv6 packets, but the network from SGSN to > GGSN or from GGSN to CGN is all IPv6. The 3GPP mobility architecture > clearly allows the mobility tunnels to be IPv4 or IPv6, but still > carrying the UE's IPv4 and IPv6 traffic. Note that the traditional > dual-stack, router mode, the UE packets arrive as IPv4 to the > first hop router, still the network is IPv6-only. Same logic here. > Dont confuse IPv6-only network with air link or the dual-stack UE. > We are talking about IPv4 in the routed network. > > > > 3£©IPv6 prefix: either DHCPv6 or RA > > Issue: No > > > > Good > > > 4) DNS: B must have both A and AAAA record? > > Issue: if A received A and AAAA record, when to use 6-6 communication? > > and when to use v4-v6 host to host tunnel? > > > > The standard source address selection rules apply. If the target is > reachable via IPv6, it will use the IPv6, else it will use IPv4. We > are talking about IPv6-only network with IPv6 on all UE's. So, > where ever IPv6 is supported just use it. Per your requirements, IPv6 > is there always and on all UE's. For IPv4-only end points, NAT64 can > also be used. > > > > 5) Routing in the A: unconformed? > > if B has both AAAA and A, and B4 is within same sub-network with > > A4, then host to host tunnel > > if B has only A record, and B4 is within same sub-network with A4, > > > > Standard source address selection rules apply as above. > > > > 6) Host mdoification: Not clear yet,unconformed (mapping table, DNS) > > A: setup tunnel mapping between IPv4 address and IPv6 address > > B: setup tunnel mapping between IPv4 address and IPv6 address > > Issue 1: when A and B setup the mapping table? mapping table is > > translation? > > A: once received DNS A and AAAA record? > > B: when received the first tunnel packet? > > Issue 2: modify the host to support DNS processing, > > isn't this same as BIS/BIA? > > Issue 3: isn't this same as PNAT in the host? > > > > No changes on the host. I'm not talking about UE to UE over overlapping > IPv4 address scenario. So, dont assume I'm supporting that requirement, > as I said, IPv6 should be used for such non-legacy cases and clearly > when there is IPv6 available. If you want to solve that case, give a > single reason why that is needed. I dont believe its a valid requirement. > > > > 7) End to end routing: > > Need go through AR, but not AFTR. > > > > Yes. Local packets will not have to hit the CGN. > > Sri > > > > > Thanks for your checking > > > > -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
