Internet Engineering Task Force R. Despres, Ed.
Internet-Draft RD-IPtech
Intended status: Standards Track J. Qin
Expires: March 25, 2012 ZTE
S. Perreault
Viagenie
X. Deng
France Telecom
September 22, 2011
Stateless Address Mapping for IPv4 Residual Deployment (4rd)
draft-despres-softwire-4rd-addmapping-01
Abstract
This document specifies a mechanism, the 4rd address mapping, for
service providers to offer residual deployment of the IPv4 service
across IPv6-only domains. Ease of operation and scalability are due
to this address mapping being stateless (no per customer states).
IPv4 address sharing is based on exclusive port sets assigned to
customers, these sets being algorithmically derived from bits used as
port-set identifiers. Features include support of shared IPv4
addresses, same routes for IPv4 as for IPv6, and compatibility with
both provider aggregatable and provider-independent IPv4 prefixes.
The whole 4rd address mapping or part of it can be used combined with
various tunneling and double-translation methods. It can also be
used either alone or in parallel with stateful mechanisms used for
their flexibility where necessary.
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 March 25, 2012.
Copyright Notice
Despres, et al. Expires March 25, 2012 [Page 1]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 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. Architectural model and design objectives . . . . . . . . . . 5
5. 4rd Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 9
6. Mapping steps from CE IPv6 prefix to CE IPv4 address space . . 10
6.1. From CE IPv6 prefix to Generalized IPv4 prefix . . . . . . 11
6.2. From Generalized IPv4 prefix to IPv4 prefix or IPv4
address or IPv4 Address + Port-set ID . . . . . . . . . . 12
6.3. From Port-set ID to Port set . . . . . . . . . . . . . . . 13
7. Mapping from IPv4 address or address plus port to CE IPv6
Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. From IPv4 Address or Address + Port to Rule IPv4
prefix + Max CE index . . . . . . . . . . . . . . . . . . 15
7.2. From Rule IPv4 prefix + Max CE index to CE IPv6 address . 16
8. Mapping from IPv4 source address to BR IPv6 Address . . . . . 17
9. Example of 4rd Domain with two Rule BR addresses and three
Rule IPv4 prefixes . . . . . . . . . . . . . . . . . . . . . . 18
10. Security considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Despres, et al. Expires March 25, 2012 [Page 2]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
1. Introduction
During the long transition period from IPv4-only to IPv6-only, some
Internet Service Providers (ISPs) will prefer to operate their
networks with IPv6-only routing. They will however have to maintain
residual IPv4 connectivities across these networks. Some customers
will still need exclusive IPv4 addresses, and others will accept
shared IPv4 addresses. This document specifies a mechanism, the 4rd
address mapping, whereby ISPs can statelessly derive IPv4 address
spaces they assign to customers from their IPv6 delegated prefixes
These IPv4 address spaces may consist of exclusive addresses or
exclusive port sets of shared addresses.
This specification can be used in association with a variety of
tunneling or double-translation methods specified in other documents.
As the chosen acronym suggest, 4rd can be viewed as the reverse of
6rd [RFC5969]: while 6rd statelessly derives IPv6 prefixes from
preassigned IPv4 addresses, 4rd derives IPv4 prefixes from
preassigned IPv6 prefixes. In addition, 4rd deals with public-IPv4
address sharing among customers.
Motivation for stateful solutions, which include simplicity and ease
of operation where more optimized address sharing ratios are not
necessary, are documented in
[I-D.ietf-softwire-stateless-4v6-motivation] (sharing ratio = number
of CEs supported per public IPv4 address). Precautions are taken so
that 4rd can coexist with stateful solutions where needed for more
sharing-ratio optimization.
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 March 25, 2012 [Page 3]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
3. Terminology
ISP: Internet-Service Provider. In this document, the
offered service can be DSL, fiber-optics, cable, or
wireless. The ISP can also be a private-network
operator.
4rd domain (Domain if context permits): An ISP IPv6 network across
which a residual IPv4 service is offered using the 4rd
address mapping, based on a common set of statelessly
advertizable mapping rules.
4rd CE (CE if context permits): 4rd-capable "customer-edge" node.
It can be a home gateway, a provider-edge router, a
host including a NAT44 or, more generally, any 4rd
capable node on the customer side of a 4rd Domain.
4rd BR (BR if context permits): A 4rd capable "border router". At
the border between a 4rd Domain and the IPv4 Internet.
Stateless: In this document, stateless means with neither per
transport-connection state nor per per-CE state (no
on-demand assignments of IPv4 address space). BRs
don't need per-CE states to forward packets that exit
or enter the Domain. CEs don't need states about
other CEs for direct CE-CE traffic.
An IPv4 address space: A set of one or several exclusive IPv4
addresses, or, in case of address sharing, an IPv4
address with an exclusive port set to be used with it.
CE IPv6 prefix: An IPv6 prefix delegated to a CE for normal IPv6
operation, e.g. according to [RFC3769]. With the 4rd
address mapping, this prefix is the only CE-specific
parameter needed for CEs to know which IPv4 addresses,
exclusive or shared, are assigned to them. CEs that
have larger IPv6 address spaces than others, i.e. have
shorter IPv6 prefixes, also have larger IPv4 address
spaces, i.e. have more IPv4 addresses or, in case of
shared addresses, larger exclusive port sets).
CE IPv6 address: One of the possible IPv6 addresses used to reach
the 4rd function of a CE node. It starts with the CE
IPv6 prefix and has the Well-known 4rd Interface ID in
its last 64 bits.
Despres, et al. Expires March 25, 2012 [Page 4]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
Port-set identifier (PSID): An identifier from which an exclusive
port set is algorithmically derived.
Generalized IPv4 prefix: An IPv4 prefix, an IPv4 address, or an IPv4
address plus a Port-set ID. Each one defines an IPv4
address space.
Mapping rule (Rule if context permits): A set of parameters whereby:
(1) a CE generalized IPv4 prefix is derived from a CE
IPv6 prefix; (2) a CE IPv6 address is derived from an
IPv4 address plus a port (or from an IPv4 address
alone in case of a port-less IPv4 payload). A 4rd
domain has one or more Mapping rules.
Rule IPv6 prefix: An IPv6 prefix that appears in a Mapping rule.
Rule IPv4 prefix: An IPv4 prefix that appears in a Mapping rule.
Rule BR IPv6 address: The IPv6 address of a BR, or of several
identical BRs. Rules having different <Rule IPv6
prefix, Rule IPv4 prefix> may have the same Rule BR
address.
CE index: In a CE IPv6 prefix, bits that follow the Rule IPv6
prefix that it MUST contain.
4rd Interface ID: A well-known Interface ID (to be assigned by
IANA). Having it, 4rd packets are distinguishable
form any other IPv6 packets whose destination
addresses start with CE IPv6 prefixes.
4. Architectural model and design objectives
A 4rd domain is an ISP network in which all CEs use a common set of
address mapping rules. Each rule comprises a Rule IPv6 prefix, Rule
IPv4 prefix, BR IPv6 address> mappings), and in which the right exit
can be picked by CE through the third parameter in chosen rule when
deriving it IPv4 address space. in which:
1. IPv6 Routing is supported.
2. Each CE is delegated an IPv6 prefix, with a routing plan
independent from IPv4.
3. Residual IPv4 service has to be offered to CEs, with some or all
of the following constraints:
Despres, et al. Expires March 25, 2012 [Page 5]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
A. Stateless operation. In addition to their delegated IPv6
prefixes, CEs need only to know the common set of Mapping
Rules of the Domain. These Rules can be statelessly
advertised to CEs (Section 5)
B. Support of IPv4 address sharing.
C. Ingress filtering compatibility. Several BRs having
different incoming IPv4 ISP prefixes from the Internet must
be supported. An IPv4 packet sent by a CE to the IPv4
Internet MUST exit the Domain via a BR having a reverse route
to this CE [RFC3704].
D. Differentiated IPv4 sharing ratios. (It MUST be possible to
assign IPv4 address spaces having different sizes to
different CEs)
E. Direct CE-CE routes. (CE-CE routes MUST be the same in IPv4
as in IPv6).
F. Asymmetric routing compatibility. (An IPv4 packet sent to
the Internet via a BR MUST have its response acceptable via
any other BR having the same parameters).
Figure 1 illustrates architectural aspects of 4rd domains.
Restricted port sets, where assigned to CEs, MUST satisfy the
following constraints:
1. Fairness. At least well-known ports 0-1023, which have more
value than others, MUST NOT be assigned to any restricted-port-
set CE.
2. Good-enough exhaustiveness. Ports that cannot be assigned to any
CE due to the assignment algorithm MUST be in small enough
proportion. (1/16, as proposed below, seems generally
acceptable).
3. RTP/RTCP compatibility. (Port set SHOULD contain complete odd-
even port pairs.)
Since ports are used as extension mechanism of IPv4 addresses,
protocols that have no ports are excluded from the solution. Note
that ICMP error messages that concern packets having ports in their
headers are not excluded: they contain copies of discarded-packet
headers. ICMP echo-request packets have no ports, but have in IPv4
16-bit Identifier fields. For CEs that have shared IPv4 addresses to
be able to ping remote IPv4 hosts that have exclusive IPv4 addresses,
Despres, et al. Expires March 25, 2012 [Page 6]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
CEs and BRs MUST process Identifier fields as though they would be CE
ports, both in Echo requests from CEs and in Echo responses to CEs.
(This does not permit IPv4 Pings between two shared-address CEs, but
this is inherent to IPv4 address sharing. IPv6 Pings should be used
instead.)
NOTE 1: An additional constraint for Port sets, the so-called UPnP
friendliness, has been considered in view of the wide deployment of
UPnP 1.0 control points in some operator's networks, and in view of
the known difficulty of extensive host upgrades. Its purpose is to
mitigate, in some cases, and to some extent, a weakness of early UPnP
implementations (version 1.0). If, despite the additional complexity
needed to support it, and despite its partially unpredictable effect
on deployed devices, it would have to be reintroduced after a Working
Group consensus, a possible design to support it is documented in
version -00 of this I-D.
Despres, et al. Expires March 25, 2012 [Page 7]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
1 or more
identical BRs
Customer per IPv4 1 or more
sites CEs 4rd Domain provider IPv4 providers
| | | | |
V V V V V
+----------------------+
| IPv6 routing | +--------------------
-------------+ | | |
| | +'-----'+
Derived +'-'+ | |
IPv4 | |<= CE IPv6 +.-----.+ <= One or more
add space +.-.+ prefix | ... | Domain
| | +'-----'+ IPv4 prefixes
-------------+ | | |
| +.-----.+
| | |
... | | +--------------------
| | IPv4 Internet ...
| | +--------------------
-------------+ | | |
| | +'-----'+
Derived +'-'+ | |
IPv4 | |<= CE IPv6 +.-----.+ <= One or more
add space +.-.+ prefix | ... | Domain
| | +'-----'+ IPv4 prefixes
-------------+ | | |
^ | +.-----.+
| | | |
| | | +--------------------
| +----------------------+
|
1 or more statelessly advertised mapping rules
Figure 1: 4rd Domain Model
NOTE 2: A particular use case has been identified, the so-called
"CPE-cascade" case. In it, the ISP that offers residual IPv4 service
does it across the IPv6-only service of another ISP, and this ISP
provides its own customer-premise equipments (CPEs). Some IPv6-
address bits are used within these CPEs for internal routing. For
this use case, "suffix" option in CPE IPv6 addresses has been
proposed. It implies that the length of CE IPv6 prefixes be a Rule
the same Mapping rule parameter. Because this conflicts with
differentiation of sharing ratios based on different IPv6 prefix
lengths, and because a specific option for this use case can be
documented in a separate document, it has not been covered in this
I-D.
Despres, et al. Expires March 25, 2012 [Page 8]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
5. 4rd Mapping Rules
A 4rd Domain has one or several Mapping rules, each one comprising
the following items:
o A Rule IPv6 prefix
o A Rule IPv4 prefix
o A Rule BR IPv6 address
Rules are considered to be indexed by Rule IPv6 prefix when a CE
looks for the matching rule with which it derives its IPv4
generalized prefix from its CE IPv6 prefix (see Section 6).
On the other hand, Rules are considered to be indexed by Rule IPv4
prefix when a CE looks for the matching rule with which it derives a
CE IPv6 address from an IPv4 destination (Section 7.1), or derives a
BR IPv6 address from an IPv4 source (Section 7.2).
For anti-spoofing protection, BRs and CEs MUST verify that the CE
IPv6 source address of a packet received from the Domain would be the
IPv6 destination addresses if the IPv4 source address, including the
port if available, would be taken as destination. each IPv4 packet
received by a BR or a CE after Domain traversal, the node A failure
of this check can be the result of a tentative spoofing attack. The
packet MUST be silently discarded (principle similar to that of
Reverse Path Forwarding in [RFC3704]).
If several BRs have the same IPv4 routes from the Internet, they are
configured with the same BR address. This address is routed in the
Domain as an anycast address so that these BRs can share the traffic
load. Note however that, for IPv4 address sharing, IPv4 datagram
reassembly may have to be supported by BRs (ports are used as address
extension tool, and fragmented datagrams have ports only in their
first fragments). Consequently, this load sharing between BRs MUST
be done with anycast routes that are stable most of the time. Route
changes may lead to a few losses of fragmented IPv4 datagrams, but
this remains acceptable provided they are rare enough.
CEs may receive Domain mapping rules in a variety of classic
provisioning methods: Stateless DHCPv6, [RFC3736], the Broadband
Forum's "TR-69", a DNS record, etc. Note that, if several rules have
a common BR address, as in the example of Section 9, format
optimization is possible. How to do it is however in scope of these
provisioning methods.
In order to send IPv4 packets to other CEs via the same routes as
Despres, et al. Expires March 25, 2012 [Page 9]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
IPv6 packets, each CE MUST know all Mapping rules of the Domain.
Ability to support up to 1000 rules, although unnecessary in typical
use cases, has been reported as useful for some exceptional
configurations. Since this is easily feasible with common memory
sizes, it is REQUIRED.
6. Mapping steps from CE IPv6 prefix to CE IPv4 address space
The following subsections detail steps whereby the IPv4 address space
assigned to a CE is derived from its CE IPv6 prefix. The example
below illustrates such a derivation with an example in which there is
one Mapping rule. Its CE IPv6 prefix, Rule IPv6 prefix, and Rule
IPv4 prefix, are supposed to be respectively 2001:db4:4444:4000::/52,
2001:db0::/28, and 192.32../12 (i.e. 0x602). For clarity, lengths of
Rule prefixes and CE prefix are multiple of 4 bits, but this is not
an obligation.
Item Hexadecimal Num. of bits
- CE IPv6 prefix : 20010DB444444 52
- Rule IPv6 prefix matching : 20010DB 28
- Resulting CE index : 444444 24
- Rule IPv4 prefix paired : 602 12
- Resulting Derived IPv4 address : 602444444
- Resulting CE's IPv4 address : 60244444 32
- Resulting Port-set ID : 4 4
- Resulting exclusive port-set : y4xx (with 16
y > 0 and any xx)
Despres, et al. Expires March 25, 2012 [Page 10]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
6.1. From CE IPv6 prefix to Generalized IPv4 prefix
<----------------- at most 64 bits ------------------>
+-----------------------------------------------------+
| CE IPv6 prefix | ||
+-----------------------------------------------------+ ||
: : ||
+--------------------------------+--------------------+ ||
| Rule IPv6 prefix | CE index | ||
+--------------------------------+--------------------+ ||
: : ||
+------------------+--------------------+ ||
| Rule IPv4 prefix | CE index | ||
+------------------+--------------------+ ||
: : ||
+---------------------------------------+ ||
| CE Generalized IPv4 prefix | \/
+---------------------------------------+
<----------- at most 44 bits ---------->
Figure 2: IPv6 prefix to Generalized IPv4 prefix
More text TBD, but Figure 2 is expected to be self-explanatory.
Despres, et al. Expires March 25, 2012 [Page 11]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
6.2. From Generalized IPv4 prefix to IPv4 prefix or IPv4 address or
IPv4 Address + Port-set ID
(A) CE Generalized IPv4 prefix shorter than 32 bits
+-----------------------------------+
| CE Generalized IPv4 prefix | ||
+-----------------------------------+ ||
: : ||
+-----------------------------------+ ||
| CE IPv4 prefix | \/
+-----------------------------------+
<----------------- 32 bits ----------------->
(B) CE Generalized IPv4 prefix having 32 bits
+-------------------------------------------+
| CE Generalized IPv4 prefix | ||
+-------------------------------------------+ ||
: : ||
+-------------------------------------------+ ||
| CE IPv4 address | \/
+-------------------------------------------+
<---------------- 32 bits ----------------->
(C) CE Generalized IPv4 prefix having 33 to 44 bits
+--------------------------------------------------+
| CE Generalized IPv4 prefix | ||
+--------------------------------------------------+ ||
: : ||
+-------------------------------------------+------+ ||
| CE IPv4 address | PSID | \/
+-------------------------------------------+------+
<----------------- 32 bits -----------------><--.-->
|
max 12 bits
Figure 3: Generalized IPv4 prefix to IPv4 prefix or IPv4 address or
IPv4 Address + PSID
More text TBD, but Figure 3 is expected to be self-explanatory.
NOTE: If the Port-set ID (PSID) has its maximum length of 12 bits,
the identified port set does not contain odd-even pairs of ports (see
Section 6.3). Practical configurations would therefore use mapping
rules such that the PSIDs do't exceed 11 bits, but the algorithm does
not need to impose it. (PSID limited to 11 bits is equivalent to
L(CE IPv6 prefix) < L(Rule IPv6 prefix) - L(Rule IPv4 prefix) + 44.)
Despres, et al. Expires March 25, 2012 [Page 12]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
6.3. From Port-set ID to Port set
1|
|0 |4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| PSID |x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ : : ^
| :<max 12 bits > |
| |
Any value > 0 Any value
Figure 4: From Port-set ID to Exclusive port set
More text TBD, but Figure 4 is expected to be self-explanatory.
7. Mapping from IPv4 address or address plus port to CE IPv6 Address
The following subsections detail steps whereby a CE IPv6 address is
derived from a CE IPv4 address, or address plus port if a port is
available. The derived CE IPv6 address has two REQUIRED properties:
o It MUST start with the CE IPv6 prefix of the CE that has the IPv4
address or address plus port in its IPv4 address space.
o It MUST be distinguishable from any possible IPv6 address that
starts with this prefix and is not concerned with 4rd. This is
achieved with the 200:5efe::/64 4rd-specific value in its
Interface ID field of [RFC4291] (see Figure 6).
The example below illustrates such a derivation where CE IPv6 prefix,
Rule IPv6 prefix, and Rule IPv4 prefix, are supposed be the same as
in Section 6 (i.e. respectively 2001:db4:4444:4000::/52, 2001:
db0::/28, and 192.32../12 = 0x602)). The IPv4 address and port are
chosen to be in the IPv4 address space of the considered CE. Note
that, for clarity, lengths of Rule prefixes and CE prefix are
multiple of 4 bits, but that similar derivations with less
constrained lengths are also possible.
Despres, et al. Expires March 25, 2012 [Page 13]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
Item Hexadecimal Value Nb of bits
- IPv4 port : 8488 16
- Derived
Max Port-set ID : 488 12
- IPv4 address : 60244444 32
- Rule IPv4 prefix
that matches this
IPv4 address : 602 12
- Resulting CE index : 44444488 32
- Rule IPv6 prefix
of the Rule : 20010DB 28
- Padding to 64 bits : 0 4
- Resulting
CE IPv6 address : 20010DB44444488002005EFE00000000 128
- Prefix routed
to the CE : 20010DB444444 52
The other example below illustrates such a derivation where Rule IPv6
prefixes are unchanged (2001:db0::/28, and 192.32../12 = 0x602
respectively). The considered CE has now an exclusive IPv4 address,
and the IPv4 packet sent to it has a port-less layer-4 protocol. The
CE IPv6 prefix is supposed to be 2001:db1:1111::/48, which maps to
IPv4 address 0x60211111 =192.33.17.17.
Item Hexadecimal Value Nb of bits
- Destination
IPv4 address : 60211111 32
- Rule IPv4 prefix
that matches this
IPv4 address : 602 12
- Resulting CE index : 11111 20
- Rule IPv6 prefix
of the Rule : 20010DB 28
- Padding to 64 bits : 0000 16
- Resulting
CE IPv6 address : 20010DB11111000002005EFE00000000 128
- Prefix routed
to the CE : 20010DB11111 48
Despres, et al. Expires March 25, 2012 [Page 14]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
7.1. From IPv4 Address or Address + Port to Rule IPv4 prefix + Max CE
index
(A) The IPv4 packet contains layer-4 ports
1|
|0 |4 5|
+---------------------------------+----------------+
| Destination IPv4 address |Destination port|
+---------------------------------+---+------------+
: : : :<- 12 bits ->
+-----------------+ : : :
| Rule IPv4 prefix| : : :
+-----------------+ : : :
: : : :
+---------------+ +------------+
| CE IPv4 suffix| | Max PSID |
+---------------+ +------------+
: : / /
: : / /
: :/ /
+---------------+------------+
| Max CE index |
+----------------------------+
<-------------------- 44 bits ----------------->
(B) The IPv4 packet contains no layer-4 port
+---------------------------------+
| Destination IPv4 address |
+-----------------+---------------+
: : :
+-----------------+ :
| Rule IPv4 prefix| :
+-----------------+ :
: :
+---------------+
| Max CE index |
+---------------+
<------------- 32 bits ----------->
Figure 5: From IPv4 Destination to Rule IPv4 prefix + Max CE index
More text TBD, but Figure 5 is expected to be self-explanatory.
Despres, et al. Expires March 25, 2012 [Page 15]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
7.2. From Rule IPv4 prefix + Max CE index to CE IPv6 address
+------------------+
| Rule IPv4 prefix |
+------------------+
||
\/
+--------------------------+
| Rule IPv6 prefix |
+--------------------------+
(A) Truncation case
<------------------ More than 64 bits ----------------->
+---------------------------+--------------------------+
| Rule IPv6 prefix | Max CE index |
+---------------------------+-----------------+--------+
:<------------------- 64 bits ---------------->
: :<----- 64 bits ------>
: : :
+---------------------------------------------+----------//---------+
| Subnet prefix | 4rd IID |
+---------------------------------------------+----------//---------+
: :
+-------------------------------------------------------------------+
| CE IPv6 address |
+-------------------------------------------------------------------+
(B) Padding case
<------------ Up to 64 bits ------------>
+-------------------------+---------------+---+
| Rule IPv6 prefix | Max CE index | 0 |
+-------------------------+---------------+---+
: : :
:<------------------- 64 bits ---------------->
+-----------------------------------------+---+----------//---------+
| Subnet prefix | 4rd IID |
+---------------------------------------------+----------//---------+
: :
+-------------------------------------------------------------------+
| CE IPv6 address |
+-------------------------------------------------------------------+
Figure 6: From Rule IPv4 prefix + Max CE index to CE IPv6 address
Despres, et al. Expires March 25, 2012 [Page 16]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
In order to permit coexistence of the 4rd stateless solution with
other solutions in the same nodes, CE IPv6 addresses MUST be
differentiable from all other valid IPv6 addresses. For this, 4rd
Interface IDs are proposed to start with 200:5efe::/64 (a choice to
be confirmed by IANA). Reasons of this choice are the following: (1)
In order to indicate a universal scope of this Interface-ID format,
bit 6 of the first octet must be set to 1 (the "u" bit of [RFC4291]);
(2) In order to guarantee no conflict with other universal scope
Interface IDs, other bits of the first 32 bits are those of the IANA
OUI in modified EUI format (the same as in [RFC4214]). Bits 64-127
are set to 0 if theDomain-traversal method is encapsulation, and is
the embedded IPv4 address in case of double translation.
8. Mapping from IPv4 source address to BR IPv6 Address
If a CE has an IPv4 packet to forward across the Domain and finds
that its destination is not another CE (no Rule IPv4 prefix matches
its IPv4 destination address), it has to send it to the IPv4 Internet
via a BR. For compatibility wit Ingress filtering, this BR MUST be
one that has an incoming route from the Internet that can reach this
CE.
+---------------------------------+
| CE IPv6 prefix |
+------------------+--------------+
: :
+------------------+
| Rule IPv6 prefix |
+------------------+
||
\/
+------------------------------------------------------------+
| Rule BR IPv6 address |
+------------------------------------------------------------+
Figure 7: From IPv4 source address to BR IPv6 Address
NOTE: While the above mapping is sufficient for Domain traversal
based on encapsulation of IPv4 packets in IPv6 packets, it isn't
sufficient for those based on double translation. With these, BRs
need to find IPv4 destination addresses in destination IPv6 addresses
that reach it. For this, the BR IPv6 address of each Rule can be
replaced by a BR IPv6 prefix of 96 bits. BR IPv6 addresses are then
constructed with embedded IPv4 addresses in their last 32 bits.
Despres, et al. Expires March 25, 2012 [Page 17]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
In the example below, we take the rule of previous examples, whose
Rule IPv6 prefix = 2001:db0::/28, and Rule IPv4 prefix = 192.32../12.
We then take BR IPv6 address = 2001:db3::3 as third parameter (not
needed in previous sections).
Item Hexadecimal Value Nb of bits
- Destination
IPv4 address : 60433333 32
- Rule IPv4 prefix : 602 (non matching)
- CE IPv6 prefix : 20010DB4 4444 4 52
- Rule IPv6 prefix
that matches it : 20010DB 28
- BR IPv6 address
of this Rule : 20010DB30000000000000000000000003 128
9. Example of 4rd Domain with two Rule BR addresses and three Rule IPv4
prefixes
If a 4rd domain has a split IPv4 space to distribute to CEs, i.e. a
space defined by several disjoint IPv4 prefixes, several Mapping
rules can be used to keep the IPv6 routing plan independent from any
IPv4 influence. (The "entropy" of the IPv4 space is thus not passed
on to the IPv6 the IPv6 space.)
To illustrate this possibility, we now consider an ISP having 2001:
0db0::/28 as unique IPv6 prefix, and three IPv4 prefixes. The first
two, 192.32../13 and 192.64../14, come from an IPv4 service provider
whose BR has 2001:db1::1 as IPv6 addresses. The last one,
192.16.64.0/14, comes from an IPv4 service provider whose BR has
2001:db2::2 as IPv6 address.
The following Mapping rules can be configured to evenly distribute
all IPv4 addresses. They also make sure that each IPv4 packet that
leaves the domain does it via the right BR (that which, as far as
ingress filtering is concerned, has a route from the IPv4 internet
for the right IPv4 prefix).
+------------------+------------------+-----------------+
| Rule IPv4 prefix | Rule IPv6 prefix | BR IPv6 address |
+------------------+------------------+-----------------+
| 192.32../13 | 2001:db0::/29 | 2001:db1::1 |
| 192.16../14 | 2001:db8::/30 | 2001:db1::1 |
| 192.24../14 | 2001:dbc::/30 | 2001:db2::2 |
+------------------+------------------+-----------------+
Despres, et al. Expires March 25, 2012 [Page 18]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
With these mapping rules, here are examples of CE parameters:
+-------------------------+--------------+----------------+---------+
| CE IPv6 prefix | CE IPv4 | Port-set | Nb of |
| | address | pattern | ports |
| | | (Hexadecimal) | |
+-------------------------+--------------+----------------+---------+
| 2001:db0:1111:1000::/52 | 192.32.17.17 | y1xx | 3840 |
| 2001:db8:1111::/48 | 192.16.17.17 | N/A | 64K |
| 2001:dbc:1111:1000::/52 | 192.24.17.17 | y2xx | 3840 |
+-------------------------+--------------+----------------+---------+
10. Security considerations
Like any mechanism that needs parameters to be configured by ISPs,
the 4rd stateless address mapping is subject to consequences of
erroneous parameter settings.
Other than that, with anti-spoofing checks of Section 5, no security
vulnerability has been identified that would be due to the 4rd
stateless address mapping.
11. IANA Considerations
For the 4rd stateless address mapping to possibly coexist with a
maximum of other IPv4/IPv6 address mappings, a 4rd-specific Interface
IDs are desirable.
For this, 200:5efe::/32 in their first half is proposed (universal
scope with the IANA OUI, as explained in Section 7.2).
12. Acknowledgements
Authors would like to acknowledge the invaluable contribution of
Satoru Matsushima. His very early and constant support of the
stateless approach has been key for its progress in IETF. Tetsuya
Murakami deserves specific recognition for his implementation of an
early 4rd specification, including its Ping mechanism for shared
addresses. This has been important to confirm soundness of the
approach. Without Mark Townsley's convincing arguments made to the
IETF hierarchy, having stateless solutions as work items in Softwire
wouldn't have been done in the same time frame. He has to be thanked
for it. Wojciech Dec and some others made a number of relevant
remarks on the Working Group discussion list that contributed to
improve the proposed design.
Despres, et al. Expires March 25, 2012 [Page 19]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
13. References
13.1. Normative References
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
13.2. Informative References
[I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-ietf-softwire-stateless-4v6-motivation-00 (work in
progress), September 2011.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, October 2005.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
Despres, et al. Expires March 25, 2012 [Page 20]
Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011
Authors' Addresses
Remi Despres (editor)
RD-IPtech
3 rue du President Wilson
Levallois,
France
Email: despres.remi@laposte.net
Jacni Qin
ZTE
Shanghai
China
Email: jacni@jacni.com
Simon Perreault
Viagenie
2875 Laurier, suite D2-630
Quebec
Canada
Email: simon.perreault@viagenie.ca
Xiaohong Deng
France Telecom
Hai dian district, 100190
Beijing
China
Email: xiaohong.deng@orange.com
Despres, et al. Expires March 25, 2012 [Page 21]