Internet Engineering Task Force R. Despres, Ed.
Internet-Draft RD-IPtech
Intended status: Standards Track S. Matsushima
Expires: September 15, 2011 SoftBank
T. Murakami
IP Infusion
O. Troan
Cisco
March 14, 2011
IPv4 Residual Deployment across IPv6-Service networks (4rd)
ISP-NAT's made optional
draft-despres-intarea-4rd-01
Abstract
This document specifies an automatic tunneling mechanism for
providing IPv4 connectivity service to end users over a service
provider's IPv6 network. During the long transition period from IPv4
to IPv6-only, a service provider's network will have to support IPv6,
but will also have to maintain some IPv4 connectivity for a number of
customers, for both outgoing and incoming connections, and for both
exclusive and shared IPv4 addresses. The 4rd solution (IPv4 Residual
Deployment) is designed as a lightweight solution for this.
In some scenarios, 4rd can dispense ISPs from supporting any NAT in
their networks. In some others it can be used in parallel with NAT-
based solutions such as DS-lite and/or NAT64/DNS4.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Despres, et al. Expires September 15, 2011 [Page 1]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5
4.1. General Principles . . . . . . . . . . . . . . . . . . . . 5
4.2. Mapping-Rule Parameters . . . . . . . . . . . . . . . . . 5
4.3. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. From a CE IPv6 Prefix to a CE 4rd Prefix . . . . . . . 6
4.3.2. From a CE 4rd Prefix to a Port-set ID . . . . . . . . 7
4.3.3. From a Port-Set ID to a Port Set . . . . . . . . . . . 7
4.3.4. From an IPv4 Address or IPv4 address + Port to a
CE IPv6 address . . . . . . . . . . . . . . . . . . . 9
4.4. Encapsulation and Fragmentation Considerations . . . . . . 10
4.5. BR and CE behaviors . . . . . . . . . . . . . . . . . . . 11
4.5.1. Domains having only One Mapping rule . . . . . . . . . 11
4.5.2. Domains having Multiple Mapping Rules . . . . . . . . 12
5. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 14
6. Security considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Despres, et al. Expires September 15, 2011 [Page 2]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
1. Introduction
During the transition period from IPv4 to IPv6 Internet Service
Providers (ISP's), will deploy networks that are IPv6 only. Some of
them will do so while they still have to offer IPv4 connectivity.
The IPv4 service can be one or multiple IPv4 addresses per end-user,
or it can be an IPv4 address shared among multiple end-users.
In this document, Internet Service Provider is used as a generic
term. It includes DSL or Broadband service providers, mobile
operators, and private operators of networks of any sizes.
4rd (IPv4 Residual Deployment) is a generic lightweight solution for
providing IPv4 connectivity across an IPv6 only infrastructure. As
such, it is the reverse of 6rd (IPv6 Rapid Deployment) whose purpose
is to rapidly introduce native IPv6 connectivity across an IPv4
network. It applies the same principles of automatic tunneling, an
stateless address mappings between IPv4 and IPv6.
On the tradeoff scale between efficiency of address sharing ratios
and simplicity, 4rd is on the side of design and operational
simplicity.
The 4rd mechanism tunnels IPv4 over IPv6 using an algorithmic mapping
from IPv4 addresses or IPv4 addresses and ports to the IPv6 addresses
used as tunnel endpoints. Depending on ISP constraints and policies,
4rd can be used either standalone, with NAT44's in CE's but no NAT in
ISP networks, or can co-exist with other mechanisms in the network on
NAT's like DS-lite [I-D.ietf-softwire-dual-stack-lite] or NAT64/DNS64
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-dns64].
2. 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 [RFC2119].
Despres, et al. Expires September 15, 2011 [Page 3]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
3. Terminology
4rd domain (Domain): an IPv6 routing network operated by an ISP and
comprising one or several 4rd BR's having the
same set of parameters. It offers to its 4rd-
capable CE's global IPv4 connectivity, both
outgoing and incoming, and with exclusive or
shared IPv4 addresses.
4rd Border Relay (BR): A 4rd-capable router managed by the service
provider at the edge of a 4rd domain. A BR has
an IPv6-enabled interface connected to the ISP
network, and an IPv4 virtual interface acting
as an endpoint for the automatic 4rd tunnel.
This tunnel (IPv4 in IPv6) is between the BR
and all CE's of the Domain.
4rd Customer Edge (CE): A node at the border between a customer
network and the 4rd domain. This node has an
IPv6 interface connected to the ISP network,
and a virtual IPv4 interface acting as the end-
point of the automatic 4rd tunnel. This tunnel
(IPv4 in IPv6) is between the CE and all other
CE's and all BR's of the Domain. It may be a
host, a router, or both.
CE IPv6 prefix: The IPv6 prefix assigned to a CE by other means
than 4rd itself, and used by 4rd to derive a CE
4rd prefix.
CE IPv6 address: In the context of 4rd, the IPv6 address used to
reach a CE from other CE's and from BR's. A CE
typically has another IPv6 address, assigned to
it at its IPv6 interface without relationship
with 6rd.
CE 4rd prefix: The 4rd prefix of the CE. It is derived from
the CE IPv6 prefix by a mapping rule according
to Section 4.3. Depending on its length, it is
an IPv4 prefix, an IPv4 address, or a shared
IPv4 address followed by a Port-set ID
(Section 4.3.2).
Port-set ID: In a CE 4rd prefix longer than 32 bits, bits
that follow the first 32. It algorithmically
identifies a set of ports exclusively assigned
to the CE. As specified in Section 4.3.3, the
set can comprise up to 4 disjoint port ranges.
Despres, et al. Expires September 15, 2011 [Page 4]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Domain IPv6 prefix: An IPv6 prefix assigned by an ISP to a 4rd
domain.
Domain 4rd prefix: A 4rd prefix assigned by an ISP to the 4rd
domain. In typical operator applications, it
is an IPv4 prefix. In a residential site in
which an already shared IPv4 address has to be
shared even more among several hosts, it may
have more than 32 bits.
CE index: For a CE, the field that is common to its CE
IPv6 prefix and its CE 4rd prefix. In the
former, it follows the Domain IPv6 prefix. In
the latter, it follows the Domain 4rd prefix.
4. Protocol Specification
4.1. General Principles
The principle of the 4rd protocol is that IPv4 packets, or in case of
shared IPv4 addresses IPv4 datagrams, traverse a 4rd domain by means
of automatic IPv4 in IPv6 tunnels. IPv6 addresses of destination
tunnel endpoints are statelessly derived from IPv4 destinations,
based on some mapping rule parameters, in such a way that tunnels
between CE's follow direct IPv6 paths (i.e. without having to go via
BR's). IPv4 destinations used for these mappings are either IPv4
addresses alone or IPv4 addresses + ports depending on whether global
addresses assigned to CE's are exclusive or shared.
BR's and CE's MAY have the detailed behaviors specified in the
following sections. Different behaviors are however permitted, but
they MUST be equivalent as far as exchanged packets are concerned.
4.2. Mapping-Rule Parameters
Both CE's and BR's have to know the BR IPv6 address of their domain
as well as, for each mapping rule, the following parameters:
o Domain IPv6 prefix
o Domain 4rd prefix
o IPv6-prefix length
o Domain IPv6 suffix (optional - default ::/0)
Despres, et al. Expires September 15, 2011 [Page 5]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
4.3. Mapping Rules
4.3.1. From a CE IPv6 Prefix to a CE 4rd Prefix
A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes
and CE 4rd prefixes.
<---------------- CE IPv6 prefix (max 64) -------------->
+-------------------------------+------------------------+
| Domain IPv6 prefix | CE index |
+-------------------------------+------------------------+
<-- Domain IPv6 Prefix length -><--- CE index length --->:
: :
: || :
: \/ :
: :
<--- CE index length --->:
+-------------------+------------------------+
| Domain 4rd prefix | CE index |
+-------------------+------------------------+
<----------- CE 4rd prefix (max 47) -------->
Figure 1: From a CE IPv6 Prefix to a CE 4rd Prefix
A CE derives its CE 4rd prefix from the IPv6 prefix it has been
delegated on the IPv6 network, using for this parameters of the
applicable mapping rule. If the domain has several mapping rules,
that which applies is that whose Domain IPv6 prefix is at the
beginning of the CE IPv6 prefix. As shown in Figure 1, the CE 4rd
prefix is made of the Domain 4rd prefix followed by the CE index,
where the CE index is the remainder of the CE IPv6 prefix after the
Domain IPv6 prefix (the length of the Domain IPv6 prefix is defined
by the mapping rule).
Despres, et al. Expires September 15, 2011 [Page 6]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
4.3.2. From a CE 4rd Prefix to a Port-set ID
Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a
full IPv4 address, or a shared IPv4 address followed by a Port-set ID
(Figure 2). If it includes a port set ID, this ID specifies which
ports are assigned to the the CE for its exclusive use
(Section 4.3.3).
<-- CE 4rd prefix length -->
+--------------------------+- - -+
Shorter than 32 bits | IPv4 prefix | ... |
+ -------------------------+- - -+
<--------------- 32 ------------->
<----- CE 4rd prefix length ----->
+--------------------------------+
32 bits | IPv4 address |
+--------------------------------+
<--------------- 32 ------------->
<----------- CE 4rd prefix length ---------->
+-------------------------------+-----------+
33 to 47 bits | IPv4 shared address |Port-set ID|
+-------------------------------+-----------+
<--------------- 32 -----------><- max 15 -->
Figure 2: Variants of CE 4rd prefixes
4.3.3. From a Port-Set ID to a Port Set
Each value of a Port-set ID specifies which ports can be used by any
protocol whose header format starts with source and destination ports
(UDP, TCP, SCTP, etc.). Design constraint of the algorithm are the
following:
"Fairness with respect to special-value ports"
No port-set must contain any port from 0 to 4095. (These ports,
which have more value than others in OS's, are normally not used
in dynamic port assignments to applications).
"Fairness with respect to the number of ports"
For a Port-set-ID's having the same length, all sets must have
the same number of ports.
Despres, et al. Expires September 15, 2011 [Page 7]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
"Exhaustiveness"
For a any Port-set-ID length, the aggregate of port sets
assigned for all values must include all ordinary-value ports
(from 4,096 to 16,384).
If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges.
As shown in Figure 3, each port range is defined by its port prefix,
made of a range-specific "head" followed by the Port-set ID. Head
values are in binary 1, 01, 001, and 0001. They are chosen to
exclude ports 0-4095 and only them.
<------- Port (16 bits) -------->
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range a |1|x x x x x x x x| | 0xF780 - 0xF7FF
(head = 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range b |0 1|x x x x x x x x| | 0x7BC0 - 0x7BFF
(head = 01) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range c |0 0 1|x x x x x x x x| | 0x3DE0 - 0x3DFF
(head = 001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range d |0 0 0 1|x x x x x x x x| | 0x1EF0 - 0x1EFF
(head = 0001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<- head-><--Port-set ID-> /\
<-- Port-range prefix --><-tail-> ||
||
Example of Port-ranges
if the Port-set ID is 0xEF
Figure 3: From Port-set ID to Port ranges
In the Port-set ID has 13 bits, only the 3 port ranges are assigned,
having heads 1, 01, and 001. If it has 14 bits, only the 2 port
ranges having heads 1 and 01 are assigned. If it has 15 bits, only
the port range having head 1 is assigned. (In these three cases, the
smallest port range has only one element).
NOTE: The port set assigned to a CE may be further subdivided by the
CE among several functions such as the following: (1) an IPv4 NAPT
(possibly configurable to do port forwarding, and possibly doing
dynamic port assignments to hosts with UPnP and/or NAT-PMP); (2) an
API for applications in the CE that need dynamic port assignments;
(3) a new 4rd BR which assigns to its CE's subsets of its own port
Despres, et al. Expires September 15, 2011 [Page 8]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
set. How to chose among these functions and/or combine them is
beyond the scope of this specification. Readers are referred to
documents dealing with operational applicability in diverse
environments, e.g. [draft-sun-intarea-4rd-applicability] prepared in
parallel of this one.
4.3.4. From an IPv4 Address or IPv4 address + Port to a CE IPv6 address
Port-set ID
|
<--- CE 4rd prefix ---|->
+---------------+---+-|--+
|IPv4 shared address| ' |
+---------------+---+----+
<-------->
CE-index length
: :
: || :
: || :
: \/ : Domain IPv6 suffix
: : |
+------------------+--------+--|-+----------------------------------+
|Domain IPv6 prefix|CE index| ' | 0 |
+------------------+--------+----+----------------------------------+
<------------ max 64 ------------>
<---------------------- CE IPv6 address (128) --------------------->
Figure 4: From 4rd Prefix to IPv6 address (shared IPv4 address case)
In order to find whether a CE IPv6 address can be derived from an
IPv4 address, or an IPv6 address + a port, a mapping rule has to be
found that matches the IPv4 information:
o If a mapping rule has a length L of CE IPv4 prefixes which does
not exceed 32 bits, there is a match if the IPv4 address starts
with the Domain 4rd prefix. The CE 4rd prefix is then the first L
bits of the IPv4 address.
o If a mapping rule has a length L of CE IPv4 prefixes which exceeds
32 bits, the match can only be found with the IPv4 address and the
port. For this, the port is examined to determine which port-
range head it starts with: 1, 01,001, or 0001. The N bits that
follow this head are taken as Port-set ID, where N is the length
of Port set ID of the mapping rule. The CE 4rd prefix is then
made of the IPv4 address followed by the Port-set ID.
If a match has been found, the CE IPv6 prefix is then made of the
Despres, et al. Expires September 15, 2011 [Page 9]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Domain IPv6 prefix followed by bits of the CE 4rd prefix that
follow the Domain 4rd prefix, followed by the Domain IPv6 prefix
of the mapping rule if there is one, and followed by 0's up to 128
bits to make a complete IPv6 address [RFC4291]. Figure 4
illustrates this process in the case of a shared IPv4 address.
4.4. Encapsulation and Fragmentation Considerations
For 4rd domain traversal, IPv4 packets are encapsulated in IPv6
packets whose Next header is set to 4 (i.e. IPv4). If fragmentation
of IPv6 packets is needed, it is performed according to [RFC2460],
and as illustrated in Figure 5. Absent more specific information,
the path MTU of a 4rd Domain has to be set to 1280 [RFC2460].
+--------------------//---------------+
| IPv4 packet |
+--------------------//---------------+
: :
: :
+-----//----+-----//----+--//--+--//--+
| frag 1 | frag 2 | |frag n|
IPv6 +-----//----+----//-----+--//--+------+
fragmentation extension : : : : :
\ : : : : :
|0 \|48 : : : :
+----------++-----//----+ : : :
| IPv6 || frag 1 | : : :
+----------++-----//----+ : : :
<---- IPv6 path MTU --->: : : :
: : : :
+----------++-----//----+ : :
| IPv6 || frag 1 | : :
+----------++-----//----+ : :
<---- IPv6 path MTU ---> : :
... : :
: :
+----------++--//--+
| IPv6 ||frag n|
+----------++------+
Figure 5: Fragmentation of long IPv4 packets for Domain Traversal
Despres, et al. Expires September 15, 2011 [Page 10]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
In domains where IPv4 addresses are not shared, IPv6 destinations are
derived from IPv4 addresses alone. Thus, each IPv4 packet can be
encapsulated and decapsulated independently of each other. 4rd
processing is completely stateless.
On the other hand, in domains where IPv4 addresses are shared, BR's
and CE's can have to encapsulate IPv4 packets whose IPv6 destinations
depend on destination ports. Precautions are needed, due to the fact
that the destination port of a fragmented datagram is available only
in its first fragment. A sufficient precaution consists in
reassembling each datagram received in multiple packets, and to treat
it as though it would have been received in single packet. This
function is such that 4rd is in this case stateful at the IP layer.
(This is common with DS-lite and NAT64/DNS64 which, in addition, are
stateful at the transport layer.) At Domain entrance, this ensures
that all pieces of all received IPv4 datagrams go to the right IPv6
destinations.
Another peculiarity of shared IPv4 addresses is that, without
precaution, a destination could simultaneously receive from different
sources fragmented datagrams that have the same Datagram ID (the
Identification field of [RFC0791]). This would disturb the
reassembly process. To eliminate this risk, BR's and CE's SHOULD, in
datagrams they receive from shared-IPv4-address CE's, replace
received Datagram ID's by new ones. New values SHOULD be generated
as though these datagrams would have been created locally (and with
due respect of [RFC0791]). Note that replacing a Datagram ID in an
IPv4 header implies an update of its Header-checksum field, by adding
to it the one's complement difference between the old and the new
values.
4.5. BR and CE behaviors
4.5.1. Domains having only One Mapping rule
(a) BR reception of an IPv4 packet
Step 1 If the length of CE 4rd prefixes does not exceed 32 bits,
the BR proceeds to step 2. Otherwise, and unless the
packet contains a complete IPv4 datagram, IPv4 datagram
reassembly is performed. If a complete datagram is
available, the BR proceeds to step 2 as though the
datagram had been received in a single packet.
Despres, et al. Expires September 15, 2011 [Page 11]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Step 2 The BR checks that the IPv4 source doesn't start with the
Domain 4rd prefix, and that a CE IPv6 address is
successfully derived from the IPv4 destination. In case
of success, the packet is encapsulated and forwarded to
this CE IPv6 address via the IPv6 interface.
(b) BR reception of an IPv6 packet
The BR checks that a CE IPv6 address is successfully
derived from the source of the IPv4 encapsulated packet,
and that the source address of the encapsulating packet is
equal to it. In case of success: (1) if the length of CE
4rd prefixes exceeds 32 bits, the Datagram ID of the
packet is replaced by a locally generated one; (2) the
IPv4 packet is forwarded via the IPv4 interface.
(c) CE reception of an IPv4 packet
Step 1 If the CE 4rd prefix of the CE does not exceed 32 bits and
the IPv4 destination address starts with the Domain 4rd
prefix, the CE proceeds to step 2. Otherwise, and unless
the packet contains a complete IPv4 datagram, IPv4
datagram reassembly is performed. If a complete datagram
is available, the BR proceeds to step 2 as though the
datagram had been received in a single packet.
Step 2 The CE tries tries to derive a CE IPv6 address from the
IPv4 destination. It then encapsulates the IPv4 packet
into an IPv6 packet whose destination is this CE IPv6
address, if one is obtained, or the BR IPv6 address
otherwise.
(d) CE reception of an IPv6 packet (reassembled if applicable)
The CE checks that a CE IPv6 address is successfully
derived from the source of the IPv4 encapsulated packet,
AND that it is equal to the source address of the
encapsulating packet. In case of success: (1) if the
length of CE 4rd prefixes exceeds 32 bits, the Datagram ID
of the packet is replaced by a locally generated one; (2)
the IPv4 packet is forwarded via the IPv4 interface.
4.5.2. Domains having Multiple Mapping Rules
Some ISP will want to use 4rd in networks having several Domain 4rd
prefixes, an/or several Domain IPv6 prefixes, and/or assigning CE 4rd
prefixes of different lengths. For this several mapping rules are
needed.
Despres, et al. Expires September 15, 2011 [Page 12]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
A first possibility consists in establishing several 4rd domains,
each on having a single mapping rule. In this case, paths between
CE's belonging to different 4rd domains go from one domain to the
other in IPv4, and cross two BR's.
A second possibility permits direct IPv6 paths between CE's by
supporting several mapping rules in a single domain, as described in
this section. At time of writing, whether this will be in the 4rd
specification a MAY, a SHOULD, or a MUST, remains an open question.
(a) BR reception of an IPv4 packet
Step 1 If a mapping rule whose length of CE 4rd prefixes does not
exceed 32 bits applies to the IPv4 destination, the BR
proceeds to step 2. Otherwise, and unless the packet
contains a complete IPv4 datagram, IPv4 datagram
reassembly is performed. If a complete datagram is
available, the BR then proceeds to step 2 as though the
datagram had been received in a single packet.
Step 2 The BR checks that the IPv4 source doesn't start with the
Domain 4rd prefix of any rule. In case of success, the
packet is encapsulated and forwarded to this CE IPv6
address via the IPv6 interface.
(b) BR reception of an IPv6 packet (reassembled if applicable)
The BR checks that a CE IPv6 address is successfully
derived from the source of the IPv4 encapsulated packet,
and that the source address of the encapsulating packet is
equal to it. In case of success, the BR tries to derive a
CE IPv6 address from the destination of the encapsulated
packet. In case of success: (1) if the source CE 4rd
prefix exceeds 32 bits, the Datagram ID of the packet is
replaced by a locally generated one; (2) the encapsulating
packet is retransmitted via the IPv6 interface with this
CE IPv6 address as destination (and the BR IPv6 address as
source address); in case of failure, the IPv4 packet is
decapsulated and forwarded via the IPv4 interface.
(c) CE reception of an IPv4 packet
Step 1 If the CE 4rd prefix of the CE does not exceed 32 bits,
and a mapping rule whose length of CE 4rd prefixes does
not exceed 32 bits applies to the IPv4 destination, the CE
proceeds to step 2. Otherwise, and unless the packet
contains a complete IPv4 datagram, IPv4 datagram
reassembly is performed. If a complete datagram is
Despres, et al. Expires September 15, 2011 [Page 13]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
available, the BR then proceeds to step 2 as though the
datagram had been received in a single packet.
Step 2 The CE tries to derive a CE IPv6 address from the IPv4
destination. It then encapsulates the IPv4 packet into an
IPv6 packet whose destination is this CE IPv6 address, if
one is obtained, or the BR IPv6 address otherwise.
(d) CE reception of an IPv6 packet (reassembled if applicable)
The CE checks that a CE IPv6 address is successfully
derived from the source of the IPv4 encapsulated packet,
and that it is equal to the source address of the
encapsulating packet. In case of success: (1) if the
source CE 4rd prefix exceeds 32 bits, the Datagram ID of
the packet is replaced by a locally generated one; (2) the
IPv4 packet is decapsulated and forwarded via the IPv4
interface.
NOTE: With consistency check made between encapsulated and
encapsulating sources in BR's and CE's when they received tunneled
packets, no CE can forward an invalid IPv4 source address, or address
plus port, and have it forwarded at by the egress BR or CE. Yet, if
before tunneling a packet, a CE makes an additional check that the
IPv4 source is consistent with the CE IPv6 address, it can discard
invalid packets earlier than by leaving it to the egress BR or CE.
At time of writing, whether this test can remain a MAY, or might
require a SHOULD or a MUST remains an open question.
5. 4rd Configuration
A CE can acquire 4rd parameters of its 4rd domain in various ways:
manual configuration by an administrator, software download by the
ISP, a new DHCPv6 option, etc. This document describes how to
configure the necessary parameters via a single DHCPv6 option. A CE
that allows IPv6 configuration by DHCPv6 SHOULD implement this
option. Other configuration and management methods, MAY use the
format described by this option for consistency and convenience of
implementation on CEs that support multiple configuration methods.
The format of Figure 6 is proposed for the DCHPv6 option. It is
chosen to permit multiple mapping rules:
Despres, et al. Expires September 15, 2011 [Page 14]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
<-2-><-2-><------------------- n octets ----------------->
+----+----+-----...-----+-- ... --+-----...-----+-- ... --+
| . | n | parameter 1 | | Parameter j | |
+--|-+----+-----...-----+-- ... --+-----...-----+-- ... --+
| _____/ \_____
option code / \
(TBD) +----+----+----+--...--+----+
| . | k | parameter value |
+--|-+----+----+--...--+----+
parameter code <--- k octets -->
PARAMETER-CODES (in Hexadecimal)
0x10 : BR IPv6 address
0x11 : Length of CE-IPv6-prefixes
0x2m : Domain IPv6 prefix, with m useful bits in last octet
0x3m : Domain 4rd prefix, with m useful bits in last octet
0x4m : Domain IPv6 suffix, with m useful bits in last octet
Figure 6: 4rd DHCPv6 option
In the parameter list the BR IPv6 address is first, followed by
parameters of each rule. For each rule, the order is <Domain IPv6
prefix, Domain IPv4 prefix, Length of CE IPv6 prefixes, Domain IPv6
suffix (optional)>.
6. Security considerations
Spoofing attacks
With consistency checks between IPv4 and IPv6 sources that are
performed on IPv4/IPv6 packets received by BR's and CE's
(Section 4.5), 4rd does not introduce any opportunity for spoofing
attack that would not pre-exist in IPv6.
Denial-of-service attacks
In 4rd domains where IPv4 addresses are shared, the fact that IPv4
datagram reassembly may be necessary introduces an opportunity for
DOS attacks (Section 4.4). This is inherent to address sharing,
and is common with other address sharing approaches such as DS-
lite and NAT64/DNS64.
The best protection against such attacks is to accelerate IPv6
enablement in both clients and servers so that, where 4rd is
supported, it is less and less used.
Despres, et al. Expires September 15, 2011 [Page 15]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Routing-loop attacks
Routing-loop attacks that may exist in some automatic-tunneling
scenarios are documented in [I-D.ietf-v6ops-tunnel-loops]. They
cannot exist with 4rd because each BRs checks that the IPv6 source
address of a received IPv6 packet is a CE address (Section 4.5.1
(b) and Section 4.5.2 (b) />).
Attacks facilitated by restricted port sets
From hosts that are not subject to ingress filtering of [RFC2827],
some attacks are possible by intervening with faked packets during
ongoing transport connections ([RFC4953], [RFC5961], [RFC6056].
These attacks, that have mitigations of their own are easier with
hosts that only use restricted port sets (they depend on guessing
which ports are currently used by target hosts). To avoid using
restricted port sets, the easiest approach consists in increasing
the proportion of connections that are IPv6, i.e. using
unrestricted port sets.
7. IANA Considerations
IANA is requested to assign a DHCPv6 option number for 4rd
(Section 5).
8. Acknowledgments
The authors wish to thank Mark Townsley for his active encouragements
to pursue the 4rd approach since it was first introduced in
[I-D.despres-softwire-sam]. Questions raised by Wojciech Dec have
been useful to clarify explanations. Olivier Vautrin, who
independently proposed a similar approach with the same acronym
deserves special recognition. Particular gratitude is due to
decision makers of the Japan ISP's that have announced actual 4rd
deployment projects (www.ietf.org/mail-archive/web/v6ops/current/
msg05247).
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Despres, et al. Expires September 15, 2011 [Page 16]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
9.2. Informative References
[I-D.despres-softwire-sam]
Despres, R., "Stateless Address Mapping (SAM) - a
Simplified Mesh-Softwire Model",
draft-despres-softwire-sam-01 (work in progress),
July 2010.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-11 (work in progress),
October 2010.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work
in progress), March 2011.
[I-D.ietf-v6ops-tunnel-loops]
Nakibly, G. and F. Templin, "Routing Loop Attack using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", draft-ietf-v6ops-tunnel-loops-03 (work in
progress), February 2011.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Despres, et al. Expires September 15, 2011 [Page 17]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.
Authors' Addresses
Remi Despres (editor)
RD-IPtech
3 rue du President Wilson
Levallois,
France
Email: remi.despres@free.fr
Satoru Matsushima
SoftBank
1-9-1 Higashi-Shinbashi, Munato-ku
Tokyo
Japan
Email: satoru.matsushima@tm.softbank.co.jp
Despres, et al. Expires September 15, 2011 [Page 18]
Internet-Draft IPv4 Residual Deployment(4rd) March 2011
Tetsuya Murakami
IP Infusion
1188 East Arques Avenue
Sunnyvale
USA
Email: tetsuya@ipinfusion.com
Ole Troan
Cisco
Bergen, Norway
France
Email: ot@cisco.com
Despres, et al. Expires September 15, 2011 [Page 19]