draft-ietf-v6ops-incremental-cgn-00.txt   draft-ietf-v6ops-incremental-cgn-01.txt 
Network Working Group S. Jiang Network Working Group S. Jiang
Internet Draft D. Guo Internet Draft D. Guo
Intended status: Informational Huawei Technologies Co., Ltd Intended status: Informational Huawei Technologies Co., Ltd
Expires: May 17, 2010 B. Carpenter Expires: December 22, 2010 B. Carpenter
University of Auckland University of Auckland
November 16, 2009 June 18, 2010
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
draft-ietf-v6ops-incremental-cgn-00.txt draft-ietf-v6ops-incremental-cgn-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute working
other groups may also distribute working documents as Internet-Drafts. documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 22, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract Abstract
Global IPv6 deployment was slower than originally expected in the Global IPv6 deployment was slower than originally expected in the
last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6
transition issues become more critical and complicated. Host-based transition issues become more critical and complicated. Host-based
transition mechanisms are not able to meet the requirements while transition mechanisms are not able to meet the requirements while
most end users are not sufficiently expert to configure or maintain most end users are not sufficiently expert to configure or maintain
these transition mechanisms. Carrier Grade NAT with integrated these transition mechanisms. Carrier-Grade NAT (CGN) with integrated
transition mechanisms can simplify the operation of end users during transition mechanisms can simplify the operation of end users during
the IPv4/IPv6 migration or coexistence period. This document proposes the IPv4/IPv6 migration or coexistence period. This document proposes
an incremental Carrier-Grade NAT (CGN) approach for IPv6 transition. an incremental CGN approach for IPv6 transition. It can provide IPv6
It can provide IPv6 access services for IPv6-enabled end hosts and access services for IPv6-enabled end hosts and IPv4 access services
IPv4 access services for IPv4 end hosts while remaining most of for IPv4 end hosts while remaining most of legacy IPv4 ISP networks
legacy IPv4 ISP networks unchanged. It is suitable for the initial unchanged. It is suitable for the initial stage of IPv4/IPv6
stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and migration. Unlike NAT444 CGN alone, it also supports and encourages
encourages transition towards dual-stack or IPv6-only ISP networks. transition towards dual-stack or IPv6-only ISP networks. A smooth
transition mechanism is also described in this document. It
introduces an integrated configurable CGN device and an adaptive Home
Gateway (HG) device. Both HG and CGN are re-usable devices during
different transition periods. It avoid potential multiple upgrade.
ISPs have NOT to make a big transition decision. It enables IPv6
migration to be incrementally achieved according to the real user
requirements. So ISPs have NOT to make a big transition decision.
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction.................................................3
2. An Incremental CGN Approach..................................4 2. An Incremental CGN Approach..................................4
2.1. Incremental CGN Approach Overview.......................4 2.1. Incremental CGN Approach Overview.......................4
2.2. Choice of tunnelling technology.........................5 2.2. Choice of tunnelling technology.........................5
2.3. Behaviour of Dual-stack Home Gateway....................5 2.3. Behaviour of Dual-stack Home Gateway....................6
2.4. Behaviour of Dual-stack Carrier-Grade NAT...............6 2.4. Behaviour of Dual-stack CGN.............................6
2.5. Impact for existing end hosts and remaining networks....6 2.5. Impact for existing end hosts and remaining networks....7
2.6. Discussion..............................................6 2.6. IPv4/IPv6 intercommunication............................7
3. Migration towards IPv6 Core Network..........................7 2.7. Discussion..............................................7
3.1. Legacy communication in Phase 2.........................8 3. Smooth transition towards IPv6 infrastructure................8
4. Security Considerations......................................8 4. Security Considerations......................................9
5. IANA Considerations..........................................8 5. IANA Considerations..........................................9
6. Acknowledgements.............................................9 6. Acknowledgements.............................................9
7. Change Log...................................................9 7. Change Log [RFC Editor please remove].......................10
8. References...................................................9 8. References..................................................11
8.1. Normative References....................................9 8.1. Normative References...................................11
8.2. Informative References..................................9 8.2. Informative References.................................11
Author's Addresses.............................................11 Author's Addresses.............................................14
1. Introduction 1. Introduction
Up to now, global IPv6 deployment does not happen as was expected 10 Up to now, global IPv6 deployment does not happen as was expected 10
years ago. The progress was much slower than originally expected. years ago. The progress was much slower than originally expected.
Network providers were hesitant to take the first move while IPv4 was Network providers were hesitant to take the first move while IPv4 was
and is still working well. However, IPv4 address exhaustion is now and is still working well. However, IPv4 address exhaustion is now
confirmed to happen soon. The dynamically-updated IPv4 Address Report confirmed to happen soon. The dynamically-updated IPv4 Address Report
[IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA
unallocated address pool exhaustion and middle 2012 for RIR unallocated address pool exhaustion and middle 2012 for RIR
unallocated address pool exhaustion. Based on this fact, the Internet unallocated address pool exhaustion. Based on this fact, the Internet
industry appears to have reached consensus that global IPv6 industry appears to have reached consensus that global IPv6
deployment is inevitable and has to be done quite quickly. deployment is inevitable and has to be done quite quickly.
IPv4/IPv6 transition issues therefore become more critical and IPv4/IPv6 transition issues therefore become more critical and
complicated for the soon-coming global IPv6 deployment. Host-based complicated for the soon-coming global IPv6 deployment. Host-based
transition mechanisms alone are not able to meet the requirements in transition mechanisms alone are not able to meet the requirements in
all cases. Therefore, network supporting functions and/or new all cases. Therefore, network supporting functions and/or new
transition mechanisms with simple user-side operation are needed. transition mechanisms with simple user-side operation are needed.
Carried Grade NAT (CGN) alone creates operational problems, but does Carrier-Grade NAT (CGN) [I-D.nishitani-cgn], also called NAT444 CGN,
nothing to help IPv4/IPv6 transition. In fact it allows ISPs to delay alone creates operational problems, but does nothing to help
the transition, and therefore causes double transition costs (once to IPv4/IPv6 transition. In fact it allows ISPs to delay the transition,
add CGN, and again to support IPv6). and therefore causes double transition costs (once to add CGN, and
again to support IPv6).
Carrier-Grade NAT that integrates multiple transition mechanisms can CGN that integrates multiple transition mechanisms can simplify the
simplify the operation of end user services during the IPv4/IPv6 operation of end user services during the IPv4/IPv6 migration or
migration or coexistence period. CGNs are deployed on the network coexistence period. CGNs are deployed on the network side and
side and managed/maintained by professionals. On the user side, new managed/maintained by professionals. On the user side, new Home
CPE devices may be needed too. They may be provided by network Gateway (HG) devices may be needed too. They may be provided by
providers, depending on the specific business model. Dual-stack lite network providers, depending on the specific business model. Dual-
[DSLite] is a CGN-based solution that supports transition, but it stack lite [I-D.ietf-softwire-dual-stack-lite], also called DS-Lite,
requires the ISP to upgrade its network to IPv6 immediately. Many is a CGN-based solution that supports transition, but it requires the
ISPs hesitate to do this as the first step. Theoretically, DS-Lite ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to
can be used with double encapsulation (IPv4-in-IPv6-in-IPv4) but this do this as the first step. Theoretically, DS-Lite can be used with
seems even less likely to be accepted by an ISP and is not discussed double encapsulation (IPv4-in-IPv6-in-IPv4) but this seems even less
further. likely to be accepted by an ISP and is not discussed further.
This document proposes an incremental CGN approach for IPv6 This document proposes an incremental CGN approach for IPv6
transition. The approach is similar to DSLite, but the other way transition. The approach is similar to DS-Lite, but the other way
around. Technically, it mainly combines v4-v4 NAT with v6-over-v4 around. Technically, it mainly combines v4-v4 NAT with v6-over-v4
tunnelling functions along with some minor adjustment. It can provide tunnelling functions along with some minor adjustment. It can provide
IPv6 access services for IPv6-enabled end hosts and IPv4 access IPv6 access services for IPv6-enabled end hosts and IPv4 access
services for IPv4 end hosts, while leaving most of legacy IPv4 ISP services for IPv4 end hosts, while leaving most of legacy IPv4 ISP
networks unchanged. The deployment of this technology does not affect networks unchanged. The deployment of this technology does not affect
legacy IPv4 hosts with global IPv4 addresses at all. It is suitable legacy IPv4 hosts with global IPv4 addresses at all. It is suitable
for the initial stage of IPv4/IPv6 migration. It also supports for the initial stage of IPv4/IPv6 migration. It also supports
transition towards dual-stack or IPv6-only ISP networks. transition towards dual-stack or IPv6-only ISP networks.
A smooth transition mechanism is also described in this document. It
introduces an integrated configurable CGN device and an adaptive HG
device. Both CGN and HG are re-usable devices during different
transition periods. It avoid potential multiple upgrade. It enables
IPv6 migration to be incrementally achieved according to the real
user requirements. So ISPs have NOT to make a big transition
decision.
2. An Incremental CGN Approach 2. An Incremental CGN Approach
Most ISP networks are still IPv4. Network providers are starting to Most ISP networks are still IPv4. Network providers are starting to
provide IPv6 access services for end users. However, at the initial provide IPv6 access services for end users. However, at the initial
stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be
the majority for most ISP networks. ISPs would like to minimize the the majority for most ISP networks. ISPs would like to minimize the
changes on their IPv4 networks. Switching the whole ISP network into changes on their IPv4 networks. Switching the whole ISP network into
IPv6-only would be considered as a radical strategy. Switching the IPv6-only would be considered as a radical strategy. Switching the
whole ISP network to dual stack is less radical, but introduces whole ISP network to dual stack is less radical, but introduces
operational costs and complications. Although some ISPs have operational costs and complications. Although some ISPs have
successfully deployed dual stack routers, others prefer not to do successfully deployed dual stack routers, others prefer not to do
this as their first step in IPv6. However, they currently face two this as their first step in IPv6. However, they currently face two
urgent pressures - to compensate for an immediate shortage of IPv4 urgent pressures - to compensate for an immediate shortage of IPv4
addresses by deploying some method of address sharing, and to prepare addresses by deploying some method of address sharing, and to prepare
actively for the deployment of IPv6 address space and services. The actively for the deployment of IPv6 address space and services. ISPs
approach described in this draft addresses both of these pressures by facing only one pressure out of two could adopt either CGN (for
proceeding in two phases. shortage of IPv6 addresses) or 6rd (to provide IPv6 connectivity
services). The approach described in this draft is targeting to
addresses both of these pressures at the same time by combining v4-v4
CGN with v6-over-v4 tunnelling technologies.
2.1. Incremental CGN Approach Overview 2.1. Incremental CGN Approach Overview
The incremental CGN approach we propose is illustrated as the The incremental CGN approach we propose is illustrated as the
following figure. following figure.
+-------------+ +-------------+
|IPv6 Internet| |IPv6 Internet|
+-------------+ +-------------+
| |
+-------------+----------+ +-------------+----------+
+-----+ +--+ | IPv4 ISP +--+--+ | +--------+ +-----+ +--+ | IPv4 ISP +--+--+ | +--------+
|v4/v6|----|DS|=====+==========| CGN |-------+---| IPv4 | |v4/v6|----|DS|=====+==========| CGN |-------+---| IPv4 |
|Host | |HG| | Network +-----+ | | |Internet| |Host | |HG| | Network +-----+ | | |Internet|
+-----+ +--+ +--------------------+---+ +--------+ +-----+ +--+ +--------------------+---+ +--------+
_ _ _ _ _ _ _ _ _ _ _ | _ _ _ _ _ _ _ _ _ _ _ |
()_6_o_4_ _t_u_n_n_e_l_() +---------------------+ ()_6_o_4_ _t_u_n_n_e_l_() +---------------------+
| Existing IPv4 hosts | | Existing IPv4 hosts |
+---------------------+ +---------------------+
Figure 1: Phase 1 of incremental CGN approach with IPv4 ISP network Figure 1: incremental CGN approach with IPv4 ISP network
DS HG = Dual-Stack Home Gateway (CPE). DS HG = Dual-Stack Home Gateway (CPE).
The above figure shows only Phase 1, in which the ISP has not As showed in the above figure, the ISP has not significantly changed
significantly changed its IPv4 network. This approach enables IPv4 its IPv4 network. This approach enables IPv4 hosts to access the IPv4
hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 Internet and IPv6 hosts to access the IPv6 Internet. A dual stack
Internet. A dual stack host can be treated as an IPv4 host when it host can be treated as an IPv4 host when it uses IPv4 access service
uses IPv4 access service and as an IPv6 host when it uses IPv6 access and as an IPv6 host when it uses IPv6 access service. In order to
service. In order to enable IPv4 hosts to access IPv6 Internet and enable IPv4 hosts to access IPv6 Internet and IPv6 hosts to access
IPv6 hosts to access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement) can be
replacement) can be integrated with CGN. The integration of such integrated with CGN. The integration of such mechanisms is out of
mechanisms is out of scope for this document scope for this document
Two new types of devices need to be deployed in this approach: a Two new types of devices need to be deployed in this approach: a
dual-stack home gateway, which may follow the requirements of [6CPE], dual-stack home gateway, which may follow the requirements of
and dual-stack Carrier-Grade NAT. The dual-stack home gateway [I-D.ietf-v6ops-ipv6-cpe-router], and dual-stack CGN. The dual-stack
integrates IPv4 forwarding and v6-over-v4 tunnelling functions. It home gateway integrates IPv4 forwarding and v6-over-v4 tunnelling
may integrate v4-v4 NAT function, too. The dual-stack CGN integrates functions. It may integrate v4-v4 NAT function, too. The dual-stack
v6-over-v4 tunnelling and carrier-grade v4-v4 NAT functions. CGN integrates v6-over-v4 tunnelling and v4-v4 CGN functions.
2.2. Choice of tunnelling technology 2.2. Choice of tunnelling technology
In principle, this model will work with any form of tunnel between In principle, this model will work with any form of tunnel between
the DS HG and the dual-stack CGN. However, tunnels that require the DS HG and the dual-stack CGN. However, tunnels that require
individual configuration are clearly undesirable because of their individual configuration are clearly undesirable because of their
operational cost. Configured tunnels based directly on [RFC4213] are operational cost. Configured tunnels based directly on [RFC4213] are
therefore not suitable. A tunnel broker according to [RFC3053] would therefore not suitable. A tunnel broker according to [RFC3053] would
also have high operational costs. also have high operational costs.
Modified 6RD [6RD] technology appears suitable to support v6-over-v4 Modified 6RD [RFC5569, I-D.ietf-softwire-ipv6-6rd] technology appears
tunnelling with low operational cost. Modified GRE [RFC2784] with suitable to support v6-over-v4 tunnelling with low operational cost.
additional auto-configuration mechanism is also suitable to support Modified GRE [RFC2784] with additional auto-configuration mechanism
v6-over-v4 tunnelling. Other tunnelling mechanisms such as 6over4 is also suitable to support v6-over-v4 tunnelling. Other tunnelling
[RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing mechanisms such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site
Protocol (ISATAP) [RFC5214] or Virtual Enterprise Traversal (VET) Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] or Virtual
[VET] are also considered. If the ISP has an entirely MPLS Enterprise Traversal (VET) [RFC5558] are also considered. If the ISP
infrastructure between the CPE and the dual-stack CGN, it would also has an entirely MPLS infrastructure between the HG and the dual-stack
be possible to consider a 6PE [RFC4798] tunnel directly over MPLS. CGN, it would also be possible to consider a 6PE [RFC4798] tunnel
This would, however, only be suitable for an advanced CPE that is directly over MPLS. This would, however, only be suitable for an
unlikely to be found as a home gateway, and is not further discussed advanced HG that is unlikely to be found as a home gateway, and is
here. not further discussed here.
2.3. Behaviour of Dual-stack Home Gateway 2.3. Behaviour of Dual-stack Home Gateway
When a dual-stack home gateway receives a data packet from an end When a dual-stack home gateway receives a data packet from an end
host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4 host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4
data, the HG can directly forward it if there is no v4-v4 NAT running data, the HG can directly forward it to CGN if there is no v4-v4 NAT
on the HG. Or the HG translates packet source address from a HG-scope running on the HG. Or the HG translates packet source address from a
private IPv4 address into a CGN-scope private IPv4 address. The HG HG-scope private IPv4 address into a CGN-scope private IPv4 address,
records the v4-v4 address mapping information for inbound packets, then forwards it to CGN. The HG records the v4-v4 address mapping
just like normal NAT does. information for inbound packets, just like normal NAT does.
For IPv6 data, the HG needs to encapsulate the data into an IPv4 For IPv6 data, the HG needs to encapsulate the data into an IPv4
tunnel, which has the dual-stack CGN as the other end. Then the HG tunnel, which has the dual-stack CGN as the other end. Then the HG
sends the new IPv4 packet towards CGN. sends the new IPv4 packet towards CGN.
The HG records the mapping information between the tunnel and the The HG records the mapping information between the tunnel and the
source IPv6 address for inbound packets if HG uplinks to more than source IPv6 address for inbound packets if HG uplinks to more than
one CGN. Detailed considerations for the use of multiple CGNs by one one CGN. Detailed considerations for the use of multiple CGNs by one
HG are for further study. HG are for further study.
2.4. Behaviour of Dual-stack Carrier-Grade NAT 2.4. Behaviour of Dual-stack CGN
When a dual-stack CGN receives a data packet from a dual-stack home When a dual-stack CGN receives a data packet from a dual-stack home
gateway, it firstly checks whether the packet is a normal IPv4 packet gateway, it firstly checks whether the packet is a normal IPv4 packet
or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN
translates packet source address from a CGN-scope private IPv4 translates packet source address from a CGN-scope private IPv4
address into a public IPv4 address, and then send it to IPv4 Internet. address into a public IPv4 address, and then send it to IPv4
The CGN records the v4-v4 address mapping information for inbound Internet. The CGN records the v4-v4 address mapping information for
packets, just like normal NAT does. For a v6-over-v4 tunnel packet, inbound packets, just like normal NAT does. For a v6-over-v4 tunnel
the CGN needs to decapsulate it into the original IPv6 packet and packet, the CGN needs to decapsulate it into the original IPv6 packet
then send it to IPv6 Internet. The CGN records the mapping and then send it to IPv6 Internet. The CGN records the mapping
information between the tunnel and the source IPv6 address for information between the tunnel and the source IPv6 address for
inbound packets. inbound packets.
Depending on the deployed location of the CGN, it may use v6-over-v4 Depending on the deployed location of the CGN, it may use v6-over-v4
tunnels to connect to the IPv6 Internet. tunnels to connect to the IPv6 Internet.
2.5. Impact for existing end hosts and remaining networks 2.5. Impact for existing end hosts and remaining networks
This approach does not affect the remaining networks at all. Legacy This approach does not affect the remaining networks at all. Legacy
IPv4 ISP networks and their IPv4 devices remain in use. The existing IPv4 ISP networks and their IPv4 devices remain in use. The existing
IPv4 hosts, shown as the right box in Figure 1, either having global IPv4 hosts, shown as the right box in Figure 1, either having global
IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it
is now. Of course, these hosts, if they are upgraded to become dual- is now. Of course, these hosts, if they are upgraded to become dual-
stack hosts, can access IPv6 Internet through IPv4 ISP network by stack hosts, can access IPv6 Internet through IPv4 ISP network by
using IPv6-over-IPv4 tunnel technologies. using IPv6-over-IPv4 tunnel technologies.
2.6. Discussion 2.6. IPv4/IPv6 intercommunication
Although IPv6-only public services are not expected as long as there
is an IPv4-only customer base in the world, for obvious commercial
reasons. However, IPv4/IPv6 intercommunication may become issues in
many scenarios.
Each ISP can provide its IPv6-only customers with a network-layer
translation service to satisfy this need. Such a service is not fully
defined at this time, so we refer to it non-specifically as "NAT64".
Current work in the IETF is focussed on one particular proposal
[I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be
provided as a common service located at the border between the ISP
and the IPv4 Internet, beyond the dual stack CGN from the customer's
viewpoint. It may be integrated into CGN devices too.
[I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance
DS-lite solution with an additional feature to ease interconnection
between IPv4 and IPv6 realms. Furthermore, home users may encounter
the problem of reaching legacy IPv4-only public services from IPv6-
only clients. This problem could already exist in Phase 1, but will
become more serious as time goes on.
2.7. Discussion
For IPv4 traffic, this approach inherits all the problems of CGN For IPv4 traffic, this approach inherits all the problems of CGN
(e.g., scaling, and the difficulty of supporting well-known ports for (e.g., scaling, and the difficulty of supporting well-known ports for
inbound traffic). Application layer problems created by double NAT inbound traffic). Application layer problems created by double NAT
are for further study. are for further study.
If a different technology than v4-v4 NAT is chosen for IPv4 address If a different technology than v4-v4 NAT is chosen for IPv4 address
sharing, for example [APLUSP], the present approach could be suitably sharing, for example [I-D.ymbk-aplusp], the present approach could be
modified, for example replacing the v4-v4 NAT function by the A+P suitably modified, for example replacing the v4-v4 NAT function by
gateway function. the A+P gateway function.
However, for IPv6 traffic, a user behind the DS HG will see normal However, for IPv6 traffic, a user behind the DS HG will see normal
IPv6 service. We therefore observe that an IPv6 tunnel MTU of at IPv6 service. We therefore observe that an IPv6 tunnel MTU of at
least 1500 bytes would ensure that the mechanism does not cause least 1500 bytes would ensure that the mechanism does not cause
excessive fragmentation of IPv6 traffic nor excessive IPv6 path MTU excessive fragmentation of IPv6 traffic nor excessive IPv6 path MTU
discovery interactions. discovery interactions.
However, for IPv6 traffic, a user behind the DS HG will see normal However, for IPv6 traffic, a user behind the DS HG will see normal
IPv6 service. This, and the absence of NAT problems for IPv6, will IPv6 service. This, and the absence of NAT problems for IPv6, will
create an incentive for users and application service providers to create an incentive for users and application service providers to
prefer IPv6. prefer IPv6.
ICMP filtering [RFC4890] function may be included as part of CGN ICMP filtering [RFC4890] function may be included as part of CGN
functions. functions.
3. Migration towards IPv6 Core Network 3. Smooth transition towards IPv6 infrastructure
If the core network transits to IPv6, this approach can easily be
transited into Phase 2, in which the ISP network is either dual-stack
or IPv6-only.
For dual-stack ISP networks, dual-stack home gateways can simply
switch off the v6-over-v4 function and forward both IPv6 and IPv4
traffic directly while the dual-stack CGN only keeps its v4-v4 NAT
function. However, this is considered an unlikely choice, since we
expect ISPs to choose the approach described here because they want
to avoid dual-stack deployment completely.
For IPv6-only ISP networks, the dual-stack lite solution [DSLite], This incremental CGN approach can easily be transited from NAT444 CGN
which also needs dual-stack home gateway and CGN devices, can be or 6rd. NAT444 CGN solves the public address shortage issues in the
adopted for Phase 2. The best business model for this approach is current IPv4 infrastructure. However, it does not contribute towards
that CPE has integrated the functions for both Phase 1 and 2, and can IPv6 at all. This incremental CGN approach can inherit NAT444 CGN
automatically detect the change. For example, the DS HG can use the function while providing overlay IPv6 services. 6rd mechanism can
appearance of IPv6 Route Advertisement messages or DHCPv6 messages as also transform into this incremental CGN with small modifications.
a signal that Phase 2 has started. Then when ISPs decide to switch One consideration is that home gateways also have to be changed
from Phase 1 to Phase 2, it may be that only a configuration change correspondently.
or a minor software update is needed on the CGNs. The DS HG will then
switch automatically to DSLite mode. The only impact on the home user
will be to receive a different IPv6 prefix.
It will not be necessary for all customers of a given ISP to switch This incremental CGN can also easily be transited into IPv6-enabled
from Phase 1 to Phase 2 simultaneously; in fact it will be infrastructure, in which the ISP network is either dual-stack or
operationally better to switch small groups of customers (e.g. all IPv6-only. For dual-stack ISP networks, dual-stack home gateways can
those connected to a single point of presence). This is a matter of simply switch off the v6-over-v4 function and forward both IPv6 and
planning and scheduling. IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4
NAT function. However, this is considered an unlikely choice, since
we expect ISPs to choose the approach described here because they
want to avoid dual-stack deployment completely. For IPv6-only ISP
networks, the DS-Lite solution also needs dual-stack home gateway and
CGN devices.
3.1. Legacy communication in Phase 2 The best business model for this approach is that an integrated
configurable CGN device and an adaptive HG device. The integrated CGN
hardware may be integrated multiple functions, include NAT444 CGN,
6rd router, incremental CGN, DS-Lite CGN and dual-stack forwarding.
It could act as different device with only software configuration
change while the hardware and its physical position/connectivity
remains no change at all. HG has also integrated these correspondent
functions, and be able to automatically detect the change on the CGN
side.
We do not expect to see IPv6-only public services as long as there is For example, the appearance of IPv6 Route Advertisement messages or
an IPv4-only customer base in the world, for obvious commercial DHCPv6 messages can be used as a signal of DS-Lite CGN. Then when an
reasons. However, especially in Phase 2, IPv4/IPv6 intercommunication ISP decides to switch from incremental CGN to DS-Lite CGN, it may be
may become issues. [DSLInter] describes a proposal to enhance DS-lite that only a configuration change or a minor software update is needed
solution with an additional feature to ease interconnection between on the CGNs. The home gateway will then detect this change and switch
IPv4 and IPv6 realms. Furthermore, home users may encounter the automatically to DS-Lite mode. The only impact on the home user will
problem of reaching legacy IPv4-only public services from IPv6-only be to receive a different IPv6 prefix.
clients. This problem could already exist in Phase 1, but will become
more serious as time goes on. Each ISP can provide its IPv6-only
customers with a network-layer translation service to satisfy this
need. Such a service is not fully defined at this time, so we refer
to it non-specifically as "NAT64". Current work in the IETF is
focussed on one particular proposal [NAT64].
The NAT64 service can be provided as a common service located at the In this smooth transition model, both CGN and HG are re-usable
border between the ISP and the IPv4 Internet, beyond the dual stack devices during different transition periods. It avoid potential
CGN from the customer's viewpoint. It may be integrated into CGN multiple upgrade. It enables IPv6 migration to be incrementally
devices too. The question has been asked why it is better to do this achieved according to the real user requirements. ISPs have NOT to
than to distribute the NAT64 function by locating it in (or near) the make a big transition decision.
home gateway, so that relevant translation state resides only in the
HG. While this might be suitable in Phase 1, when the ISP still
provides full IPv4 connectivity, it would force all translated
traffic into DSLite tunnels in Phase 2. This seems undesirable.
4. Security Considerations 4. Security Considerations
Security issues associated with NAT have been documented in [RFC2663] Security issues associated with NAT have been documented in [RFC2663]
and [RFC2993]. and [RFC2993].
Further security analysis will be needed to understand double NAT Further security analysis will be needed to understand double NAT
security issues and tunnel security issues. However, since the tunnel security issues and tunnel security issues. However, since the tunnel
proposed here exists entirely within a single ISP network, between proposed here exists entirely within a single ISP network, between
the CPE and the CGN, the threat model is relatively simple. [RFC4891] the HG/CPE and the CGN, the threat model is relatively simple.
describes how to protect tunnels using IPSec, but it is not clear [RFC4891] describes how to protect tunnels using IPSec, but it is not
whether this would be an important requirement. An ISP could deem its clear whether this would be an important requirement. An ISP could
infrastructure to have sufficient security without additional deem its infrastructure to have sufficient security without
protection of the tunnels. additional protection of the tunnels.
The dual-stack home gateway will need to provide basic security for The dual-stack home gateway will need to provide basic security for
IPv6 [6CPESec]. Other aspects are described in [RFC4864]. IPv6 [I-D.ietf-v6ops-cpe-simple-security]. Other aspects are
described in [RFC4864].
5. IANA Considerations 5. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
6. Acknowledgements 6. Acknowledgements
Useful comments were made by Fred Baker, Dan Wing, Fred Templin, Useful comments were made by Fred Baker, Dan Wing, Fred Templin,
Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair,
Shin Miyakawa and other members of the IETF V6OPS working group. Shin Miyakawa and other members of the IETF V6OPS working group.
skipping to change at page 9, line 30 skipping to change at page 10, line 24
draft-jiang-v6ops-incremental-cgn-02, remove normative parts (to be draft-jiang-v6ops-incremental-cgn-02, remove normative parts (to be
documented in other WGs), 2009-07-06 documented in other WGs), 2009-07-06
draft-jiang-v6ops-incremental-cgn-03, revised after comments at v6ops draft-jiang-v6ops-incremental-cgn-03, revised after comments at v6ops
mailing list, 2009-09-24 mailing list, 2009-09-24
draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg docuemtn, draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg docuemtn,
2009-11-17 2009-11-17
draft-ietf-v6ops-incremental-cgn-01, revised after comments at v6ops
mailing list, 2010-06-21
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC2529, March 1999. Domains without Explicit Tunnels", RFC2529, March 1999.
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. "Generic Routing Encapsulation (GRE)", RFC 2784, March
2000.
8.2. Informative References 8.2. Informative References
[RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663, Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999. August 1999.
[RFC2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation [RFC2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation
- Protocol Translation (NAT-PT)", RFC 2766, February 2000. - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
skipping to change at page 10, line 35 skipping to change at page 12, line 12
[RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC4891, May 2007. RFC4891, May 2007.
[RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address
Translator - Protocol Translator (NAT-PT) to Historic Translator - Protocol Translator (NAT-PT) to Historic
Status", RFC 4966, July 2007. Status", RFC 4966, July 2007.
[RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[DSLite] A. Durand, R. Droms, B. Haberman and J. Woodyatt, "Dual- [RFC5558] F. Templin, "Virtual Enterprise Traversal (VET)", RFC 5558,
stack lite broadband deployments post IPv4 exhaustion", February 2010.
draft-durand-softwire-dual-stack-lite-01, work in progress.
[RFC5569] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures
(6rd)", RFC 5569, January 2010.
[IPUSAGE] G. Huston, IPv4 Address Report, March 2009, [IPUSAGE] G. Huston, IPv4 Address Report, March 2009,
http://www.potaroo.net/tools/ipv4/index.html. http://www.potaroo.net/tools/ipv4/index.html.
[6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures [I-D.ietf-softwire-dual-stack-lite]
(6rd)", draft-despres-6rd, work in progress. A. Durand, "Dual-stack lite broadband deployments post IPv4
exhaustion", draft-ietf-softwire-dual-stack-lite, work in
progress.
[6CPE] H. Singh, "IPv6 CPE Router Recommendations", draft-wbeebee- [I-D.ietf-softwire-ipv6-6rd]
ipv6-cpe-router, work in progress. W. Townsley and O. Troan, "IPv6 via IPv4 Service Provider
Networks '6rd'", draft-ietf-softwire-ipv6-6rd, work in
progress.
[6CPESec] J. Woodyatt, "Recommended Simple Security Capabilities in [I-D.ietf-v6ops-ipv6-cpe-router]
H. Singh, W. Beebee, C. Donley, B. Stark and O. Troan,
"IPv6 CPE Router Recommendations", draft-ietf-v6ops-ipv6-
cpe-router, work in progress.
[I-D.ietf-v6ops-cpe-simple-security]
J. Woodyatt, "Recommended Simple Security Capabilities in
Customer Premises Equipment for Providing Residential IPv6 Customer Premises Equipment for Providing Residential IPv6
Internet Service", draft-ietf-v6ops-cpe-simple-security, Internet Service", draft-ietf-v6ops-cpe-simple-security,
work in progress. work in progress.
[APLUSP] R. Bush, O. Maennel, J. Zorz, S. Bellovin and L. Cittadini, [I-D.ietf-behave-v6v4-xlate-stateful]
"The A+P Approach to the IPv4 Address Shortage", draft- M. Bagnulo, P. Matthews and I. van Beijnum, "NAT64: Network
ymbk-aplusp, work in progress. Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful, work in
progress.
[VET] F. Templin, "Virtual Enterprise Traversal (VET)", draft- [I-D.nishitani-cgn]
templin-autoconf-dhcp, work in progress. I. Yamagata, T. Nishitani, S. Miyahawa, A. nakagawa and H.
Ashida, "Common requirements for IP address sharing
schemes", draft-nishitani-cgn, work in progress.
[DSLInter] M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection [I-D.ymbk-aplusp]
R. Bush, "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp, work in progress.
[I-D.boucadair-dslite-interco-v4v6]
M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection
in the Context of DS-lite Deployment", draft-boucadair- in the Context of DS-lite Deployment", draft-boucadair-
dslite-interco-v4v6, work in progress. dslite-interco-v4v6, work in progress.
[NAT64] M. Bagnulo, P. Matthews and I. van Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64, work in progress.
Author's Addresses Author's Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd., Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China P.R. China
Phone: 86-10-82836774
Email: shengjiang@huawei.com Email: shengjiang@huawei.com
Dayong Guo Dayong Guo
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd., Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China P.R. China
Phone: 86-10-82836284
Email: guoseu@huawei.com Email: guoseu@huawei.com
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 49 change blocks. 
182 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/