[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Gateway Initiated Dual-stack lite Support
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.