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

From: Sri Gundavelli <[email-masked]>
Date: Tue, 13 Oct 2009 18:27:08 -0700 (PDT)

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.

Please review and comment.

Abstract

    Dual-Stack lite has been proposed as a IPv4 to IPv6 transition
    technology.  Dual-stack lite allows a service provider to migrate his
    network to IPv6, while still offering IPv4 services to the end
    customer.  The dual-stack lite solution uses an IPv4 over IPv6 tunnel
    between a host (or access device) and a dual-stack lite large scale
    NAT.  Several existing network architectures (e.g. 3GPP, WiMAX, or
    PPP based broadband networks) already specify dual-stack deployment
    and leverage tunneling technology between the access device and an
    access gateway in the provider network.  Applying the existing dual-
    stack lite concept to these networks will result in changes to the
    end-system and unnecessary tunneling overhead.  This draft describes
    a modified implementation of dual-stack lite where existing access
    tunnels are extended beyond the access gateway to the dual-stack lite
    large scale NAT using softwires.  This evolved approach applies to
    IPv4 as well as IPv6 networks.

Regards

---------- Forwarded message ----------
Date: Tue, 13 Oct 2009 18:08:24 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: New Version Notification for
     draft-gundavelli-softwire-gateway-init-ds-lite-00

A new version of I-D, draft-gundavelli-softwire-gateway-init-ds-lite-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository.

Filename:	 draft-gundavelli-softwire-gateway-init-ds-lite
Revision:	 00
Title:		 Gateway Initiated Dual-Stack Lite Deployment
Creation_date:	 2009-10-13
WG ID:		 Independent Submission
Number_of_pages: 21

Abstract:
Dual-Stack lite has been proposed as a IPv4 to IPv6 transition
technology.  Dual-stack lite allows a service provider to migrate his
network to IPv6, while still offering IPv4 services to the end
customer.  The dual-stack lite solution uses an IPv4 over IPv6 tunnel
between a host (or access device) and a dual-stack lite large scale
NAT.  Several existing network architectures (e.g. 3GPP, WiMAX, or
PPP based broadband networks) already specify dual-stack deployment
and leverage tunneling technology between the access device and an
access gateway in the provider network.  Applying the existing dual-
stack lite concept to these networks will result in changes to the
end-system and unnecessary tunneling overhead.  This draft describes
a modified implementation of dual-stack lite where existing access
tunnels are extended beyond the access gateway to the dual-stack lite
large scale NAT using softwires.  This evolved approach applies to
IPv4 as well as IPv6 networks.

The IETF Secretariat.

---

From: Ralph Droms <[email-masked]>
Date: Sat, 17 Oct 2009 08:26:38 -0400

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?

- Ralph

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 17 Oct 2009 07:06:58 -0700 (PDT)

Hi Ralph,

Thanks for the comment. Please see below.

On Sat, 17 Oct 2009, Ralph Droms wrote:

> 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

>> We have posted a draft on using Gateway Initiated Dual-stack lite approach 
>> for IPv6 migration support. Following is the pointer to
>> the draft.
>>