Internet Engineering Task Force R. Despres, Ed.
Internet-Draft RD-IPtech
Intended status: Standards Track J. Qin
Expires: February 20, 2012 ZTE
S. Perreault
Viagenie
X. Deng
France Telecom
August 19, 2011
Stateless Address Mapping for IPv4 Residual Deployment (4rd)
draft-despres-softwire-4rd-addmapping-00
Abstract
This document specifies an address mapping mechanism, 4rd, for
service providers to offer residual deployment of the IPv4 service
across IPv6-only domains. Ease of operation and scalability are due
to address mapping being done stateless (no per customer states).
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. IPv4 address sharing is
based on exclusive port sets that are algorithmically derived of IPv4
prefixes longer than 32 bits. The 4rd address mapping can be used
combined with various tunneling or translation mechanisms. It can
also can be used either alone or in parallel with stateful mechanisms
used for their flexibility.
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 February 20, 2012.
Copyright Notice
Despres, et al. Expires February 20, 2012 [Page 1]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Design Objectives . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Architectural model . . . . . . . . . . . . . . . . . . . 5
4.2. Compatibility with Asymmetric routing . . . . . . . . . . 5
4.3. Compatibility with Reverse-Path Forwarding . . . . . . . . 6
4.4. Same routes for IPv4 packets and IPv6 packets . . . . . . 6
4.5. Multiple IPv4 prefixes without impact on IPv6 routing . . 6
4.6. Stateless Support of Shared IPv4 Addresses . . . . . . . . 7
4.6.1. Flexible Sizes of CPE-assigned Port-Sets . . . . . . . 7
4.6.2. Odd-even port couples in assigned port sets . . . . . 7
4.6.3. Interleaved Port Sets for UPnP friendliness . . . . . 7
5. Specification of the 4rd Stateless Address Mapping . . . . . . 8
5.1. Mapping-Rule Parameters and Basic Operation . . . . . . . 8
5.2. Mapping from IPv6 Prefix to IPv4 Prefix (including A+P) . 9
5.3. Mapping from IPv4 address or A+P to IPv6 address . . . . . 10
5.4. Algorithmic Derivation of a Port Set from a Port-Set ID . 13
5.5. The CPE-Cascade Option . . . . . . . . . . . . . . . . . . 14
6. Mapping-rule Examples for some Representative 4rd Domains . . 14
7. Security considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Despres, et al. Expires February 20, 2012 [Page 2]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 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 routing done only in IPv6. They will however have to
maintain residual IPv4 connectivity across these networks, for some
customers with exclusive IPv4 addresses, and for some others with
shared IPv4 addresses. This document specifies a mechanism, 4rd,
whereby ISPs statelessly derive IPv4 addresses they assign to
customers from the IPv6 prefixes they have delegated to them.
In this document, stateless means without per-customer states in ISP
nodes concerned with the 4rd address mapping and without, for 4rd,
states about other CPEs in each CPE.
This specification can be used in association with a variety of
tunneling or translation mechanisms that are in scope of other
documents. (Earlier 4rd documents such as
[I-D.despres-softwire-sam]-sec. 3.2 and [I-D.murakami-softwire-4rd]
simultaneously covered stateless address mapping and encapsulation-
based tunneling, but it has now become clearthat stateless address
mapping can have a much larger scope than just this tunneling.)
Design objectives that influenced this specification are listed in
Section 4. Section 5 specifies the 4rd stateless address mapping.
Examples of 4rd mapping-rule configurations, for diverse ISP needs,
are illustrated in Section 6.
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].
3. Terminology
ISP: Internet-Service Provider. In this document,
it can be a DSL, a fiber-optics, cable, or a
wireless operator. It can also be a private-
network operator.
4rd CPE (CPE if context permits): Customer Premise Equipment that
supports the 4rd stateless address mapping.
Despres, et al. Expires February 20, 2012 [Page 3]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
4rd AFTR (AFTR if context permits): Address-Family-Transition Router
that supports the 4rd stateless address
mapping.
4rd domain (Domain if context permits): An ISP IPv6-only network
across which a residual IPv4 service is offered
using the 4rd address mapping. It has at least
one 4rd AFTR at its border to the IPv4
Internet, and a number of CPEs which may or may
not be 4rd CPEs.
A+P: IPv4 address plus transport-layer port, also
known as "transport address".
Port-set ID (PSID): An identifier from which a port set is
algorithmically derived according to
Section 5.4.
CPE IPv6 prefix: An IPv6 prefix delegated to a CPE, e.g. per
[RFC3769]).
CPE IPv4 prefix: In this document, an IPv4 address prefix or an
IPv4 address followed by a Port-set ID.
4rd mapping rule (Mapping rule, or Rule, if context permits): A set
of parameters that permit to derive a CPE IPv4
prefix from a CPE IPv6 prefix, and to derive an
IPv6 address from an IPv4 address or A+P. A 4rd
domain has at least one Mapping rule, and may
have several. Each Rule contains at least a
Domain IPv6 prefix, a Domain IPv4 prefix, and
an AFTR IPv6 prefix.
Domain IPv6 prefix: An IPv6 prefix that appears in a Mapping rule.
Domain IPv4 prefix: An IPv4 prefix that appears in a Mapping rule.
AFTR IPv6 prefix: For a set of AFTRs that share the same IPv4
prefixes, the /64 IPv6 prefix used by CPEs to
reach them.
4rd IID prefix: A 32-bit value use to disambiguate what
concerns the 4rd address mapping from other
address mapping that may coexist it the same
AFTRs or CPEs, e.g. with dynamic port
assignments.
Despres, et al. Expires February 20, 2012 [Page 4]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
Domain IPv6 suffix: Optional parameter of a Mapping rule applicable
to specific configurations having cascaded CPEs
(see Section 5.5).
4. Design Objectives
4.1. Architectural model
The 4rd stateless address mapping is for an IPv6-only routing domain
in which:
o Each CPE is delegated an IPv6 prefix.
o Residual IPv4 service has to be offered to CPEs.
o Some design objectives detailed in the following sections have to
be satisfied.
If some objective(s) would be relaxed, the specification could be
simplified accordingly. Yet, a unique solution that covers a large
scope of use cases is in general be better for ISPs and for product
vendors, provided it remains simple enough. This specification is
expected to be such.
4.2. Compatibility with Asymmetric routing
An ISP can have border points to the IPv4 Internet that are
geographically far apart and for which there are incoming routes for
the same prefixes. This can be the case with provider-independent
prefixes (PIs), if routed from the Internet core to the via several
independent providers. It can also be the case with provider-
dependent prefixes (PAs), if coming from providers having several
Internet exchange points. packets sent to a host of another ISP via a
given border point may have answers coming via another border point.
End-to-end routes can in this case be asymmetric.
Unless some nodes between AFTRs and CPEs would also deal with both
IPv4 and IPv6 (which is contrary to the IPv6-only nature of the
Domain), this implies in practice static address mappings in AFTRs.
(Otherwise, complex coordination between widely separated AFTRs would
be necessary.)
Compatibility with asymmetric routing without complex coordination
between AFTRs is an objective of the 4rd specification.
Despres, et al. Expires February 20, 2012 [Page 5]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
4.3. Compatibility with Reverse-Path Forwarding
An ISP can be allocated IPv4 prefixes from different lower-tier
providers (tier numbers decrease in direction to the Internet core).
These providers normally exercise anti-spoofing control at their
border points with the reverse-path forwarding of [RFC3704]. A CPE
that is assigned an IPv4 address for incoming connectivity must
therefore send its IPv4 packets to off-Domain destinations via the
provider that delegated the prefix of this IPv4 address.
Sending IPv4 packets to the Internet via AFTRs that are compatible
with reverse-path forwarding is an objective of this specification.
4.4. Same routes for IPv4 packets and IPv6 packets
If IPv4 traffic follows the same routes than IPv6 traffic, the impact
on IPv4 quality of service can remain negligible compared with direct
support of IPv4 routing in the Domain. This is useful to facilitate
ISP moving from dual-stack routing to IPv6-only routing. Also,
scalability of the solution is improved by the fact that AFTRs don't
need to deal with traffic between CPEs of the Domain. (In
particular, if some content-providers have servers in the domain, it
traffic between in-domain customers and these servers does not
contribute to the load of AFTRs.)
Support of common routes between IPv4 and IPv6 traffics, in
particular between CPEs, is an objective of the 4rd specification.
4.5. Multiple IPv4 prefixes without impact on IPv6 routing
An ISP whose need for IPv4 addressing space has increased over time
has typically a number of allocated IPv4 prefixes. The IPv6 routing
plan is easier to setup if not influenced by the multiplicity of
these prefixes. In other words, the problem is to statelessly
distribute the fragmented IPv4 space among CPEs whose IPv6 prefixes
have been allocated without any concern for IPv4.
NOTE: IPv4 address sharing can be used to reduce the number of IPv4
prefixes to be supported. Let us take, for example, an ISP whose
IPv4 prefixes are one /10, two /11s, one /14, one /15, and one /16 (a
real example of the past). If it returns the three longest prefixes
to the free pool, it reduces the IPv4-space size by only 5%. If it
shares one IPv4 address out of 16 among 16 customers, the total
number of supported customers is increased by 94%, which more than
compensates the 5% loss. (Whether returning prefixes to the free
pool would be with a compensation is beyond the scope of this
document.)
Despres, et al. Expires February 20, 2012 [Page 6]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
Ability to support multiple IPv4 prefixes without impact on IPv6
routing is an objective of this specification.
4.6. Stateless Support of Shared IPv4 Addresses
Because IPv4 prefixes allocatable to ISPs has been exhausted, the
need to share IPv4 public address among several customers is now well
known, with ports as the multiplexing instrument. While dynamic
assignments of ports to customers can optimize the sharing ratio of
IPv4 addresses, static assignments are an approach to comply with
route commonality between IPv4 and IPv6 of Section 4.4, and with
asymmetric-routing compatibility of Section 4.2. Also, stateless
operation simplify operation in many typical cases. It is an
objective of the 4rd specification.
4.6.1. Flexible Sizes of CPE-assigned Port-Sets
In IPv4, some customers are delegated IPv4 prefixes shorter than 32
bits, while the vast majority are only assigned single IPv4
addresses. In the context of shared IPv4 addresses, some customers
will need individual addresses, and sooner or later the vast majority
will have to be satisfied with shared IPv4 addresses.
Ability to assign port sets of different sizes to different classes
of customers is an objective of this specification. Because it has
to be done without interfering with other objectives, different port-
set sizes are linked to different lengths of delegated IPv6 prefixes.
4.6.2. Odd-even port couples in assigned port sets
A number of protocols designed a long time ago require pairs two
consecutive ports. In particular, a SIP application using the RTP of
[RFC3550] without support of the RTCP of [RFC3605] uses odd/even port
pairs. Also, where FTP of [RFC0959] is used in passive mode without
the option that relaxes this constraint, even/odd pairs are needed.
Although there may be very few impacted hosts if odd/even pairs would
become impossible, it is hard to predict where and when they this
appear. That may be costly to diagnose.
In order to ensure backward compatibility with old practices,
assigning port sets that contain odd-even pairs of ports is an
objective of this specification.
4.6.3. Interleaved Port Sets for UPnP friendliness
In a CPE having a restricted port set and a NAT44 that supports UPnP
for hosts to reserve ports for incoming connectivity, the number of
Despres, et al. Expires February 20, 2012 [Page 7]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
UPnP attempts before obtaining a port is a legitimate concern. With
UPnP version 1, widely deployed, hosts try ports in sequential order
numbers until one is obtained from the NAT. By interleaving port
sets, the likely number of attempts before getting an available port
can be statistically reduced.
Assigning to CPEs port sets that are as interleaved as possible is,
for UPnP-version-1 friendliness, an objective of this specification.
This objective is however subject to the odd/even-pair constraint of
Section 4.6.2.
NOTE: Typical NAT implementations assign ports based on the
assumption of a single port range. With this objective of
interleaved port sets they need to be adapted. Provided there is a
simple algorithm that does a 1:1 mapping between ports of the port-
set and a continuous port range, this is not difficult. This is the
case with port sets of Section 5.4.
5. Specification of the 4rd Stateless Address Mapping
5.1. Mapping-Rule Parameters and Basic Operation
A 4rd domain are one or several Mapping rules, each one having the
following parameters:
o REQUIRED parameters:
* Domain IPv6 prefix
* Domain IPv4 prefix
* AFTR IPv6 prefix
o OPTIONAL parameters (see Section 5.5):
* CPE IPv6 suffix
* CPE IPv6-prefix length
Each AFTR has incoming routes from the Internet for one or several
IPv4 prefixes. It MUST know all Mapping rules that have one of these
prefixes as Domain IPv4 prefix.
In order to send IPv4 packets to other CPEs via the same routes as
IPv6 packets, each CPE 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
Despres, et al. Expires February 20, 2012 [Page 8]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
configurations. Since this is easily feasible with common memory
sizes, it is REQUIRED.
For each packet received at its IPv4 interfaces, an AFTR or a CPE
MUST use Mapping rules it knows to determine the IPv6 destination
used to traverse the Domain. It MUST also verify that the IPv4
source of the packet is one that would be a possible destination in
the reverse direction. If one of these two steps fails, the IPv4
packet is silently discarded. Otherwise the packet is forwarded with
whatever tunneling or translation mechanism applies.
For each packet received at its IPv6 interface with an IID as
specified in Section 5.3, an AFTR or CPE MUST check that the IPv4
address or A+P it contains is a possible destination in the reverse
direction and, if the packet is encapsulated, that the IPv6 source
address is that which Mapping rules derive from the IPv4 source. In
case of success, it MUST forward the packet to the IPv4 destination
found in the IPv6 packet (with decapsulation or translation as the
case may be). Otherwise, it MUST silently discard the packet.
Since ports are used as extension mechanism of IPv4 addresses,
protocols that have no ports are excluded from the solution. ICMP
error messages that concern discarded packets that had ports in their
transport-layer headers are not in this case because they contain
copies of discarded-packet headers. ICMP echo-request packets have
no ports but have in IPv4 a 16-bit identifier field. In both CPEs
and AFTRs, this field MUST be processed as though it would be a CPE
port. Note that this permits CPEs having shared IPv4 addresses to
Ping remote IPv4 hosts that have exclusive IPv4 addresses. (This
does not permit IPv4 Pings between two shared-address hosts, but this
is inherent to IPv4 address sharing. IPv6 Pings should be used
instead.)
CPEs may receive Domain mapping rules in a variety of classic
provisioning methods, including DHCPv6, the Broadband Forum's
"TR-69", a DNS record, etc. A separate draft on DHCPv6 provisioning
is expected to be discussed in Softwire, with
draft-mrugalski-softwire-dhcpv6-4rd-00 as envisaged file name.
5.2. Mapping from IPv6 Prefix to IPv4 Prefix (including A+P)
How a CPE derives its CPE IPv4 prefix is detailed in Figure 1.
Despres, et al. Expires February 20, 2012 [Page 9]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
<------------------ up to 64 bits ------------------->
+-----------------------------------------------------+
| CPE IPv6 prefix (delegated by the ISP) |
+-----------------------------------------------------+
: :
: (1) Find a matching rule :
+--------------------------------+ :
| Domain IPv6 prefix | (2) Delete the :
+--------------------------------+ Domain IPv6 prefix :
: :
+--------------------+
| |
+--------------------+
Domain IPv4 prefix : :
| : :
+---|---------+ (3) Add the :
| | | Domain IPv4 prefix :
+-------------+ of the rule :
: :
+----------------------------------+
| CPE IPv4 prefix (A or A+P) |
+----------------------------------+
<--------- max 46 bits ----------->
Figure 1: Mapping from CPE IPv6 prefix to CPE IPv4 prefix (A or A+P)
NOTE: If, as it seems so far, CPEs are expected to have non
overlapping IPv6 prefixes, the first match found is sufficient.
Should the need for CPE IPv6 ) prefixes that overlap be confirmed, as
some have suggested, longest match should become a requirement.
5.3. Mapping from IPv4 address or A+P to IPv6 address
How a CPE or AFTR derives from an IPv4 address or A+P an IPv6 address
is detailed in Figure 2 (in-domain address case) and in Figure 3
(off-domain address case).
Despres, et al. Expires February 20, 2012 [Page 10]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
|0 31| |0 3| 15|
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination Port (if any) |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (1) : :<--L-->::
: Find a rule having : (3) : (*) :
: a matching : If a port is available :
: Domain IPv4 prefix : and isn't in the first 4K, :
+-------------------+ : extract L bits before bit 15, :
| Domain IPv4 prefix| : and reverse their order. :
+-------------------+ (2) : : :
: Delete : +-+-+-+-+
: the Domain: | |
:IPv4 prefix: (4) +-+-+-+-+
: : Concatenate available : :
+-----------+ intermediate results : :
| | : :
+-----------+ _____________________/ /
: : / ______________________/
: :/ /
+-----------+-------+ Domain IPv6 suffix
| | (if applicable)
+-----------+-------+ /
: (5) : / Padding to 64 bits
: Complete the : / (if needed)
: Tunnel-endpoint : / ____________|
: IPv6 address : | |
|0 : : | | |64 127|
+----- - - - - ------+-------------------+-|-+-|-+--- - - - - - ---+
| Domain IPv6 prefix | | | 0 | 4rd IID (**) |
+----- - - - - ------+-------------------+---+---+--- - - - - - ---+
CPE IPv6 address / :
________________________________/ :
/ :
+--------------------------+--------------------------+
| 4rd IID prefix (**) | 0 or IPv4 address (***) |
+--------------------------+--------------------------+
(*) L = maximum length of Port-set IDs of the matching rule
(**) . The 4rd IID prefix (TBD by IANA) for encapsulation-based or
double-translation based solutions
. 0 per RFC 6145 for IPv6-only CPEs
(***) . 0 for encapsulation-based solutions
. The IPv4 address for translation-based solutions
Figure 2: IPv4 (A or A+P) to IPv6 Mapping - In-Domain Address
The maximum length L of port-set IDs is in absence of a CPE-cascade
Despres, et al. Expires February 20, 2012 [Page 11]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
option, is L = min(14, 64 - Length(Domain IPv6 prefix) - (32 -
Length(Domain IPv4 prefix)). With the CPE-cascade option, the CPE
IPv6-prefix length is a rule parameter, say X, and L = X -
Length(Domain IPv6 prefix) - (32 - Length(Domain IPv4 prefix)).
For tunnel-based solutions (encapsulation or double-translation
based), 4rd IIDs have to be different from any IID a host of the CPE
site may legitimately have. Also, in order to permit coexistence of
the 4rd stateless solution with other solutions (e.g. some using NAPT
to support dynamic port mappings for more optimized address sharing),
4rd has to be different from any IID that may be used by these other
solutions. In particular, it has to differ from that used by IPv4/
IPv6 translators conforming to [RFC6145]. For this, the value
proposed to IANA for the 4rd IID prefix is 200:5efe::/32. It has bit
6 of its first octet set to 1, in order to indicate a universal scope
of the IID ("u" bit of). Its other bits have, like in [RFC4214],
IANA OUI in modified EUI format (ref. [RFC4291]).
| IPv4 DST | | IPv4 SRC |
+--------------------------+ +--------------------------+
(1) : (2) :
Detect that no rule has a : Find a rule having :
matching Domain IPv4 prefix : a matching :
: Domain IPv4 prefix :
: :
+-------------------+ :
| Domain IPv4 prefix| :
+-------------------+------+
(3)
Take the AFTR IPv6 prefix of the rule
and the appropriate 4rd IID to complete the IPv6 address
|0 |64 127|
+---------------------------------+---------------------------------+
| AFTR IPv6 prefix | 4rd IID (*) |
+---------------------------------+---------------------------------+
AFTR IPv6 address
(*) As for in-domain addresses
Figure 3: IPv4 (A or A+P) to IPv6 Mapping - Off-Domain Address
Despres, et al. Expires February 20, 2012 [Page 12]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
5.4. Algorithmic Derivation of a Port Set from a Port-Set ID
The port set specified by an
[A] From IPv4 prefix longer than 32 bits to PSID
|0 31|
+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+
| CPE IPv4 prefix (A+P) |
+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
Delete the first 32 bits : :
+-+-+-+-+
(Port-set ID) --- PSID |
+-+-+-+-+
[B] From PSID to port-set pattern
+-+-+-+-+
| PSID |
+-+-+-+-+
(1) Reverse bits left to right : :
("ABC..." => "...CBA") : :
+-+-+-+-+
Reversed port-set ID --> |R-PSID |
+-+-+-+-+
(2) Place the result in the port pattern : :
with its last bit in bit 14 position : :
: :
|0 3| : 14:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-set pattern: |y y y y|x x x x x x x|R-PSID |x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ \___________/ \/
| \______________/
0x1 to 0xF Any value
Figure 4: Port Pattern derived from a Port-Set ID
Despres, et al. Expires February 20, 2012 [Page 13]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
5.5. The CPE-Cascade Option
A use case has been identified where the ISP that wants to offer
residual IPv4 service to offer has to offer it across an IPv6-only
service obtained from another ISP, and where this other ISP provides
its own CPEs in customer sites (the "outer CPEs"). In outer CPEs,
the other ISP adds a "suffix" to customer-site IPv6 prefixes to
select among its physical interfaces. The 4rd ISP then attaches its
4rd CPEs to a specific interface of outer CPEs, the same in all
sites. The suffix of this interface must be included in IPv6
addresses that target 4rd CPEs, but it must not be included in CPE
IPv4 prefixes (that would be waste of the precious IPv4 address space
of the Domain).
For this to work, two optional rule parameters are added: the Domain
IPv6 suffix and the CPE IPv6-prefix length. Their use has been
specified in Section 5.3.
An example of Domain configuration using this option is shown in
Section 6.
6. Mapping-rule Examples for some Representative 4rd Domains
The following examples are chosen to illustrate representative use
cases of 4rd mapping rules. Many other combinations are possible, in
particular by mixing and matching properties of the chosen examples.
(A) ISP PROVIDING EXCLUSIVE AND SHARED ADDRESSES
We consider an ISP domain having the following parameters:
* Domain IPv6 prefix: 2001:db0::/28
* Domain IPv4 prefix: 192.32.0.0/12
The IPv4 prefix may be a provider-aggregetable prefix allocated
by a single lower-tier provider of the ISP. It can also be a
provider independent prefix, with routes to the Domain for this
prefix from several lower-tier operators of the ISP.
The choice is to assign in /48 IPv6 prefixes to privileged
customers those who paying for exclusive IPv4 addresses, and /52s
to ordinary customers who accept to share their IPv4 addresses.
Privileged customers are expected to be a minority.
Despres, et al. Expires February 20, 2012 [Page 14]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
With up to 2^16 customers having privileged addresses, this
leaves 2^20 - 2^16 IPv4 addresses to be shared, giving 2^16 + 2^4
* (2^20 - 2^16) = 15,794,176 ordinary customers. Thus, 15 times
more customers are supported than if all had exclusive addresses
(their number would have been 2^(32-12) = 1,048,576).
The Domain has for this the following mapping rule:
+--------------------+--------------------+-------------------------+
| Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
+--------------------+--------------------+-------------------------+
| 192.32../12 | 2001:db0::/28 | 2001:db0:aaaa:aaaa::/64 |
+--------------------+--------------------+-------------------------+
With this rule, here are representative examples of CPE
parameters:
+-------------------------+--------------+------------------+-------+
| CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of |
| | address | pattern | ports |
+-------------------------+--------------+------------------+-------+
| 2001:db1:1111:/48 | 192.33.17.17 | NA | 64K |
| 2001:db2:2222:2000::/52 | 192.34.34.34 | yyyyxxxxxxx0100x | 3840 |
+-------------------------+--------------+------------------+-------+
NOTE: Without changing the mapping rule, some customers could be
delegated /56 IPv6 prefixes. This would increase even more the
number of supportable customers, with 960 ports per /56 customer.
(B) ISP HAVING IN IPV4 THRE PREFIXES FROM DIFFERENT PROVIDERS"
We now consider an ISP having 2001:0db0::/28 as Domain IPv6
prefix, and three Domain IPv4 prefixes from different lower-tier
providers, 192.32.128.0/13, 192.64.128.0/14, 192.16.64.0/14, and
192.16.128.0/13.
The following Mapping rules ensure that each IPv4 packet that
leaves the domain does it via the right AFTR (that which, as far
as anti-spoofing protection is concerned, is attached to the
right lower-tier provider).
+--------------------+--------------------+-------------------------+
| Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
+--------------------+--------------------+-------------------------+
| 192.32../13 | 2001:db0::/29 | 2001:db0:aaaa:aaaa::/64 |
| 192.16../14 | 2001:db8::/30 | 2001:db1:bbbb:bbbb::/64 |
| 192.24../14 | 2001:dbc::/30 | 2001:db2:cccc:cccc::/64 |
+--------------------+--------------------+-------------------------+
Despres, et al. Expires February 20, 2012 [Page 15]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
With these mapping rules, here are examples of CPE parameters:
+-------------------------+--------------+------------------+-------+
| CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of |
| | address | pattern | ports |
+-------------------------+--------------+------------------+-------+
| 2001:db0:1111:1000::/52 | 192.32.17.17 | yyyyxxxxxxx1000x | 3840 |
| 2001:db8:1111::/48 | 192.16.17.17 | NA | 64K |
| 2001:dbc:1111:1000::/52 | 192.24.17.17 | yyyyxxxxxxx0100x | 3840 |
+-------------------------+--------------+------------------+-------+
(C) ISP PROVIDING SHARED ADDRESSES ACROSS WITH CPE CASCADES
We now consider an ISP whose IPv6-only infrastructure comes from
another provider whose CPEs use a 4-bit suffix to reach LAN
interfaces at which 4rd CPEs are attached (see ). The suffix
value is supposed to be 0xF. The 4rd ISP has 2001:0db0::/28 as
Domain IPv6 prefix, and has four Domain IPv4 prefixes coming from
the same lower-tier provider, namely 192.32.128.0/13,
192.64.128.0/14, 192.16.64.0/14, and 192.16.128.0/13. Each IPv4
address is shared among 16 customers. With its 2^20 IPv4
addresses, The ISP can thus support up to 2^24 customers.
The following mapping rules can be used:
+-----------------+-----------------+----------------+--------------+
| Domain IPv4 | Domain IPv6 | CPE IPv6 max | CPE IPv6 |
| prefix | prefix | length | suffix |
+-----------------+-----------------+----------------+--------------+
| 192.32../13 | 2001:db0::/29 | 52 | 0xF |
| 192.16../14 | 2001:db8::/30 | 52 | 0xF |
| 192.24../14 | 2001:dbc::/30 | 52 | 0xF |
+-----------------+-----------------+----------------+--------------+
With these mapping rules, here are examples of CPE parameters:
+-------------------------+--------------+------------------+-------+
| CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of |
| | address | pattern | ports |
+-------------------------+--------------+------------------+-------+
| 2001:db0:1111:1f00::/52 | 192.32.17.17 | yyyyxxxxxxx1000x | 3840 |
| 2001:db8:2222:2f00:/52 | 192.16.34.34 | yyyyxxxxxxx0100x | 3840 |
| 2001:dbc:4444:4f00::/52 | 192.24.70.70 | yyyyxxxxxxx0010x | 3840 |
+-------------------------+--------------+------------------+-------+
Despres, et al. Expires February 20, 2012 [Page 16]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
7. 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.
8. IANA Considerations
For the 4rd stateless address mapping to possibly coexist with a
maximum of other IPv4/IPv6 address mappings, a 4rd-specific IID
prefix is desirable.
As explained in (Section 5.3), 200:5efe::/32 is a proposed value that
avoids ambiguity with other currently permitted IID values.
9. 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. He has also been the source of explanations on the CPE-
cascade use case. 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.
10. References
10.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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
Despres, et al. Expires February 20, 2012 [Page 17]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
10.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.murakami-softwire-4rd]
Murakami, T. and O. Troan, "IPv4 Residual Deployment on
IPv6 infrastructure - protocol specification",
draft-murakami-softwire-4rd-00 (work in progress),
July 2011.
[I-D.murakami-softwire-4v6-translation]
Murakami, T., Chen, G., Deng, H., Dec, W., and S.
Matsushima, "4via6 Stateless Translation",
draft-murakami-softwire-4v6-translation-00 (work in
progress), July 2011.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 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
Despres, et al. Expires February 20, 2012 [Page 18]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
(ISATAP)", RFC 4214, October 2005.
[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.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 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: jacniq@gmail.com
Despres, et al. Expires February 20, 2012 [Page 19]
Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011
Simon Perreault
Viagenie
2875 Laurier, suite D2-630
Quebec
Canada
Email: simon.perreault@viagenie.ca
Xiaohong Deng
France Telecom
Hai dian district, 100190
Beijingc
China
Email: xiaohong.deng@orange-ftgroup.com
Despres, et al. Expires February 20, 2012 [Page 20]