Network Working Group M. Boucadair, Ed.
Internet-Draft C. Jacquenet
Intended status: Standards Track JL. Grimault
Expires: April 8, 2010 M. Kassi-Lahlou
P. Levis
France Telecom
D. Cheng
Huawei Technologies Co., Ltd.
Y. Lee
Comcast
October 5, 2009
Deploying Dual-Stack lite in IPv6-only Network
draft-boucadair-dslite-interco-v4v6-02
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 April 8, 2010.
Boucadair, et al. Expires April 8, 2010 [Page 1]
Internet-Draft Extended DS-lite October 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
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 Dual-Stack lite (DS-lite)
[I-D.ietf-softwire-dual-stack-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. IPv6 transfer
capabilities are used for the transfer of IPv4-addressed datagrams in
a completely stateless scheme between the interconnection segment and
the DS-lite CGN node(s). The proposed DS-lite extension is meant to
encourage (if not accelerate) IPv6 deployment in networks.
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 April 8, 2010 [Page 2]
Internet-Draft Extended DS-lite October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 4
1.2. Dual-Stack lite . . . . . . . . . . . . . . . . . . . . . 4
1.3. Contribution of this draft . . . . . . . . . . . . . . . . 4
1.4. What's new compared to RFC5565 . . . . . . . . . . . . . . 5
1.5. Changes since 01 . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Global Architecture . . . . . . . . . . . . . . . . . . . 7
3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 8
3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Provisioning Information . . . . . . . . . . . . . . . 9
3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 10
3.3.3. Processing Operations . . . . . . . . . . . . . . . . 10
3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 12
3.4.1. Provisioning Information . . . . . . . . . . . . . . . 13
3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 13
3.4.3. BGP Behavior . . . . . . . . . . . . . . . . . . . . . 14
3.4.4. Processing Operations . . . . . . . . . . . . . . . . 15
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15
5. Multicast Considerations . . . . . . . . . . . . . . . . . . . 16
6. Applicability in the context of A+P . . . . . . . . . . . . . 16
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Boucadair, et al. Expires April 8, 2010 [Page 3]
Internet-Draft Extended DS-lite October 2009
1. Introduction
1.1. IPv4 Address Exhaustion
IPv4 addresses are finite resources. The current prediction is that
RIRs will allocate their last /8s in 2012. Detailed information is
available at http://www.potaroo.net/tools/ipv4. To address this
problem, IETF has defined IPv6 Protocol [RFC2460] which extends the
32-bit address space to 128-bit address space. Unfortunately, IPv4
and IPv6 are incompatible. IPv6-only CPEs cannot reach IPv4 services
w/o address family translation. Consider the fact that the Internet
will take time to fully migrate to IPv6, the IETF community is
actively discussing techniques to make sure IPv4-to-IPv4
communications can still be established in IPv6 access network where
global IPv4 addresses have become a scarce resource that will be
shared between several customers. Dual-Stack lite (DS-lite)
[I-D.ietf-softwire-dual-stack-lite] is one of the potential
techniques.
1.2. Dual-Stack lite
DS-lite solution contains two major components: the DS-lite CPE
client which initiates the IPv4-in-IPv6 softwire towards the DS-lite
CGN node, and the DS-lite CGN node which terminates the IPv4-in-IPv6
softwire and performs NAT44 function on the IPv4 datagram. Hosts
connected to the CPE use RFC1918 addresses to source IPv4 datagrams.
The CPE forwards the IPv4 datagrams over the IPv4-in-IPv6 softwire
towards the DS-lite CGN node. The CGN receives the IPv4 datagrams,
performs NAT44 on them, and forwards them to the IPv4 Internet. The
DS-lite CGN is configured with a pool of public IPv4 addresses that
will be shared by multiple customers. Note that the deployment of
DS-lite CGN capabilities is not necessarily centralized and several
nodes may be deployed for load-balancing, redundancy and other
scalability considerations.
Current DS-lite specification defines that the DS-lite CGN nodes
communicate to both IPv4 and IPv6 networks. Consider the deployment
model where CGN nodes are deployed in the edge of the network, the
CGN nodes MUST connect to an IPv4 core network to forward IPv4
datagrams.
1.3. Contribution of this draft
This memo proposes an extended solution that allows the DS-lite CGN
node to be deployed in an IPv6-only network. More precisely, this
memo proposes to extend DS-lite CGN node with a new stateless
encapsulation/decapsulation capability that delivers the NAT-ed IPv4
datagram in an IPv4-inferred IPv6 datagram after the NAT44 function.
Boucadair, et al. Expires April 8, 2010 [Page 4]
Internet-Draft Extended DS-lite October 2009
Furthermore, this document proposes a new stateless IPv6-IPv4
Interconnection Function (IPv6-IPv4 ICXF) in the border element of
the IPv6 network that will translate IPv6 datagrams into IPv4
datagrams for the sake of IPv4 connectivity.
In this memo, the DS-lite CGN node is not directly connected to an
IPv4 network. After performing IPv4-in-IPv6 de-capsulation and NAT
operation, the DS-lite CGN node will encapsulate the NAT-ed IPv4
datagram in an IPv4-in-IPv6 datagram and forward the datagram in the
IPv6 network towards an ICXF-capable router located in the network
border.
The stateless IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF) is
introduced. This function may be hosted in an ASBR (Autonomous
System Border Router) 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
datagrams and de-encapsulating IPv4-in-IPv6 datagrams. An ICXF-
capable router refers to the border router implemented with IPv6-IPv4
ICXF. It resides in the border of an IPv6-only network but also
connects to one or more IPv4 networks. When the ICXF-capable router
receives the IPv4-inferred IPv6 datagram from a DS-lite CGN node, it
will de-capsulate the datagram and forward the IPv4 datagram based on
the IPv4 destination address in the header. For incoming IPv4
traffic, the ICXF router will encapsulate the IPv4 datagram into an
IPv6 datagram with the IPv4-inferred IPv6 address and forward it to
the appropriate DS-lite CGN node.
1.4. What's new compared to RFC5565
One of the two scenarios softwire mesh [RFC5565] covers is IPv4
tunneling through an IPv6-only backbone. Mesh defines an
interconnection function at the backbone's edge routers called AFBR.
All AFBRs exchange i-BGP routes. When an IPv4 datagram arrives at an
AFBR, it uses a BGP-distributed route to retrieve the IPv6
destination address of the distant softwire endpoint. The AFBRs will
form a mesh network tunneling the IPv4 datagrams over softwire. The
AFBRs must maintain a stateful mapping table for encapsulation and
de-capsulation purposes.
This document covers a slightly different IPv4 over IPv6 scenario.
This scenario is asymmetric. On one side of the IPv6 backbone, there
are CGNs, and on the other side of the IPv6 backbone there are IPv4
Internet access points. At each IPv4 Internet access point we define
an interconnection function called ICXF. All ICXFs exchange i-BGP
information. In some scenarios, CGNs do not participate in the i-BGP
exchanges (since IGP may be used, see Section 3.3.2 for more
details).
Boucadair, et al. Expires April 8, 2010 [Page 5]
Internet-Draft Extended DS-lite October 2009
Unlike [RFC5565], the encapsulation at both sides is stateless: the
IPv6 destination address of the distant softwire endpoint is
automatically generated, based on the IPv4 destination address of the
IPv4 datagram only, there is no need to refer to any route. The
forwarding of the encapsulated datagrams is ensured by the
installation of appropriate routes by i-BGP between ICXFs.
1.5. Changes since 01
The following changes have been made since the last version:
1. A new co-author has joined the draft's team;
2. Add a new section to position the proposed solution versus
RFC5565;
3. Add a new section to describe in detail the routing
considerations;
4. Add a new section on multicast considerations;
5. Various editorial changes.
2. Terminology
This memo defines the following terms:
o DS-lite CGN node: refers to the CGN node whose behavior is
specified in [I-D.ietf-softwire-dual-stack-lite]. This node
embeds a CGN function. In addition, this draft makes the
assumption that the DS-lite CGN node is only connected to an IPv6
network. Within this draft, the CGN design scheme assumes that
only IPv6 traffic will be forwarded in the backbone that embeds
DS-lite capabilities, including IPv6 traffic that conveys
encapsulated IPv4 datagrams and which is sent to ICXF-enabled
routers. This encapsulation is stateless.
o IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF): refers to the
function that de-capsulates (resp., encapsulates) the IPv6 (resp.,
IPv4) datagram from DS-lite CGN node(s) and forwards the IPv4
(resp., IPv6) datagrams to the IPv4 (resp., IPv6) networks.
o ICXF router: refers to the border router implemented with IPv6-
IPv4 ICXF.
o Access segment: This segment encompasses both the IP access and
backhaul network.
Boucadair, et al. Expires April 8, 2010 [Page 6]
Internet-Draft Extended DS-lite October 2009
o Interconnection segment: Includes all nodes and resources which
are deployed at the border of a given AS (Autonomous System) a la
BGP.
o Core segment: Denotes a set of IP networking capabilities and
resources which are located between the interconnection and the
access segments.
o Customer Attachment Device: A customer may use a terminal or a CPE
to access the he/she has subscribed to. This device is referred
to as Customer Attachment Device. This device is standard DS-lite
client device. This extension does not introduce any new
functionality to that device. In this memo, CPE refers to
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 extension of the DS-lite approach.
3.1. Global Architecture
Figure 1 provides an overview of the global architecture. 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 the end-user terminal devices. The service domain is IPv6
only and interconnection with adjacent IPv4 realms is implemented
using IPv6-IPv4 ICXF.
Boucadair, et al. Expires April 8, 2010 [Page 7]
Internet-Draft Extended DS-lite October 2009
+--------------------------------+
| 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: Global Architecture
The following sub-sections provide more details about the proposed
solution.
3.2. Customer Attachment Device
The Customer Attachment Device is (dynamically) assigned an IPv6
prefix and also acquires IPv6 reachability information to forward
IPv6 traffic outside of the customer premises. The Customer
Attachment Device also supports DS-lite-specific capabilities (namely
an encapsulation scheme to convey privately-addressed IPv4 traffic
into IPv6 datagrams that will be sent to one of the available CGN
devices located in the network). DS-lite CGN IPv6 reachability
information is also (dynamically) provisioned to the Customer
Attachment Device, e.g. by means of a specific DHCPv6
option[I-D.dhankins-softwire-tunnel-option]. To reach a CGN, a FQDN
may be provided to the Customer Attachment Device instead of an IPv6
address.
For outbound IPv6 datagrams, the Customer Attachment Device routes
them natively in the service domain. For outbound IPv4 datagrams,
the Customer Attachment Device encapsulates the private-addressed
IPv4 datagrams in IPv6 ones. These datagrams are forwarded (without
any NAT operation) towards a DS-lite CGN node.
Boucadair, et al. Expires April 8, 2010 [Page 8]
Internet-Draft Extended DS-lite October 2009
For inbound IPv6 datagram, the Customer Attachment device routes them
natively to the hosts connected to it. For inbound IPv4 datagrams,
the Customer Attachment Device proceeds to de-encapsulation
operation. De-encapsulated datagrams are routed locally and
forwarded to the hosts connected to the Customer Attachment Device.
This is standard DS-lite client behavior defined in
[I-D.ietf-softwire-dual-stack-lite]. This memo does not add new
requirement.
3.3. DS-lite CGN Node
3.3.1. Provisioning Information
DS-lite CGN nodes are provisioned with:
o Pref6: An IPv6 prefix which may be assigned by IANA or by LIR as
described in [I-D.ietf-behave-address-format]. This prefix is
used to construct an IPv4-inferred IPv6 address. More information
are provided in Section 3.3.3. The choice between IANA and LIR is
left to service provider's engineering policies.
o A set of IPv6 prefixes which are structured as Pref6+IPv4_Addr:
* Pref6 is the IPv6 prefix dedicated to the IPv4-IPv6
interconnection.
* IPv4_Addr is a public IPv4 address used by the DS-lite CGN to
enforce its NAT44 operations.
+ Several IPv4_Addrs may be configured on a DS-lite node.
These IPv4_Addrs SHOULD be aggregated, leading to aggregated
Pref6+IPv4_Addr prefixes.
+ Each IPv4_Addr represents multiple IPv4 customers served by
the DS-lite CGN node.
Figure 2 gives an example of address format. For more information
about mapping address format, refer to
[I-D.ietf-behave-address-format].
In this example, Pref6 is 2a01:c::/20 and the IPv4_Addr is
193.51.145.206. Then, the corresponding IPv6 prefix is: 2a01:cc13:
391c:e0::/56.
Boucadair, et al. Expires April 8, 2010 [Page 9]
Internet-Draft Extended DS-lite October 2009
2a01:c::11000001001100111001000111001110 = 2a01:cc13:391c:e0::/56
|Pref6 | <--------193.51.145.206-------->
Figure 2: Example for an IPv4-Inferred IPv6 Prefix
3.3.2. Routing Considerations
To enable stateless de-/encapsulation in the ICXF router, the DS-lite
CGN nodes MUST use the aforementioned Pref6 to construct the IPv4-
Inferred IPv6 address when forwarding datagrams received from a
customer device.
A DS-lite node (or the upstream router of the DS-lite node)
advertises the IPv6 prefix it manages (i.e., the set of Pref6+
IPv4_Addr prefix described above) by IGP (e.g. OSPFv3). Such
announcement is required so that all traffic sent to an IPv6 address
belonging to the IPv6 prefix managed by the DS-lite CGN node MUST be
forwarded to the appropriate DS-lite node. These prefixes MUST NOT
be advertised to external peers (e.g., e-BGP peers).
3.3.3. Processing Operations
Figure 3 shows the input and output of a DS-lite CGN node.
+-------------------+
----IPv6---\ | |----IPv6---\
----IPv4---\\| |----IPv4---\\
-----------//| |-----------//
-----------/ | |-----------/
Customer | DS-lite |
/----IPv6---| CGN | /----IPv6---
//---IPv4----| |//---IPv4----
\\-----------| |\\-----------
\-----------| | \-----------
+-------------------+
DS-lite Interface Core Node Interface
Figure 3: Modified DS-lite CGN
Two main interfaces may be distinguished in a DS-lite CGN node:
a. Interface with the customer device, i.e., DS-lite interface, per
[I-D.ietf-softwire-dual-stack-lite].
Boucadair, et al. Expires April 8, 2010 [Page 10]
Internet-Draft Extended DS-lite October 2009
b. Interface with core nodes. Note that the DS-lite CGN node does
not directly connect to an IPv4 domain.
The processing of the IPv4 traffic received from a customer device is
as follows.
IPv4-in-IPv6 datagrams (issued by the customer device) are de-
encapsulated and then NAT operation is applied. Once this operation
is performed, the DS-lite node encapsulates the NAT-ed IPv4 datagrams
in IPv6 using the following information:
o Source IPv6 address: One of the DS-lite node IPv6 addresses. This
source IPv6 address is a global IPv6 address configured on an
interface of the DS-lite CGN (e.g., loopback).
o Destination IPv6 address: Pref6+IPv4_Addr destination address
(i.e., the destination IPv4 address contained in the encapsulated
datagrams).
Encapsulated traffic is forwarded until it reaches another DS-lite
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., Figure 4), it
de-capsulates 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 5), it
proceeds to a de-capsulation operation and then the traffic is
forwarded to the next IPv4 destination according to the installed
IPv4 routes.
As illustrated in Figure 4, the communications between two CPEs
attached to a DS-lite domain are implemented using IPv6 transfer
capabilities only. IPv4 datagrams are encapsulated in IPv6 ones.
Boucadair, et al. Expires April 8, 2010 [Page 11]
Internet-Draft Extended DS-lite October 2009
+------+ +---------+ +---------+ +------+
| |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | |
| |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| |
| |---------//| |---------------//| |---------//| |
| |---------/ | |---------------/ | |---------/ | |
| CPE 1| | DS-lite | | DS-lite | | CPE2 |
| | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| |
| |//---IPv4--| |//----IPv4-------| |//--IPv4---| |
| |\\---------| |\\---------------| |\\---------| |
| | \---------| | \---------------| | \---------| |
+------+ +---------+ +---------+ +------+
Note that hosts connected to each CPE are not represented in the
figure.
Figure 4: Flow Example involving two devices attached to distinct
CGNs
The following figure illustrates an example of CPE connected to a DS-
lite CGN node, which establishes a communication with a remote host
(referred to as RH) which is IPv4-enabled.
+------+ +---------+ +---------+ +------+
| |--IPv6---\ | |------IPv6-----\ | | | |
| |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| |
| |---------//| |---------------//| |---------/| |
| |---------/ | |---------------/ | | | |
| CPE 1| | DS-lite | |IPv6-IPv4| | RH |
| | /---IPv6--| CGN A | /-----IPv6------| ICXF | | |
| |//---IPv4--| |//----IPv4-------| |/--IPv4---| |
| |\\---------| |\\---------------| |\---------| |
| | \---------| | \---------------| | | |
+------+ +---------+ +---------+ +------+
Note that host connected to CPE1 are not represented in the figure.
Figure 5: Flow Example involving only one device attached to a DS-
lite enabled domain
3.4. IPv6-IPv4 Interconnection Function
A dedicated node called IPv6-IPv4 Interconnection Function (IPv6-IPv4
ICXF) is required to interconnect an IPv6-only network (which hosts a
DS-lite CGN function) and an IPv4 network. This function is required
Boucadair, et al. Expires April 8, 2010 [Page 12]
Internet-Draft Extended DS-lite October 2009
to interconnect both realms to receive and forward IPv4 datagrams
from the DS-lite clients and IPv4 Internet.
The following sub-sections provide more information about the
behavior of this function.
3.4.1. Provisioning Information
An IPv6-IPv4 Interconnection node is provisioned with a Pref6. This
prefix is used to build IPv4-inferred IPv6 addresses (structured as
Pref6+IPv4_Addr). IPv4_Addr refers to an IPv4 address (or network)
that can be reached through the IPv6-IPv4 interconnection node. IPv4
addresses may be statically configured or dynamically learned (IPv4
peers).
3.4.2. Routing Considerations
Two modes may be considered:
o Static mode: IPv4-inferred IPv6 prefixes, structured as Pref6+
IPv4_Addr, are manually configured in the IPv6-IPv4 ICXF router.
o Dynamic mode: IPv6-IPv4 ICXF router is responsible to build IPv4-
inferred IPv6 prefixes which are structured as Pre6+IPv4_addr.
These addresses represent IPv4 reachable destinations in the IPv6-
only realm.
IPv4 traffic encapsulated in IPv6 datagrams will be forwarded to ICXF
routers. The selection of the appropriate ICXF router is based upon
the computation of the best (shortest) IPv4 route towards the IPv4
destination. There are several ways to proceed. As examples, we
describe two solutions: a one-step process and a two-step process.
The one-step process can be achieved using softwire mesh ([RFC5565]).
ICXF routers and CGNs exchange i-BGP information. Particularly, the
CGNs receive and process the i-BGP advertisements. From the i-BGP
information, CGNs build IPv4 routes where the next hop is the IPv6
address of the ICXF router which has the best route to the IPv4
destination. Whenever a CGN has to encapsulate an IPv4 datagram into
IPv6, it looks up the IPv6 destination in its BGP-distributed routes.
The IPv6 datagram is then directly routed from the CGN to the
relevant ICXF router, in a one-step process. In this scenario, CGNs
maintain a full BGP IPv4 routing table, and the IPv4-in-IPv6
encapsulation is stateful.
In the two-step process, ICXF routers exchange i-BGP information as
in the previous scenario, but, contrary to the previous scenario,
CGNs do not participate to the i-BGP mesh. Furthermore, each ICXF
Boucadair, et al. Expires April 8, 2010 [Page 13]
Internet-Draft Extended DS-lite October 2009
router advertises a route to Pref6 in IPv6 IGP. Whenever a CGN has
to encapsulate an IPv4 datagram into IPv6, it dynamically builds the
IPv6 destination address from the IPv4 destination address: Pref6+
IPv4_Addr. The IPv6 datagram is then routed to the nearest ICXF
router. This ICXF router then forwards, if necessary, the IPv6
datagram to the ICXF router which has the best route to the IPv4
destination. Thus, IPv6 datagram may be routed in a two-step
process. In this scenario, CGNs do not maintain any IPv4 BGP routing
table, and the IPv4-in-IPv6 encapsulation is stateless.
IPv4-inferred IPv6 reachability information (received from adjacent
domains) should be advertised using i-BGP between ICXF routers, to
avoid a full redistribution of BGP routes into IGP. Recursive
routing lookup will be then executed to select the appropriate IXCF
(exit point). The engineering of the relationship between IGP and
i-BGP would follow best practices as those documented in [RFC4277].
Note that the ICXF router does not assign Pref6 + IPv4_Addr IPv6
addresses to its interfaces.
3.4.3. BGP Behavior
This section provides a description of the BGP behavior when IPv4-
inferred IPv6 routes are to be injected in i-BGP.
The following steps are to be followed:
o e-BGP session is maintained between an ICXF router and its IPv4
peer. IPv4 routes are exchanged between these two peers.
Particularly, ICXF router advertises to its peers a set of
reachable IPv4 networks through its attached domain (e.g., AS).
These IPv4 networks include the IPv4 addresses used by CGN
devices.
o No new capability BGP attribute is required with the context of
stateless IPv4-IPv6 interconnection.
o Each ICXF router is configured with a dedicated IPv6 prefix
(Pref6) which is to be used to build IPv4-inferred IPv6 prefixes
(e.g., IPv4-inferred IPv6 prefix=Pref6+IPv4 net).
o For each route towards an IPv4 network, a corresponding IPv6
prefix is built as per the method described in Section 3.3.3.
These routes are then injected in i-BGP to all internal peers to
synchronise the overall BGP routing table and avoid loops.
Boucadair, et al. Expires April 8, 2010 [Page 14]
Internet-Draft Extended DS-lite October 2009
3.4.4. Processing Operations
Figure 6 shows the input and output of an IPv6-IPv4 ICXF.
+-------------------+
----IPv6---\ | |
----IPv4---\\| |----IPv4---\
-----------//| |-----------/
-----------/ | |
| IPv6-IPv4 |
/----IPv6---| ICXF |
//---IPv4----| |/---IPv4----
\\-----------| |\-----------
\-----------| |
+-------------------+
Figure 6: IPv6-IPv4 Interworking Function
When the interconnection node receives IPv4 traffic from an IPv4
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: Prefix6+IPv4 Destination address. The
IPv4 destination address is part of the DS-lite node address
space.
The traffic is 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 incoming IPv6 received traffic, an Interconnection node
proceeds to a de-capsulation operation and then the traffic is
forwarded to the next IPv4 destination according to installed IPv4
routes.
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 upstream and far from the customer premises
since this would create a concentrator and then may be considered as
Boucadair, et al. Expires April 8, 2010 [Page 15]
Internet-Draft Extended DS-lite October 2009
a single point of failure. Furthermore, the routing would not be
optimal, particularly for intra-domain traffic.
5. Multicast Considerations
To access IPv4 multicast-based content via the CGN, the following
behaviour MAY be implemented:
o IPv4-inferred IPv6 multicast addresses are built based on IPv4
multicast address. An IPv4 multicast address is embedded in an
IPv6 multicast one.
o The ICMP proxy function embedded in a DS-lite CPE forwards ICMP
Report messages towards a DS-lite CGN. These ICMP Report messages
are encapsulated in IPv6 by the CPE and forwarded to the DS-lite
CGN.
o The CGN is then able to connect that CPE to the corresponding IPv6
multicast tree using the IPv4-inferred IPv6 multicast address.
This document recommends the migration of IPv4 multicast-based
services to IPv6 and CGN device to be restricted to process unicast
IPv4 traffic.
6. Applicability in the context of A+P
The procedure defined in this memo may also apply in the context of
PRR (Port Range Router, [I-D.boucadair-port-range]) instead of DS-
lite CGN. In the last case the customer attachment device should do
the classification of outbound IPv4 packet between A+P and DS-lite
mode and the IPv6-IPv4 interconnection function should do the
classification of inbound IPv4 datagrams. In this case a specific
prefix (Prefix6) may be allocated for each mode.
7. Conclusions
This memo describes the mechanism to extend DS-lite to operate 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.
Boucadair, et al. Expires April 8, 2010 [Page 16]
Internet-Draft Extended DS-lite October 2009
o A remote IPv4 host would reach a host connected to the DS-lite
enabled domain using IPv4-in-IPv6.
8. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
Security considerations defined in
[I-D.ietf-softwire-dual-stack-lite] should be taken into account. In
addition, current interconnection practices for ingress traffic
filtering should be enforced in the interconnection points (ICXF).
10. Acknowledgements
The authors would like to thank Eric Burgey for his support and
suggestions.
11. References
11.1. Normative References
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-stack lite broadband deployments
post IPv4 exhaustion",
draft-ietf-softwire-dual-stack-lite-01 (work in progress),
July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
11.2. Informative References
[I-D.boucadair-port-range]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Boucadair, et al. Expires April 8, 2010 [Page 17]
Internet-Draft Extended DS-lite October 2009
Exhaustion: Port Range based IP Architecture",
draft-boucadair-port-range-02 (work in progress),
July 2009.
[I-D.dhankins-softwire-tunnel-option]
Hankins, D., "Dynamic Host Configuration Protocol Option
for Dual-Stack Lite",
draft-dhankins-softwire-tunnel-option-03 (work in
progress), March 2009.
[I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-00 (work in progress),
August 2009.
[RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4
Protocol", RFC 4277, January 2006.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 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
France
Email: jeanluc.grimault@orange-ftgroup.com
Boucadair, et al. Expires April 8, 2010 [Page 18]
Internet-Draft Extended DS-lite October 2009
Mohammed Kassi-Lahlou
France Telecom
Email: mohamed.kassilahlou@orange-ftgroup.com
Pierre Levis
France Telecom
Email: pierre.levis@orange-ftgroup.com
Dean Cheng
Huawei Technologies Co., Ltd.
Email: Chengd@huawei.com
URI: http://www.huawei.com
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Boucadair, et al. Expires April 8, 2010 [Page 19]