Subject: Re: [Softwires] Summary of the discussion Host based translation forv4-v4 within the same network.

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2009 12:27:15 -0800 (PST)

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-masked]>
> To: Hui Deng <[email-masked]>
> Cc: [email-masked]
> 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-masked]
> > https://www.ietf.org/mailman/listinfo/softwires
> >

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 1 Dec 2009 13:40:11 -0800 (PST)

Hi Behcet,

>   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.

There is no need to touch the access architecture. Today's mobility
architectures allow the mobility tunnel to carry both IPv4 and IPv6
packets. We focus on tunnel stiching the mobility and CGN tunnels.

>   Of course the above could accomodate GTP by removing LMA or MAG terminology.

We do not initiate tunnels from MAG to CGN. The gateway in the Gateway
initiated DS lite is not the first hop router, such as MAG, but a
router at the end of the mobility tunnel. We also dont initiate tunnels
from UE. And we dont require the CGN collocation with LMA, as we want
to support IPv6 core.

We focus on the tunnel stitch and with requiring no changes to UE, or to
the access architecture.

>  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.
>

It will add the extra tunnel over ahead and requires host changes for
supporting UE initiated mode. Instead we use the access tunnel and
stitch it with the CGN tunnel.

I'm not going to comment on what you have in mind, if you see merits
in the double tunnels or in other modes what ever you think, make a
case and convince folks.

Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2009 14:32:23 -0800 (PST)

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, December 1, 2009 3:40:11 PM
> >   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.

As I said above, the gateway is not MAG, it is AR/GGSN/PGW or LMA.
In -01 draft we also removed CGN or AFTR colocation with LMA.

But I am curious about tunnel initiation for the UE. 
Can you clarify that? 

Tunnel initiated by LMA, would it work for PMIPv6? Maybe it is an allowed feature, but restrict the operation into that specific choice?

 I don't think it would work for GTP but I am not sure.

> stitch it with the CGN tunnel.

Again, as I said above, DSMIPv6 UE already supports tunneling to HA and then you can stich it to AFTR.

So previously called host based now is access mode I think has some uses.

Regards,

Behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Dec 2009 14:41:15 -0800

> In -01 draft we also removed CGN or AFTR colocation with LMA.

You can make any changes you want in each of your iterations. But, if the
tunnel is initiated from the UE or MAG, and if CGN is not collocated, how
will the home agent see these IPv4 packets sent in a tunnel, or apply QoS or
other policies ? Where will the UE set up the tunnel to CGN or to HA ?

> Tunnel initiated by LMA, would it work for PMIPv6? Maybe it is an allowed
> feature, but restrict the operation into that specific choice?
> 

No, it will work. We always initiate the CGN tunnel from LMA/HA/PDN GW/GGSN.

> you can stich it to AFTR.

Great. That's what I mean when I say tunnel stitching of mobility and CGN
tunnels.

> So previously called host based now is access mode I think has some uses.

You need DS-lite client on the UE. Like I said, we dont plan to change
access architecture.

Sri

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Dec 2009 15:41:41 +1300

On 2009-11-30 19:47, Hui Deng wrote:
...
>     he is in the same sub-network as B.

I am having some trouble with this statement. How does
A know it is in the same *copy* of Net 10 as B? That all
depends where the address of B has come from. If it has come
from a third-party referral, it could be anywhere in the
universe.

You can't rely on the bits in an RFC1918 address to tell
you about adjacency, unless you know for sure that the address
has local scope. In your model, that seems to mean knowing for
sure that B is on the same access router. How does A know that?

    Brian

---

From: Hui Deng <[email-masked]>
Date: Wed, 2 Dec 2009 23:05:24 +0800

Hi, Sri,

Inline please

> I dont see response to my specific questions in this email.
Excuse me, I am swamped,

> 2. The access network from SGSN to GGSN can be IPv6-only network.
Here I don't agree, think it is typo. GTP tunnel could be over any
type of IP family.

>   can solved in couple of ways, per Alain's/Dan's draft, using implicit
As I replied in the previous email, you are assinging unlimited IPv4
address to the UE,
I don't see why you need migrate to IPv6.

> We are talking about IPv4 in the routed network.
What you described here either SGSN to GGSN, or GGSN to CGN,
both of them are bear network which could be closed network, I don't see
really deployment about IPv6.

>
>
>> 3）IPv6 prefix: either DHCPv6 or RA
>>     Issue: No
>>
>
> Good
>
Based on your explanation, I think it is the fundamental issue now,
how the host A could smartly identify when and how to use which IP
familiy and reachable.

> Standard source address selection rules apply as above.
Same as above, standard source address selection doesn't apply here.

> single reason why that is needed. I dont believe its a valid requirement.
thanks, for overlapping, you can't support the requirement,
back to non-overlapping, you need modify the host, if not please explain
how you could support different A/AAA record,

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 2 Dec 2009 23:13:59 +0800

> sure that B is on the same access router. How does A know that?
Normally enhanced DNS server will not advertise other domain's NET 10 address,
it's bad for referal, same problem as NAT64, so this solution doesn't
scale as I said.

thanks

-Hui