Network Working Group M. Boucadair, Ed.
Internet-Draft C. Jacquenet
Intended status: Informational JL. Grimault
Expires: October 31, 2009 M. Kassi Lahlou
P. Levis
France Telecom
April 29, 2009
Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment
draft-boucadair-dslite-interco-v4v6-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 October 31, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Boucadair, et al. Expires October 31, 2009 [Page 1]
Internet-Draft Extended DS-lite April 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo describes a proposal to enhance DS-lite solution with an
additional feature to ease interconnection between IPv4 and IPv6
realms. When deployed, no dual-stack-enabled network is required for
the delivery of both IPv4 and IPv6 connectivity to customers. Only
IPv6 is required to be deployed in core and access networks.
Particularly, IPv6 transfer capabilities are used for the transfer of
IPv4-addressed packets in a completely stateless scheme between the
interconnection segment and the DS-lite CGN node(s). This memo
proposes an IPv4-inferred scheme to build IPv6 addresses.
The proposed solution allows Service Providers to maintain an IPv6-
only network.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Boucadair, et al. Expires October 31, 2009 [Page 2]
Internet-Draft Extended DS-lite April 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Contribution of this draft . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 5
3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 7
3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Provisioning Information . . . . . . . . . . . . . . . 7
3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 8
3.3.3. Processing Operations . . . . . . . . . . . . . . . . 8
3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 10
3.4.1. Provisioning Information . . . . . . . . . . . . . . . 10
3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 10
3.4.3. Processing Operations . . . . . . . . . . . . . . . . 11
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Boucadair, et al. Expires October 31, 2009 [Page 3]
Internet-Draft Extended DS-lite April 2009
1. Introduction
1.1. Context
It is commonly agreed that IPv4 address shortage is a fact. Several
solutions have been proposed to cope with this sensitive issue. All
these solutions are based on IP address sharing and differ in where
the IP address sharing function is enforced.
The first category is denoted as Port Range
[I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp]. The
spirit of this category is to assign the same public IP address to
several customers' devices (called also port restricted devices)
together with a Port Range. Communications issued/destined to a
port-restricted device can be established only if the ports belong to
the provisioned Port Range. Dedicated means to provision the Port
Range have been proposed (see [I-D.bajko-pripaddrassign] and
[I-D.boucadair-pppext-portrange-option] for instance).
The second category is known as CGN (for Carrier Grade NAT). Two
main CGN flavors can be distinguished. Double NAT, in which two
levels of NAT are cascaded: one in the CPE and one in the network
(i.e. CGN). And DS-lite [I-D.ietf-softwire-dual-stack-lite] which
gets rid of the CPE NAT level. This solution requires a Dual Stack
CPE. Thus, a given CPE is assigned with an IPv6 prefix to be used
for its native IPv6 communications and also to encapsulate the IPv4
packets into IPv6 ones between the CPE and the DS-lite CGN. Note
that the deployment of DS-lite CGN equipment is not necessarily
centralized and several DS-lite CGN nodes may be deployed to handle
traffic issued/destined from/to end-user devices.
Whilst the DS-lite solution enhances the Double NAT scenario by
avoiding a NAT level and the allocation of a specific private IPv4
address to the CPE, it does not solve the IPv4-IPv6 interworking
issue.
1.2. Contribution of this draft
This memo proposes an extended DS-lite approach to solve both IPv4
address shortage and also to allow stateless IPv4-IPv6
interconnection. More precisely, this memo proposes to update DS-
lite nodes with new encapsulation and de-encapsulation capabilities
to be applied on the interface to core network of a given service
provider. Furthermore, a new function embedded in IPv6-IPv4
interconnection nodes (e.g. ASBR or a dedicated node) is also
introduced. The activation of the proposed solution allows a service
provider to operate a network which is IPv6-only.
Boucadair, et al. Expires October 31, 2009 [Page 4]
Internet-Draft Extended DS-lite April 2009
[I-D.boucadair-behave-ipv6-portrange] introduces a slightly modified
IPv4-IPv6 interworking function (which takes into account the port
number information) compatible with the Port Range based solutions.
2. Terminology
This memo makes use of the following terms:
o DS-lite CGN node: refers to the CGN node which behaviour is
specified in [I-D.ietf-softwire-dual-stack-lite]. This node
embedded a CGN function.
o Access segment: This segment encloses both IP access and backhaul
network.
o Interconnection segment: Includes all nodes and resources which
are deployed at the border of a given AS (Autonomous System) a la
BGP (Border Gateway Protocol).
o Core segment: Denotes a set of IP networking capabilities and
resources which are between the interconnection and the access
segments.
o Customer Attachment Device: A customer may use a terminal or a CPE
to access its subscribed services. This device is referred to as
Customer Attachment Device.
o IP connectivity information: A set of information (e.g. IP
address, default gateway, etc) required to access IP transfer
delivery service.
3. Procedure
This section describes an updated DS-lite solution.
3.1. Overall Procedure
The overall proposed procedure is summarised hereafter:
o A new IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF) is
introduced. This function may be hosted in an ASBR or a dedicated
node located at the interconnection between IPv6 and IPv4 domains.
This function is responsible for encapsulating all received IPv4
datagrams in IPv6 ones and de-encapsulating IPv4-in-IPv6
datagrams.
Boucadair, et al. Expires October 31, 2009 [Page 5]
Internet-Draft Extended DS-lite April 2009
o DS-lite CGN nodes are deployed in the access network. These nodes
are compliant with [I-D.ietf-softwire-dual-stack-lite]. In
addition, these nodes are enhanced with new IPv4-in-IPv6
encapsulation and de-encapsulation functions. These newly
introduced functions are stateless. Once these functions are
enabled, a given DS-lite node is responsible to handle IPv4-in-
IPv6 traffic in all its interfaces. No plain IPv4 traffic is
sent/received by the DS-lite CGN in all its interfaces. Only
IPv4-in-IPv6 packets are handled.
o Customer Attachment Devices are provisioned with an IPv6 prefix
that will not only be used for native IPv6 communication, but also
to encapsulate IPv4 datagrams. The proposed solution does no
require any modification on the customers side compared to what
has been listed in [I-D.ietf-softwire-dual-stack-lite].
This figure provides an overview of the overall environment.
Customers are connected to the service domain via a CPE device.
Several DS-lite CGN nodes are deployed to manage the traffic issued/
destined from/to end user device. The local domain is IPv6 only and
interconnection with adjacent IPv4 realms is implemented using IPv6-
IPv4 ICXF.
+--------------------------------+
| Service Domain | +-----------
+----+ | +---------+ | IPv4
|CPE1|---------| |IPv6-IPv4|----| Domain A
+----+ | | ICXF | |
| +---------+ +-----------
| +-------+ |
| |DS-lite| | +-----------
+----+ | | CGN A | +---------+ | IPv4
|CPE2|---------| +-------+ |IPv6-IPv4|----| Domain B
+----+ | | ICXF | |
| +---------+ +-----------
| +-------+ | |
| |DS-lite| | | +-----------
+----+ | | CGN B | | | | IPv4
|CPEi|---------| +-------+ | +-------| Domain C
+----+ | | |
| | +-----------
+--------------------------------+
|<---IPv6----------->|<-----IPv6------------->|<---IPv4----
Figure 1: Environment Overview
The following sub-sections provide more details about the proposed
Boucadair, et al. Expires October 31, 2009 [Page 6]
Internet-Draft Extended DS-lite April 2009
solution.
3.2. Customer Attachment Device
The Customer Attachment Device is provisioned with an IPv6 prefix and
the IPv6 address of a DS-lite CGN, by means of DHCPv6 for example.
For robustness reasons, the IPv6 address of a DS-Lite CGN is
recommended to be an anycast address.
A Customer Attachment Device encapsulates the privately addressed
IPv4 traffic in IPv6 datagrams. These messages are then forwarded
(without any NAT operation) towards a DS-lite CGN node.
As for incoming traffic, a Customer Attachment Device proceeds to de-
encapsulation operation. De-encapsulated datagrams are handled
locally or are forwarded to the appropriate machine connected to the
LAN behind the Customer Attachment Device.
The current specification does not require any modification on a DS-
lite compliant CPE.
3.3. DS-lite CGN Node
3.3.1. Provisioning Information
In addition to the required configuration information to activate DS-
lite mode described in [I-D.ietf-softwire-dual-stack-lite], DS-lite
CGN nodes are provisioned with:
o WKIPv6: an IPv6 prefix that can be assigned by IANA or extracted
from the prefix assigned to the service provider. This prefix is
used to build an IPv4-inferred IPv6 address. More information are
provided in Section 3.3.3.
o A set of IPv6 prefixes which are structured as WKIPv6+IPv4_addr:
* WKIPv6: the same as the one mentioned in the previous bullet.
* IPv4_addr is an IPv4 address used by the DS-lite CGN to enforce
its NAT44 operations.
* Several IPv4 addresses may be configured on a DS-lite node.
These IPv4 addresses may be aggregated, leading to aggregated
WKIPv6+IPv4_addr prefixes.
Boucadair, et al. Expires October 31, 2009 [Page 7]
Internet-Draft Extended DS-lite April 2009
3.3.2. Routing Considerations
A DS-lite node (or a third party) advertises in IGP the IPv6 prefixes
it manages (i.e. the set of WKIPv6+IPv4_addr prefixes described
above). Such announcement is required so that all traffic destined
to an IPv6 address belonging to an IPv6 prefix configured on the DS-
lite CGN node MUST be forwarded to the DS-Lite node.
3.3.3. Processing Operations
Figure 2 shows the input and output of a DS-lite CGN node.
+-------------------+
----IPv6---\ | |----IPv6---\
----IPv4---\\| |----IPv4---\\
-----------//| |-----------//
-----------/ | |-----------/
| DS-Lite |
/----IPv6---| CGN | /----IPv6---
//---IPv4----| |//---IPv4----
\\-----------| |\\-----------
\-----------| | \-----------
+-------------------+
Figure 2: Modified DS-lite CGN
Two main interfaces may be distinguished in a DS-lite CGN node:
a. Interface to the customer device.
b. Interface to core nodes.
The handling of the traffic received from a customer device is as
follows.
IPv4-in-IPv6 packets are de-encapsulated and then NAT operation is
applied. Once this operation is performed, the DS-lite node
encapsulates the NATed IPv4 datagrams in IPv6 ones using the
following information:
o Source IPv6 address: One of the DS-Lite node IPv6 addresses.
o Destination IPv6 address: WKIPv6+Original IPv4 address (i.e. the
destination IPv4 address contained in the encapsulated datagrams).
Encapsulated traffic is then forwarded until reaching another DS-lite
Boucadair, et al. Expires October 31, 2009 [Page 8]
Internet-Draft Extended DS-lite April 2009
CGN node, if the traffic remains in the same domain, or an IPv6-IPv4
Interconnection equipment.
o If datagrams are received by a DS-lite node (e.g. See Figure 3),
it de-encapsulates them and handles the embedded IPv4 ones
according to [I-D.ietf-softwire-dual-stack-lite].
o If received by an Interconnection node (e.g. See Figure 4), it
proceeds to a de-encapsulation operation and then the traffic is
forwarded to the next IPv4 destination according to installed IPv4
routes.
As illustrated in the figure, the communications between two CPEs
attached to a DS-lite enabled domain are implemented using IPv6 only
capabilities. IPv4 datagrams are encapsulated in IPv6 ones. The NAT
function is implemented by DS-lite CGN nodes.
+------+ +---------+ +---------+ +------+
| |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | |
| |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| |
| |---------//| |---------------//| |---------//| |
| |---------/ | |---------------/ | |---------/ | |
| CPE 1| | DS-lite | | DS-lite | | CPE2 |
| | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| |
| |//---IPv4--| |//----IPv4-------| |//--IPv4---| |
| |\\---------| |\\---------------| |\\---------| |
| | \---------| | \---------------| | \---------| |
+------+ +---------+ +---------+ +------+
Machines behind each CPE are not represented in the figure.
Figure 3: Flow Example involving two devices attached to the same DS-
lite enabled domain
Boucadair, et al. Expires October 31, 2009 [Page 9]
Internet-Draft Extended DS-lite April 2009
The following figure illustrates an example of a CPE, located behind
a DS-lite CGN node, which establishes a communication with a remote
machine (referred to as RM) which is IPv4-only.
+------+ +---------+ +---------+ +------+
| |--IPv6---\ | |------IPv6-----\ | | | |
| |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| |
| |---------//| |---------------//| |---------/| |
| |---------/ | |---------------/ | | | |
| CPE 1| | DS-lite | |IPv6-IPv4| | RM |
| | /---IPv6--| CGN A | /-----IPv6------| ICXF | | |
| |//---IPv4--| |//----IPv4-------| |/--IPv4---| |
| |\\---------| |\\---------------| |\---------| |
| | \---------| | \---------------| | | |
+------+ +---------+ +---------+ +------+
Machines located behind CPE1 are not represented in the figure.
Figure 4: Flow Example involving only one device attached to a DS-
lite enabled domain
3.4. IPv6-IPv4 Interconnection Function
As mentioned above, a dedicated node called IPv6-IPv4 Interconnection
function (IPv6-IPv4 ICXF) is required to interconnect an IPv6-only
domain (which hosts a DS-lite CGN function) and an IPv4 one. This
function is required to interconnect both realms without introducing
any additional NAT operation in the path.
The following sub-sections provide more information about the
behaviour of this function.
3.4.1. Provisioning Information
An IPv6-IPv4 Interconnection node is provisioned with a WKIPv6 which
is an IPv6 prefix that can be assigned by IANA or be part of the
service provider's prefix. This prefix is used to build IPv4-
inferred IPv6 addresses (structured as WKIPv6+IPv4_addr). IPv4_addr
refers to an IPv4 address (or network) that can be reached through
the IPv6-IPv4 Interworking node. These IPv4 addresses may be static
or dynamic (e.g. learned via a dedicated protocol such as BGP).
3.4.2. Routing Considerations
Two modes may be envisaged:
Boucadair, et al. Expires October 31, 2009 [Page 10]
Internet-Draft Extended DS-lite April 2009
o Static mode: IPv4-inferred IPv6 prefixes, structured as WKIPv6+
IPv4_addr, are provided to IPv6-IPv4 ICXF through a dedicated
configuration means (e.g. CLI).
o Dynamic mode: IPv6-IPv4 ICXF is responsible to build IPv4-inferred
IPv6 prefixes which are structured as WKIPv6+IPv4_addr.
The aforementioned IPv4-inferred IPv6 prefixes are then advertised in
IGP. Thus, IPv4-encapsulated traffic will reach the appropriate
IPv6-IPv4 ICXF.
3.4.3. Processing Operations
Figure 5 shows the input and output of an IPv6-IPv4 ICXF.
+-------------------+
----IPv6---\ | |
----IPv4---\\| |----IPv4---\
-----------//| |-----------/
-----------/ | |
| IPv6-IPv4 |
/----IPv6---| ICXF |
//---IPv4----| |/---IPv4----
\\-----------| |\-----------
\-----------| |
+-------------------+
Figure 5: IPv6-IPv4 Interworking Function
Concretely, when the interconnection node receives IPv4 traffic from
an adjacent domain, it encapsulates IPv4 datagrams in IPv6 using the
following information:
o Source IPv6 address: One of its own IPv6 addresses.
o Destination IPv6 address: WKIPv6+Original IPv4 address.
The traffic is then received by a DS-lite CGN node which de-
encapsulates the traffic and handles the embedded IPv4 one according
to current DS-lite specification [I-D.ietf-softwire-dual-stack-lite].
As for the IPv6 received traffic, an Interconnection node proceeds to
a de-encapsulation operation and then the traffic is forwarded to the
next IPv4 destination according to installed IPv4 routes.
Boucadair, et al. Expires October 31, 2009 [Page 11]
Internet-Draft Extended DS-lite April 2009
4. Design Considerations
The aforementioned functions (i.e. DS-lite CGN and IPv6-IPv4 ICXF)
may be hosted in the same node or distinct ones according to the
underlying topology constraints and dimensioning considerations.
Nevertheless for scalability reasons, it is not recommended to deploy
a DS-lite CGN function far (from the access network) in the network
since this would create a concentrator and then may be considered as
a single point of failure. Furthermore, the routing would not be
optimal, particularly for intra-domain traffic.
5. Conclusions
This proposal allows to migrate toward an IPv6-only network while
offering:
o Global IPv6 <==> IPv6 communications.
o Global IPv4 <==> IPv4 communications.
o A remote IPv6 host would reach a host connected to the DS-lite
enabled domain using IPv6.
o A remote IPv4 host would reach a host connected to the DS-lite
enabled domain using IPv4-in-IPv6.
Since end user's devices are DS(-lite), the appropriate connectivity
protocol (IPv4 or IPv6) is selected to issue outgoing traffic.
Therefore, IPv4-to-IPv6 and IPv6-to-IPv4 communications are not
considered as valid scenarios within the proposed architecture.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
TBC
Boucadair, et al. Expires October 31, 2009 [Page 12]
Internet-Draft Extended DS-lite April 2009
8. Acknowledgements
TBC
9. References
9.1. Normative References
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work
in progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-01 (work in progress),
March 2009.
[I-D.boucadair-behave-ipv6-portrange]
Boucadair, M., Levis, P., Grimault, J., Villefranque, A.,
and M. Kassi-Lahlou, "Flexible IPv6 Migration Scenarios in
the Context of IPv4 Address Shortage",
draft-boucadair-behave-ipv6-portrange-01 (work in
progress), March 2009.
[I-D.boucadair-port-range]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion", draft-boucadair-port-range-01 (work in
progress), January 2009.
[I-D.boucadair-pppext-portrange-option]
Boucadair, M., Levis, P., Grimault, J., and A.
Villefranque, "Port Range Configuration Options for PPP
IPCP", draft-boucadair-pppext-portrange-option-00 (work in
progress), February 2009.
[I-D.ymbk-aplusp]
Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L.
Cittadini, "The A+P Approach to the IPv4 Address
Boucadair, et al. Expires October 31, 2009 [Page 13]
Internet-Draft Extended DS-lite April 2009
Shortage", draft-ymbk-aplusp-03 (work in progress),
March 2009.
Authors' Addresses
Mohamed BOUCADAIR (editor)
France Telecom
3, Av Francois Chateaux
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Christian JACQUENET
France Telecom
Email: christian.jacquenet@orange-ftgroup.com
Jean Luc GRIMAULT
France Telecom
Email: jeanluc.grimault@orange-ftgroup.com
Mohammed KASSI LAHLOU
France Telecom
Email: mohamed.kassilahlou@orange-ftgroup.com
Pierre LEVIS
France Telecom
Email: pierre.levis@orange-ftgroup.com
Boucadair, et al. Expires October 31, 2009 [Page 14]