Re: [MEXT] Gateway Initiated Dual-stack lite Support

[Hui Deng <denghui02 at gmail.com>]

So you are resolving IPv4 running out issue other than IPv6 issue
because GRE is used here.

-Hui

2009/10/17 Sri Gundavelli <sgundave at cisco.com>:
> Hi Ralph,
>
> Thanks for the comment. Please see below.
>
>
>
> On Sat, 17 Oct 2009, Ralph Droms wrote:
>
>> Quick question about your draft...
>>
>> I understand about stitching the tunnels together in a gateway.  In the
>> case of DS-lite, there is a NAT function in the DSLTC as well as a tunnel
>> concentrator function.  Presumably, that NAT function appeared somewhere
>> else in the scenarios you describe in the I-D.  Where is that NAT function
>> before the addition of DS-lite and how does DS-lite change the NAT function?
>>
>
> The application of DS-lite is not changing the placement of the NAT
> function. The NAT function is outside the anchor (HA/PDN), performing
> address translation on the MN's traffic, when overlapping addressing
> is in use. Now, if the home network and the access network are in
> seperate domains seperated by NAT (such as in RFC-3519, RFC-5555), the
> mobility tunnel may go through some translation, but that has no bearing
> on the MN's traffic and the placement of the NAT in the home network is
> still outside the anchor. The transport tunnel has little purpose in
> the the MN's addressing and translation context.
>
> Now, when we apply Dual-stack lite function to these architectures,
> based on any of the modes (GTP, MIPv6, or PMIPv6), we are making the
> anchor point (HA/LMA/PDN) perform the DS lite initiator function to
> the DSLTC (LSN), with no change in where the NAT is placed. We are
> building a unique softwire-id for each mobility session, but using a
> single tunnel between the anchor and the DSLTC, using GRE to identify
> the user flows. This is very close to the gateway mode that the DS-lite
> draft supports, except using GRE to identify the flows and mapping the
> access tunnel to the CGN tunnel.
>
> This approach results in:
>
> - Allocation of the same IP (overlapping addresses) to all MN's.
>  Solves the issues for some operators who dont have enough RFC-1918
>  address space
> - No *changes* to MN (UE)'s host stack, requirement for some handset
>  vendors
> - No bearing on the type of transport used for the mobility tunnel.
>  Allows the operator to migrate their network in incremental steps,
>  allowing IPv6-only or IPv4 transport network.
> - Just using NAT44 and we are not doing 4 to 6 translation and
>  back 6 to 4, avoiding all those side affects of NAT464.
> - No additional overahead of the CGN tunnel in the access network
>  or on the MN. Just one tunnel from the anchor to the LSN.
> - Minimal changes to anchor (HA/LMA/PDN).
>
> Regards
> Sri
>
>
>
>
>
>
>
>
>
>
>
>
>
>> - Ralph
>>
>> On Oct 13, 2009, at 9:27 PM 10/13/09, Sri Gundavelli wrote:
>>
>>>
>>> We have posted a draft on using Gateway Initiated Dual-stack lite
>>> approach for IPv6 migration support. Following is the pointer to
>>> the draft.
>>>
>>>
>>> http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00.txt
>>>
>>> The key aspect of this solution is the approach by which we are applying
>>> dual-stack lite solution to IP mobility architectures. In this gateway
>>> initiated dual-stack lite mode we are leveraging the mobile tunnel
>>> by extending it to the CGN, and by using a UE specific softwire for
>>> session identification.
>>
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>