draft-ietf-v6ops-incremental-cgn-02.txt   draft-ietf-v6ops-incremental-cgn-03.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: April 12, 2010 B. Carpenter Expires: July 4, 2011 B. Carpenter
University of Auckland University of Auckland
October 11, 2010 January 4, 2011
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
draft-ietf-v6ops-incremental-cgn-02.txt draft-ietf-v6ops-incremental-cgn-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute working Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on April 12, 2011. This Internet-Draft will expire on July 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
Global IPv6 deployment was slower than originally expected. As IPv4 Global IPv6 deployment was slower than originally expected. As IPv4
address exhaustion approaches, the IPv4 to IPv6 transition issues address exhaustion approaches, IPv4 to IPv6 transition issues become
become more critical and less tractable. Host-based transition more critical and less tractable. Host-based transition mechanisms
mechanisms used in dual stack environments are not able to meet the used in dual stack environments cannot meet all transition
transition requirements. Most end users are not sufficiently expert requirements. Most end users are not sufficiently expert to configure
to configure or maintain host-based transition mechanisms. Carrier- or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN)
Grade NAT (CGN) devices with integrated transition mechanisms can devices with integrated transition mechanisms can reduce the
reduce the operational change required during the IPv4 to IPv6 operational changes required during the IPv4 to IPv6 migration or
migration or coexistence period. coexistence period.
This document proposes an incremental CGN approach for IPv6 This document proposes an incremental CGN approach for IPv6
transition. It can provide IPv6 access services for IPv6-enabled transition. It can provide IPv6 access services for IPv6 hosts and
hosts and IPv4 access services for IPv4 hosts while leaving much of a IPv4 access services for IPv4 hosts, while leaving much of a legacy
legacy IPv4 ISP network unchanged. It is suitable for the initial ISP network unchanged during the initial stage of IPv4 to IPv6
stage of IPv4 to IPv6 migration. Unlike NAT444 based CGN alone, migration. Unlike CGN alone, incremental CGN also supports and
Incremental CGN also supports and encourages transition towards dual- encourages smooth transition towards dual-stack or IPv6-only ISP
stack or IPv6-only ISP networks. A smooth transition to IPv6 networks. An integrated configurable CGN device and an adaptive Home
deployment is also described in this document. Gateway (HG) device are described. Both are re-usable during
different transition phases, avoiding multiple upgrades. This enables
An integrated configurable CGN device and an adaptive Home Gateway IPv6 migration to be incrementally achieved according to real user
(HG) device are introduced. Both HG and CGN are re-usable devices requirements.
during different transition periods. It avoids potential multiple
upgrades. It enables IPv6 migration to be incrementally achieved
according to the real user requirements.
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 tunneling technology..........................5 2.2. Choice of tunneling technology..........................5
2.3. Behavior of Dual-stack Home Gateway.....................6 2.3. Behavior of Dual-stack Home Gateway.....................6
2.4. Behavior of Dual-stack CGN..............................6 2.4. Behavior of Dual-stack CGN..............................7
2.5. Impact for existing hosts and unchanged networks.........7 2.5. Impact for existing hosts and unchanged networks........7
2.6. IPv4/IPv6 intercommunication............................7 2.6. IPv4/IPv6 intercommunication............................7
2.7. Discussion.............................................7 2.7. Discussion..............................................8
3. Smooth transition towards IPv6 infrastructure................8 3. Smooth transition towards IPv6 infrastructure................9
4. Security Considerations......................................9 4. Security Considerations.....................................10
5. IANA Considerations.........................................9 5. IANA Considerations.........................................11
6. Acknowledgements............................................9 6. Acknowledgements............................................11
7. Change Log [RFC Editor please remove].......................10 7. Change Log [RFC Editor please remove].......................11
8. References.................................................11 8. References..................................................12
8.1. Normative References...................................11 8.1. Normative References...................................12
8.2. Informative References.................................11 8.2. Informative References.................................12
Author's Addresses............................................13 Author's Addresses.............................................15
1. Introduction 1. Introduction
Global IPv6 deployment did not happen as was forecast 10 years ago. Global IPv6 deployment did not happen as was forecast 10 years ago.
Network providers were hesitant to take the first move while IPv4 was Network providers were hesitant to make the first move while IPv4 was
and is still working well. However, IPv4 address exhaustion is and is still working well. However, IPv4 address exhaustion is
imminent. The dynamically-updated IPv4 Address Report [IPUSAGE] has imminent. The dynamically-updated IPv4 Address Report [IPUSAGE] has
analyzed this issue. It predicts early 2011 for IANA unallocated analyzed this issue. It predicts early 2011 for IANA unallocated
address pool exhaustion and middle 2012 for RIR unallocated address address pool exhaustion and middle 2012 for RIR unallocated address
pool exhaustion. Based on this fact, the Internet industry appears to pool exhaustion. Based on this fact, the Internet industry appears to
have reached consensus that global IPv6 deployment is inevitable and have reached consensus that global IPv6 deployment is inevitable and
has to be done expediently. has to be done expeditiously.
IPv4 to IPv6 transition issues therefore become more critical and IPv4 to IPv6 transition issues therefore become more critical and
complicated for the soon-coming global IPv6 deployment. Host-based complicated for the approaching 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-based supporting functions and/or new
transition mechanisms with simple user-side operation are needed. transition mechanisms with simple user-side operation are needed.
Carrier-Grade NAT (CGN) [I-D.nishitani-cgn], also called NAT444 CGN, Carrier-Grade NAT (CGN) [I-D.nishitani-cgn], also called NAT444 CGN
alone compounds IPv4 operational problems, but does nothing to or Large Scale NAT, compounds IPv4 operational problems when used
encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows alone, but does nothing to encourage IPv4 to IPv6 transition.
ISPs to delay the transition, and therefore increased double Deployment of NAT444 CGN allows ISPs to delay the transition, and
transition costs (once to add CGN, and again to support IPv6). therefore causes double transition costs (once to add CGN, and again
to support IPv6).
CGN deployments that integrate multiple transition mechanisms can CGN deployments that integrate multiple transition mechanisms can
simplify the operation of end user services during the IPv4 to IPv6 simplify the operation of end user services during the IPv4 to IPv6
migration and coexistence periods. CGNs are deployed on the network migration and coexistence periods. CGNs are deployed on the network
side and managed/maintained by professionals. On the user side, new side and managed/maintained by professionals. On the user side, new
Home Gateway (HG) devices may be needed too. They may be provided by Home Gateway (HG) devices may be needed too. They may be provided by
network providers, depending on the specific business model. Dual- network providers, depending on the specific business model. Dual-
stack lite [I-D.ietf-softwire-dual-stack-lite], also called DS-Lite, stack lite [I-D.ietf-softwire-dual-stack-lite], also called DS-Lite,
is a CGN-based solution that supports transition, but it requires the is a CGN-based solution that supports transition, but it requires the
ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to
do this as the first step. Theoretically, DS-Lite can be used with do this as the first step. Theoretically, DS-Lite can be used with
double encapsulation (IPv4-in-IPv6-in-IPv4) but this seems even less double encapsulation (IPv4-in-IPv6-in-IPv4) but this seems even less
likely to be accepted by an ISP and is not discussed in this likely to be accepted by an ISP and is not discussed in this
document. document.
This document proposes an incremental CGN approach for IPv6 This document proposes an incremental CGN approach for IPv6
transition. The approach is similar to DS-Lite, but the other way transition. It does not define any new protocols or mechanisms, but
describes how to combine existing proposals in an incremental
deployment. The approach is similar to DS-Lite, but the other way
around. It mainly combines v4-v4 NAT with v6-over-v4 tunneling around. It mainly combines v4-v4 NAT with v6-over-v4 tunneling
functions. It can provide IPv6 access services for IPv6-enabled hosts functions. It can provide IPv6 access services for IPv6-enabled hosts
and IPv4 access services for IPv4 hosts, while leaving most of legacy and IPv4 access services for IPv4 hosts, while leaving most of legacy
IPv4 ISP networks unchanged. The deployment of this technology does IPv4 ISP networks unchanged. The deployment of this technology does
not affect legacy IPv4 hosts with global IPv4 addresses at all. It is not affect legacy IPv4 hosts with global IPv4 addresses at all. It is
suitable for the initial stage of IPv4 to IPv6 migration. It also suitable for the initial stage of IPv4 to IPv6 migration. It also
supports transition towards dual-stack or IPv6-only ISP networks. supports transition towards dual-stack or IPv6-only ISP networks.
A smooth transition mechanism is also described in this document. It A smooth transition mechanism is also described in this document. It
introduces an integrated configurable CGN device and an adaptive HG introduces an integrated configurable CGN device and an adaptive HG
device. Both CGN and HG are re-usable devices during different device. Both CGN and HG are re-usable devices during different
transition periods. It avoid potential multiple upgrade. It enables transition periods, so they do not need to be replaced as the
IPv6 migration to be incrementally achieved according to the real transition proceeds. This enables IPv6 migration to be incrementally
user requirements. achieved according to the real user requirements.
2. An Incremental CGN Approach 2. An Incremental CGN Approach
Most consumers remain primarily IPv4. Network providers are starting Today, most consumers primarily use IPv4. Network providers are
to provide IPv6 access services for end users. At the initial stage starting to provide IPv6 access services for end users. At the
of IPv4 to IPv6 migration, IPv4 connectivity and traffic would initial stage of IPv4 to IPv6 migration, IPv4 connectivity and
continue to represent the majority of traffic for most ISP networks. traffic would continue to represent the majority of traffic for most
ISPs would like to minimize the changes to their IPv4 networks. ISP networks. ISPs would like to minimize the changes to their IPv4
Switching the whole ISP network into IPv6-only would be considered as networks. Switching the whole ISP network into IPv6-only would be
a radical strategy. Switching the whole ISP network to dual stack is considered as a radical strategy. Switching the whole ISP network to
less radical, but introduces operational costs and complications. dual stack is less radical, but introduces operational costs and
Although some ISPs have successfully deployed dual stack networks, complications. Although some ISPs have successfully deployed dual
others prefer not to do this as their first step in IPv6. However, stack networks, others prefer not to do this as their first step in
they currently face two urgent pressures - to compensate for an IPv6. However, they currently face two urgent pressures - to
immediate shortage of IPv4 addresses by deploying some method of compensate for an immediate shortage of IPv4 addresses by deploying
address sharing, and to prepare actively for the use of deployment of some method of address sharing, and to prepare actively for the use
IPv6 address space and services. ISPs facing only one pressure out of of deployment of IPv6 address space and services. ISPs facing only
two could adopt either CGN (for shortage of IPv6 addresses) or 6rd one pressure out of two could adopt either CGN (for shortage of IPv4
(to provide IPv6 connectivity services). The approach described in addresses) or 6rd (to provide IPv6 connectivity services). The
this draft is intended to address both of these pressures at the same approach described in this draft is intended to address both of these
time by combining v4-v4 CGN with v6-over-v4 tunneling technologies. pressures at the same time by combining v4-v4 CGN with v6-over-v4
tunneling 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_over_4_ _t_u_n_n_e_l_() +---------------------+
| Existing IPv4 hosts | | Existing IPv4 hosts |
+---------------------+ +---------------------+
Figure 1: 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 - Customer Premises Equipment).
As shown in the above figure, the ISP has not significantly changed As shown in the above figure, the ISP has not significantly changed
its IPv4 network. This approach enables IPv4 hosts to access the IPv4 its IPv4 network. This approach enables IPv4 hosts to access the IPv4
Internet and IPv6 hosts to access the IPv6 Internet. A dual stack Internet and IPv6 hosts to access the IPv6 Internet. A dual stack
host is treated as an IPv4 host when it uses IPv4 access service and host is treated as an IPv4 host when it uses IPv4 access service and
as an IPv6 host when it uses an IPv6 access service. In order to as an IPv6 host when it uses an IPv6 access service. In order to
enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement) access IPv4 Internet, NAT64 can be integrated with the CGN; see
can be integrated with the CGN. The integration of such mechanisms is Section 2.6 for details regarding IPv4/IPv6 intercommunication. The
out of scope for this document integration of such mechanisms is out of scope for this document.
Two new types of devices need to be deployed in this approach: a Two types of device need to be deployed in this approach: a dual-
dual-stack home gateway, which may follow the requirements of stack home gateway (HG), and a dual-stack CGN. The dual-stack home
[I-D.ietf-v6ops-ipv6-cpe-router], and a dual-stack CGN. The dual- gateway integrates both IPv6 and IPv4 forwarding and v6-over-v4
stack home gateway integrates IPv4 forwarding and v6-over-v4 tunneling functions. It should follow the requirements of
tunneling functions. It may integrate v4-v4 NAT functionality, too. [I-D.ietf-v6ops-ipv6-cpe-router], including IPv6 prefix delegation.
The dual-stack CGN integrates v6-over-v4 tunneling and v4-v4 CGN It may integrate v4-v4 NAT functionality, too. The dual-stack CGN
functions. integrates v6-over-v4 tunneling and v4-v4 CGN functions, as well as
standard IPv6 and IPv4 routing
The approach does not require any new mechanisms for IP packet
forwarding or encapsulation or decapsulation at tunnel end points.
The following sections describe how the HG and the incremental CGN
interact.
2.2. Choice of tunneling technology 2.2. Choice of tunneling 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 dual-stack HG and the dual-stack CGN. However, tunnels that
individual configuration are clearly undesirable because of their require individual configuration are clearly undesirable because of
operational cost. Configured tunnels based directly on [RFC4213] are their operational cost. Configured tunnels based directly on
therefore not suitable. A tunnel broker according to [RFC3053] would [RFC4213] are therefore not suitable. A tunnel broker according to
also have high operational costs. [RFC3053] would also have high operational costs and be unsuitable
for home users.
Modified 6RD [RFC5569, RFC5969] technology appears suitable to
support v6-over-v4 tunneling with low operational cost. Modified GRE
[RFC2784] with additional auto-configuration mechanism is also 6rd [RFC5569, RFC5969] technology appears suitable to support v6-
suitable to support v6-over-v4 tunneling. Other tunneling mechanisms over-v4 tunneling with low operational cost. GRE [RFC2784] with an
such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic additional auto-configuration mechanism is also able to support v6-
Tunnel Addressing Protocol (ISATAP) [RFC5214] or Virtual Enterprise over-v4 tunneling. Other tunneling mechanisms such as 6over4
Traversal (VET) [RFC5558] are also considered. If the ISP has an [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing
entirely MPLS infrastructure between the HG and the dual-stack CGN, Protocol (ISATAP) [RFC5214] or Virtual Enterprise Traversal (VET)
it would also be possible to consider a 6PE [RFC4798] tunnel directly [RFC5558] could be considered. If the ISP has an entirely MPLS
over MPLS. This would, however, only be suitable for an advanced HG infrastructure between the HG and the dual-stack CGN, it would also
that is unlikely to be found as a consumer device, and is not further be possible to use a 6PE [RFC4798] tunnel directly over MPLS. This
discussed here. would, however, only be suitable for an advanced HG that is unlikely
to be found as a consumer device, and is not further discussed here.
To simplify the discussion, we assume the use of 6rd.
2.3. Behavior of Dual-stack Home Gateway 2.3. Behavior of Dual-stack Home Gateway
When a dual-stack home gateway receives a data packet from a host, it When a dual-stack home gateway receives a data packet from a host, it
firstly checks whether the packet is IPv4 or IPv6. For IPv4 data, the will determine whether the packet is an IPv4 or IPv6 packet. The
HG can directly forward it to CGN in the absence of v4-v4 NAT on the packet will be handled by an IPv4 or IPv6 stack as appropriate. For
HG. Alternatively the HG translates packet source address from a HG- IPv4, and in the absence of v4-v4 NAT on the HG, the stack will
scope private IPv4 address into a CGN-scope private IPv4 address, and simply forward the packet to the CGN, which will normally be the IPv4
then forwards it towards the CGN. The HG records the v4-v4 address default router. If v4-v4 NAT is enabled, the HG translates the packet
mapping information for inbound packets, just like a normal NAT source address from a HG-scope private IPv4 address into a CGN-scope
gateway does. IPv4 address, performs port mapping if needed, and then forwards the
packet towards the CGN. The HG records the v4-v4 address and port
mapping information for inbound packets, like any other NAT.
For IPv6 data, the HG needs to encapsulate the data into an IPv4 For IPv6, the HG needs to encapsulate the data into an IPv4 tunnel
tunnel, which has the dual-stack CGN as the other end. The HG sends packet, which has the dual-stack CGN as the IPv4 destination. The HG
the new IPv4 packet towards CGN. sends the new IPv4 packet towards the CGN, for example using 6rd.
The HG records the mapping information between the tunnel and the If the HG is linked to more than one CGN, it will record the mapping
source IPv6 address for inbound packets if HG uplinks to more than information between the tunnel and the source IPv6 address for
one CGN. Detailed considerations for the use of multiple CGNs by one inbound packets. Detailed considerations for the use of multiple CGNs
HG are for further study. by one HG are for further study.
IPv4 packets from the CGN, and encapsulated IPv6 packets from the
CGN, will be translated or decapsulated according to the stored
mapping information and forwarded to the customer side of the HG.
2.4. Behavior of Dual-stack CGN 2.4. Behavior of Dual-stack CGN
When a dual-stack CGN receives a data packet from a dual-stack home When a dual-stack CGN receives an IPv4 data packet from a dual-stack
gateway, it firstly checks whether the packet is a normal IPv4 packet home gateway, it will determine whether the packet is a normal IPv4
or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN packet, which is non-encapsulated, or a v6-over-v4 tunnel packet
translates packet source address from a CGN-scope private IPv4 addressed to a tunnel end point within the CGN. For a normal IPv4
address into a public IPv4 address, and then send it to IPv4 packet, the CGN translates the packet source address from a CGN-scope
Internet. The CGN records the v4-v4 address mapping information for IPv4 address into a public IPv4 address, performs port mapping if
inbound packets, just like normal NAT does. For a v6-over-v4 tunnel necessary, and then forwards it normally to the IPv4 Internet. The
packet, the CGN needs to decapsulate it into the original IPv6 packet CGN records the v4-v4 address and port mapping information for
and then send it to IPv6 Internet. The CGN records the mapping inbound packets, just like a normal NAT does. For a v6-over-v4 tunnel
information between the tunnel and the source IPv6 address for packet, the tunnel end point within the CGN will decapsulate it into
inbound packets. the original IPv6 packet and then forward it to the IPv6 Internet.
The CGN records the mapping information between the tunnel and the
source IPv6 address for 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 a further
tunnels to connect to the IPv6 Internet. v6-over-v4 tunnel to connect to the IPv6 Internet.
Packets from the IPv4 Internet will be appropriately translated by
the CGN and forwarded to the HG, and packets from the IPv6 Internet
will be tunneled to the appropriate HG, using the stored mapping
information as necessary.
2.5. Impact for existing hosts and unchanged networks 2.5. Impact for existing hosts and unchanged networks
This approach does not affect the unchanged networks at all. Legacy This approach does not affect the unchanged parts of ISP networks at
IPv4 ISP networks and their IPv4 devices remain in use. The existing all. Legacy IPv4 ISP networks and their IPv4 devices remain in use.
IPv4 hosts, shown as the right box in Figure 1, either having global The existing IPv4 hosts, shown as the lower right box in Figure 1,
IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it either having global IPv4 addresses or behind v4-v4 NAT, can connect
is now. These hosts, if they are upgraded to become dual-stack hosts, to the IPv4 Internet as it is now. These hosts, if they are upgraded
can access IPv6 Internet through the IPv4 ISP network by using IPv6- to become dual-stack hosts, can access the IPv6 Internet through the
over-IPv4 tunnel technologies. IPv4 ISP network by using IPv6-over-IPv4 tunnel technologies. (See
section 2.7 for a comment on MTU size.)
2.6. IPv4/IPv6 intercommunication 2.6. IPv4/IPv6 intercommunication
IPv6-only public services are not expected as long as there is IPv6-only public services are not expected as long as there is
significant IPv4-only customer base in the world, for obvious significant IPv4-only customer base in the world, for obvious
commercial reasons. However, IPv4/IPv6 intercommunication may become commercial reasons. However, IPv4/IPv6 intercommunication may become
issues in many scenarios. issues in many scenarios.
An ISP can provide its IPv6-only customers with a network-layer The IETF is expected to standardize a recommended IPv4/IPv6
translation service to satisfy this need. Such a service is not fully translation algorithm, sometimes referred to as NAT64. It is
defined at this time, so we refer to it non-specifically as "NAT64". specified in
Current work in the IETF is focused on one particular proposal o "Framework for IPv4/IPv6 Translation"
[I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be [I-D.ietf-behave-v6v4-framework]
provided as a common service located at the border between the ISP o "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052]
and the IPv4 Internet, beyond the dual stack CGN from the customer's o "DNS64: DNS extensions for Network Address Translation from IPv6
viewpoint. It may be integrated into CGN devices too. Clients to IPv4 Servers" [I-D.ietf-behave-dns64]
o "IP/ICMP Translation Algorithm" [I-D.ietf-behave-v6v4-xlate]
o "Stateful NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers"
[I-D.ietf-behave-v6v4-xlate-stateful]
o "An FTP ALG for IPv6-to-IPv4 translation" [I-D.ietf-behave-ftp64]
[I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a The service, as described in the IETF's "Guidelines for Using IPv6
DS-lite solution with an additional feature to ease interconnection Transition Mechanisms during IPv6 Deployment"
between IPv4 and IPv6 realms. Home users may encounter the problem of [I-D.arkko-ipv6-transition-guidelines], provides for stateless
reaching legacy IPv4-only public services from IPv6-only clients. translation between hosts in an IPv4-only domain or which offer an
This problem already exists in early phases, but will become more IPv4-only service and hosts with an IPv4-embedded IPv6 address in an
serious over time. IPv6-only domain. It additionally provide access from IPv6 hosts with
general format addresses to hosts in an IPv4-only domain or which
offer an IPv4-only service. It does not provide any-to-any
translation. One result is that client-only hosts in the IPv6 domain
gain access to IPv4 services through stateful translation. Another
result is that the IPv6 network operator has the option of moving
servers into the IPv6-only domain while retaining accessibility for
IPv4-only clients, through stateless translation of an IPv4-embedded
IPv6 address.
Also, "Architectural Implications of NAT" [RFC2993] applies across
the service just as in IPv4/IPv4 translation: apart from the fact
that a system with an IPv4-embedded IPv6 address is reachable across
the NAT, which is unlike IPv4, any assumption on the application's
part that a local address is meaningful to a remote peer, and any use
of an IP address literal in the application payload, is a source of
service issues. In general, the recommended mitigation for this is
o Ideally, applications should use DNS names rather than IP address
literals in URLs, URIs, and referrals, and in general be network
layer agnostic.
o If they do not, the network may provide a relay or proxy that
straddles the domains. For example, an SMTP MTA with both IPv4
and IPv6 connectivity handles IPv4/IPv6 translation cleanly at the
application layer.
2.7. Discussion 2.7. Discussion
For IPv4 traffic, the incremental CGN approach inherits all the For IPv4 traffic, the incremental CGN approach inherits all the
problems of CGN address sharing techniques problems of CGN address sharing techniques
[I-D.ietf-intarea-shared-addressing-issues] (e.g., scaling, and the [I-D.ietf-intarea-shared-addressing-issues] (e.g., scaling, and the
difficulty of supporting well-known ports for inbound traffic). difficulty of supporting well-known ports for inbound traffic).
Application layer problems created by double NAT are for further Application layer problems created by double NAT are beyond the scope
study. of this document.
If a different technology than v4-v4 NAT is chosen for IPv4 address
sharing, for example [I-D.ymbk-aplusp], the present approach could be
suitably modified, for example replacing the v4-v4 NAT function by
the A+P gateway function.
For IPv6 traffic, a user behind the DS HG will see normal IPv6 For IPv6 traffic, a user behind the DS HG will see normal IPv6
service. We observe that an IPv6 tunnel MTU of at least 1500 bytes service. We observe that an IPv6 tunnel MTU of at least 1500 bytes
would ensure that the mechanism does not cause excessive would ensure that the mechanism does not cause excessive
fragmentation of IPv6 traffic nor excessive IPv6 path MTU discovery fragmentation of IPv6 traffic nor excessive IPv6 path MTU discovery
interactions. interactions. This, and the absence of NAT problems for IPv6, will
create an incentive for users and application service providers to
For IPv6 traffic, a user behind the DS HG will see normal IPv6 prefer IPv6.
service. This, and the absence of NAT problems for IPv6, will create
an incentive for users and application service providers to prefer
IPv6.
ICMP filtering [RFC4890] function may be included as part of CGN ICMP filtering [RFC4890] may be included as part of CGN functions.
functions.
3. Smooth transition towards IPv6 infrastructure 3. Smooth transition towards IPv6 infrastructure
The incremental CGN approach can easily be transited from NAT444 CGN Transition from pure NAT444 CGN or 6rd to the incremental CGN
or 6rd. NAT444 CGN solves the public address shortage issues in the approach is straightforward. The HG and CGN devices and their
current IPv4 infrastructure. However, it does not contribute towards locations do not have to be changed; only software upgrading may be
IPv6 deployment at all. The incremental CGN approach can inherit needed. In the ideal model, described below, even software upgrading
NAT444 CGN function while providing overlay IPv6 services. 6rd is not necessary; reconfiguration of the devices is enough. NAT444
mechanisms can also transform into this incremental CGN with small CGN solves the public address shortage issues in the current IPv4
modifications. One consideration is that home gateways also have to infrastructure. However, it does not contribute towards IPv6
be changed correspondently. deployment at all. The incremental CGN approach can inherit NAT444
CGN functions while providing overlay IPv6 services. 6rd mechanisms
can also transform smoothly into this incremental CGN model. However,
the home gateways need to be upgraded correspondingly to perform the
steps described below
The incremental CGN can also easily be transited into IPv6-enabled The incremental CGN can also easily be transitioned to an IPv6-
infrastructure, in which the ISP network is either dual-stack or enabled infrastructure, in which the ISP network is either dual-stack
IPv6-only. For dual-stack ISP networks, dual-stack home gateways can or IPv6-only.
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. This approach is considered an unlikely choice, since
we expect ISPs to choose the approach described as incremental CGN
here because they want to avoid or are unable to complete dual-stack
deployment completely. For IPv6-only ISP networks, the DS-Lite
solution also needs dual-stack home gateway and CGN devices.
The best model for the incremental CGN approach is that an integrated If the ISP prefers to move to dual-stack routing, the HG should
configurable CGN device and an adaptive HG device. The integrated CGN simply switch off its v6-over-v4 function when it observes native
hardware may integrate multiple functions, include NAT444 CGN, 6rd IPv6 RA or DHCPv6 traffic, and then forward both IPv6 and IPv4
router, incremental CGN, DS-Lite CGN and dual-stack forwarding. The traffic directly, while the dual-stack CGN keeps only its v4-v4 NAT
HG has to integrate these correspondent functions, and be able to function.
detect changes on the CGN side.
For example, the appearance of IPv6 Route Advertisement messages or However, we expect ISPs to choose the approach described as
DHCPv6 messages can be used as a signal the availability of DS-Lite incremental CGN here because they intend to avoid dual-stack routing,
CGN. When an ISP decides to switch from incremental CGN to DS-Lite and to move incrementally from IPv4-only routing to IPv6-only
CGN, it may be that only a configuration change or a minor software routing. In this case, the ideal model for the incremental CGN
update is needed on the CGNs. The home gateway can then detect this approach is that of an integrated configurable CGN device and an
change and switch automatically to DS-Lite mode. The only impact on adaptive HG device. The integrated CGN device will be able to support
the home user will be to receive a different IPv6 prefix. multiple functions, including NAT444 CGN, 6rd router (or an
alternative tunneling mechanism), DS-Lite, and dual-stack forwarding.
The HG has to integrate the corresponding functions, and be able to
detect relevant incremental changes on the CGN side. Typically the HG
will occasionally poll the CGN to discover which features are
operational. For example, starting from a pure IPv4-only scenario (in
which the HG treats the CGN only as an IPv4 default router), the HG
would discover by infrequent polling when 6rd became available. The
home user would then acquire an IPv6 prefix. At a later stage, the HG
would observe the appearance of native IPv6 Route Advertisement
messages or DHCPv6 messages to discover the availability of an IPv6
service including DS-Lite. Thus, when an ISP decides to switch from
incremental CGN to DS-Lite CGN, only a configuration change or a
minor software update is needed on the CGNs. The home gateway would
detect this change and switch automatically to DS-Lite mode. The only
impact on the home user will be to receive a different IPv6 prefix.
In the smooth transition model, both CGN and HG are re-usable devices In the smooth transition model, both CGN and HG are re-usable devices
during different transition periods. It avoids the potential multiple during different transition periods. This avoids potential multiple
upgrades. IPv6 migration may be incrementally achieved according to upgrades. Different regions of the same ISP network may be at
the real user requirements. different stages of the incremental process, using identical
equipment but with different configurations of the incremental CGN
devices in each region. Thus, IPv6 migration may be incrementally
achieved according to the real ISP and customer requirements.
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]. Security issues for large-scale address sharing,
including CGN, are discussed in [I-D.ietf-intarea-shared-addressing-
Further security analysis will be needed to understand double NAT issues]. The present specification does not introduce any new
security issues and tunnel security issues. However, since the tunnel features to CGN itself, and hence no new security considerations.
proposed here exists entirely within a single ISP network, between Security issues for 6rd are documented in [RFC5569, RFC5969] and
the HG/CPE and the CGN, the threat model is relatively simple. those for DS-Lite in [I-D.ietf-softwire-dual-stack-lite].
[RFC4891] describes how to protect tunnels using IPSec, but it is not
clear whether doing so would be an important requirement. An ISP
could deem its infrastructure to provide adequate security without
additional protection of the tunnels.
The dual-stack home gateway will need to provide basic security Since the tunnels proposed here exist entirely within a single ISP
network, between the HG/CPE and the CGN, the threat model is
relatively simple. [RFC4891] describes how to protect tunnels using
IPsec, but an ISP could reasonably deem its infrastructure to provide
adequate security without the additional protection and overhead of
IPsec. The intrinsic risks of tunnels are described in [I-D.ietf-
v6ops-tunnel-security-concerns], which recommends that tunneled
traffic should not cross border routers. The incremental CGN approach
respects this recommendation. To avoid other risks caused by tunnels,
it is important that any security mechanisms based on packet
inspection, and any implementation of ingress filtering, are applied
to IPv6 packets after they have been decapsulated by the CGN. The
dual-stack home gateway will need to provide basic security
functionality for IPv6 [I-D.ietf-v6ops-cpe-simple-security]. Other functionality for IPv6 [I-D.ietf-v6ops-cpe-simple-security]. Other
aspects are described in [RFC4864]. 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, Joel Jaeggli and other members of the IETF V6OPS Shin Miyakawa, Joel Jaeggli, Jari Arkko, Tim Polk, Sean Turner and
working group. other members of the IETF V6OPS working group.
7. Change Log [RFC Editor please remove] 7. Change Log [RFC Editor please remove]
draft-jiang-incremental-cgn-00, original version, 2009-02-27 draft-jiang-incremental-cgn-00, original version, 2009-02-27
draft-jiang-v6ops-incremental-cgn-00, revised after comments at draft-jiang-v6ops-incremental-cgn-00, revised after comments at
IETF74, 2009-04-23 IETF74, 2009-04-23
draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops
mailing list, 2009-06-30 mailing list, 2009-06-30
skipping to change at page 11, line 5 skipping to change at page 11, line 43
draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg document, draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg document,
2009-11-17 2009-11-17
draft-ietf-v6ops-incremental-cgn-01, revised after comments at v6ops draft-ietf-v6ops-incremental-cgn-01, revised after comments at v6ops
mailing list, 2010-06-21 mailing list, 2010-06-21
draft-ietf-v6ops-incremental-cgn-02, revised after comments at v6ops draft-ietf-v6ops-incremental-cgn-02, revised after comments at v6ops
WGLC, 2010-10-11 WGLC, 2010-10-11
draft-ietf-v6ops-incremental-cgn-03, revised according comments from
IESG, 2011-1-4
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 "Generic Routing Encapsulation (GRE)", RFC 2784, March
2000. 2000.
[RFC5569] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures
(6rd)", RFC 5569, January 2010.
[RFC5969] W. Townsley and O. Troan, "IPv6 via IPv4 Service Provider [RFC5969] W. Townsley and O. Troan, "IPv6 via IPv4 Service Provider
Networks '6rd'", RFC5969, May 2010. Networks '6rd'", RFC5969, May 2010.
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
- Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993, [RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 [RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms [RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms
skipping to change at page 12, line 8 skipping to change at page 13, line 8
[RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E. [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E.
Klein, "Local Network Protection for IPv6", RFC 4864, May Klein, "Local Network Protection for IPv6", RFC 4864, May
2007. 2007.
[RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering [RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[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
Translator - Protocol Translator (NAT-PT) to Historic
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.
[RFC5558] F. Templin, "Virtual Enterprise Traversal (VET)", RFC 5558, [RFC5558] F. Templin, "Virtual Enterprise Traversal (VET)", RFC 5558,
February 2010. February 2010.
[RFC5569] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
(6rd)", RFC 5569, January 2010. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
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.
[I-D.ietf-softwire-dual-stack-lite] [I-D.ietf-softwire-dual-stack-lite]
A. Durand, "Dual-stack lite broadband deployments post IPv4 A. Durand, "Dual-stack lite broadband deployments post IPv4
exhaustion", draft-ietf-softwire-dual-stack-lite, work in exhaustion", draft-ietf-softwire-dual-stack-lite, work in
progress. progress.
[I-D.ietf-v6ops-ipv6-cpe-router] [I-D.ietf-v6ops-ipv6-cpe-router]
skipping to change at page 13, line 10 skipping to change at page 14, line 5
[I-D.ietf-intarea-shared-addressing-issues] [I-D.ietf-intarea-shared-addressing-issues]
M. Ford, et al, "Issues with IP Address Sharing", draft- M. Ford, et al, "Issues with IP Address Sharing", draft-
ietf-intarea-shared-addressing-issues, work in progress. ietf-intarea-shared-addressing-issues, work in progress.
[I-D.nishitani-cgn] [I-D.nishitani-cgn]
I. Yamagata, T. Nishitani, S. Miyahawa, A. nakagawa and H. I. Yamagata, T. Nishitani, S. Miyahawa, A. nakagawa and H.
Ashida, "Common requirements for IP address sharing Ashida, "Common requirements for IP address sharing
schemes", draft-nishitani-cgn, work in progress. schemes", draft-nishitani-cgn, work in progress.
[I-D.ymbk-aplusp] [I-D.arkko-ipv6-transition-guidelines]
R. Bush, "The A+P Approach to the IPv4 Address Shortage", Arkko, J. and F. Baker, "Guidelines for Using IPv6
draft-ymbk-aplusp, work in progress. Transition Mechanisms during IPv6 Deployment", draft-arkko-
ipv6-transition-guidelines, work in progress.
[I-D.boucadair-dslite-interco-v4v6] [I-D.ietf-behave-dns64]
M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
in the Context of DS-lite Deployment", draft-boucadair- "DNS64: DNS extensions for Network Address Translation from
dslite-interco-v4v6, work in progress. IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64,
work in progress.
[I-D.ietf-behave-ftp64]
Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
draft-ietf-behave-ftp64, work in progress.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework,
work in progress.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate, work in
progress.
Author's Addresses Author's Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Building, No.3 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
Email: shengjiang@huawei.com Email: shengjiang@huawei.com
 End of changes. 51 change blocks. 
241 lines changed or deleted 321 lines changed or added

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