Internet Engineering Task Force R. Despres
Internet-Draft November 3, 2008
Intended status: Standards Track
Expires: May 7, 2009
Stateless Address Mappings (SAMs)
IPv6 & extended IPv4 via local routing domains - possibly multihomed
draft-despres-sam-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009.
Abstract
Stateless Address Mapping (SAM) is a generic technique to achieve
global IPv4 or IPv6 connectivity across local domains where routing
is in a different address space. To cope with the IPv4 address
shortage, it supports an extension of IPv4 addresses with dynamic-
port prefixes. For multi-homed routing domains, it ensures that
source addresses that cross domain borders are always routable in the
reverse direction (Reverse Path Forwarding). SAM can be used alone
as an alternative to NATs, to improve scalability and end-to-end
network transparency, or in combination with NATs, to cover a wider
range of IPv4-IPv6 coexistence scenarios.
Despres Expires May 7, 2009 [Page 1]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Existing Internet address spaces . . . . . . . . . . . . . 3
2.2. IPv4 address shortage . . . . . . . . . . . . . . . . . . 3
2.3. Need for Multihomed routing domains . . . . . . . . . . . 4
2.4. Translation and Mapping approaches . . . . . . . . . . . . 4
3. SAM specification . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Interfaces of SAM local domains . . . . . . . . . . . . . 5
3.2. SAM Address Spaces . . . . . . . . . . . . . . . . . . . 6
3.2.1. Private address (v4P and v6P) . . . . . . . . . . . . 7
3.2.2. Non-extended global address spaces (v4G and v6G) . . . 7
3.2.3. Extended IPv4 global address space (v4E) . . . . . . . 7
3.2.4. Extended IPv6 global address space (v6E) . . . . . . . 8
3.3. The four parameters of a SAM (P, H, E, n) . . . . . . . . 9
3.4. Mapping rules . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Packet encapsulation-decapsulation . . . . . . . . . . 9
3.4.2. Address mappings . . . . . . . . . . . . . . . . . . . 10
3.5. Fragmentation support . . . . . . . . . . . . . . . . . . 11
3.6. On demand privacy protection . . . . . . . . . . . . . . . 12
4. Application examples . . . . . . . . . . . . . . . . . . . . . 13
4.1. Already deployed configurations . . . . . . . . . . . . . 13
4.1.1. IPv6 across a private IPv4 site (ISATAP=SAM(6G/4P)) . 13
4.1.2. IPv6 across an IPv4 ISP network (6rd=SAM(6G/4G)) . . . 14
4.2. New configurations . . . . . . . . . . . . . . . . . . . . 15
4.2.1. IPv4 and extended IPv4 across an IPv6 ISP network . . 15
4.2.2. IPv6 and extended IPv4 across a private IPv4
mobile operator . . . . . . . . . . . . . . . . . . . 16
4.2.3. Host controlled ISP selection in IPv6 dual-homed
sites . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.4. End-to-end IPv4 transparency across a home site . . . 18
5. Security considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Despres Expires May 7, 2009 [Page 2]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
1. Introduction
Stateless Address Mapping (SAM) is a generic technique to achieve
global IPv4 or IPv6 connectivity across local domains where routing
is in different address spaces.
The problem statement of Section 2 introduces the context that
justifies a SAM approach, and discusses why another approach than
NATs is worth standardizing.
Section 3 describes the the proposed specification. It is understood
that further work is needed to clarify and polish it, Tbut it is
expected to be complete enough to start experimenting it.
In designing SAM, high attention has paid to algorithmic simplicity
and to application generality. It can be viewed as a generalization
of [6rd], which itself is derived from the 6to4 of [RFC3056] and of
the ISATAP of [RFC5214]. It can also be viewed as an application of
a variant of the map and encap principle of [RFC1955], and of a
variant of the locator/identifier separation principle of [LISP].
2. Problem Statement
2.1. Existing Internet address spaces
Internet has two global address spaces, IPv4 and IPv6. A host in a
local routing domain that wants to send a packet to an arbitrarily
located remote host has to provide its global address.
Due to the lack of IPv4 addresses for all hosts, Internet uses also
extensively, in private networks and in some operator networks, IPv4
private addresses [RFC1918]. Network address translations (NATs) are
placed at borders between these networks and the global Internet.
Although the need to share global addresses is not pressing in IPv6
as it is in IPv4, considerations on ease of renumbering have lead to
have private addresses also in IPv6 (ULAs of [RFC4193]).
Standardized solutions are needed for global connectivity to be
maintained across routing domains that use private address spaces.
2.2. IPv4 address shortage
Because of a shortage of global IPv4 addresses is now unavoidable
before all hosts can support IPv6, global IPv4 addresses will have to
be shared among more and more hosts.
Despres Expires May 7, 2009 [Page 3]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
They are shared today among hosts of private sites by means of NATs
at site entrances, and between mobile phones by means of NATs
infrastructures of typical mobile phone operators. Some NATs are
even cascaded to increase the statistical efficiency of NAT address
sharing.
Assigning an exclusive global IPv4 address to a broadband residential
site becomes more and more a luxury, which will have to be charged
for. Ordinary customers will have to share more and more with others
global IPv4 address they need to communicate in IPv4. More and more
devices within ISP infrastructures will therefore have to manage this
sharing, one way or another.
2.3. Need for Multihomed routing domains
A routing domain is multihomed if it has several interfaces to the
global Internet, typically to different ISPs.
SHIM6 and SCTP are designed to take advantage of such a possibility,
in particular to maintain connectivity in case of single interface
failure, but a difficulty remains. Because of the reverse path
forwarding principle (RPF) of [RFC3704], hosts of multihomed domains
must influence which interface to the global Internet their outgoing
packets go through depending on which source address they use. SAMs
have to make this possible.
2.4. Translation and Mapping approaches
Where a global packet has to traverse a routing domain having a
different address space, two main possibilities exist:
1. A NAT translates the packet. Depending on conditions, the
translation may involve several consecutive packets, and may go
up to the application layer. It is not in general reversible
outside the NAT that did the translation.
2. A SAM derives a locally routable destination address from the
global destination address, and encapsulates the global packet to
forward it.
Advantages of NATs include the following:
o With the NAPT variant (which translate [address, port] couples
rather than just addresses), address are shared statistically so
that there use would in general more optimized than with static
sharing.
Despres Expires May 7, 2009 [Page 4]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
o Hosts attached to local routing domains don't need to be dual-
stack. They may ignore which is the global address family of
remote hosts they communicate with.
Expected advantages that justify SAM deployment include:
o Good scalability (no need to keep track of transport layer
connections)
o End-to-end network transparency: no need for application level
translation of addresses exchanged as data; compatibility with
transport protocols that use more sophisticated redundancy checks
than that of UDP and TCP.
o No DNS implication: global addresses are the only ones to be
advertised.
o Functional simplicity (stable specification, low development and
operational costs)
The purpose of this document is to propose a specification for the
SAM alternative.
3. SAM specification
3.1. Interfaces of SAM local domains
As illustrated in Figure 1, A SAM operates on a local domain which
has interfaces to one or several external domains, and to a number of
internal domains.
Despres Expires May 7, 2009 [Page 5]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
INTERNAL EXTERNAL
DOMAIN "i" DOMAIN "e"
| |
| interfaces interfaces |
| to internal to external |
| domain "i" domain "e" |
| | ______________________ | |
V V | | | |
___ | LOCAL DOMAIN | V V
___ | | | ___
same add. | | |an IPv4 and/or an IPv6| | ___
spaces as +----+ local address space | | |an IPv4 and/or an IPv6
external |_| | +----+ global address space
domains ___| | | |_|
| | |___
| global packets |
| encapsulated |
OTHER | in local packets | OTHER
INTERNAL ----+ +---- EXTERNAL
DOMAINS | | DOMAINS
|______________________|
INTERFACES AND ADDRESS SPACES OF SAM DOMAINS
Figure 1
The local domain may be an ISP network, or part of it, or a privately
owned network, also in whole or in part.
External domains are in direction of the global Internet, while
internal domains are in the direction of hosts that access the global
Internet via the local domain.
A local domain performs its local routing in IPv4, in IPv6, or in
both. In each of the two address families it may route in the global
address space or in a private address space.
A SAM local domain may support several SAMs. Each one maps a subset
of a global address space, to a local address space. In case of a
multihomed domain, there may be several mappings from the same global
address space.
3.2. SAM Address Spaces
SAMs see global addresses of internal hosts as composed of the global
prefix P of the local domain, followed by the local identifier L of
the internal domain of the host, followed by a suffix which can be
exploited within this internal domain.
Despres Expires May 7, 2009 [Page 6]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
3.2.1. Private address (v4P and v6P)
Local address spaces SAMs deal with are the following:
o Private IPv4 (v4P)
o Private IPv6 (v6P)
The v4P address space is that of [RFC1918]. (Addresses addresses
have one one of the following prefixes: 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/24.)
The v6P address space is that of [RFC4193]? (Addresses have the
fc00::/7 prefix).
3.2.2. Non-extended global address spaces (v4G and v6G)
Non-extended global address spaces SAMs deal with are the following:
o Non-extended global IPv4 (v4G)
o Non-extended global IPv6 (v6G)
The non extended global IPv4 address space it the total IPv4 address
space minus private addresses of v4P.
The non-extended global IPv6 address space it the total IPv6 address
space, minus addresses of v6P, and minus addresses that have in their
lower 64 bits an invalid IID. (A valid IID has, in its first octet,
either bit 6 is 0 (local significance of the 64-bit IID) or bits 6-7
are "10" (global significance of the 64-bit IID, with an individual
organization identifier in other bits of the first 3 octets in EUI-64
format).
3.2.3. Extended IPv4 global address space (v4E)
In the v4E address space, a subnetwork prefix or a host address is a
global IPv4 address extended by a port prefix.
In order to avoid interfering with specific interpretations of well
known and registered ports (0 to 49,151), only dynamic port numbers
are exploited for address extension (49,152 to 65,535).
A v4E prefix, always longer that 32 bits, never appears as such in a
field of a packet. It is only used to derive from it a local address
to be put in an encapsulating packet.
A v4E address can only be used with protocols that use port numbers.
Despres Expires May 7, 2009 [Page 7]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
This includes UDP, TCP, DCCP, SCTP, and ICMPv4 unreachability
messages in which headers of discarded packets are copied with heir
port numbers.
Figure 2 illustrates the format of a v4E address, as it is seen in a
local domain of prefix P, in the case where the local identifier L
spans the address-port boundary. In this case, L has three parts: La
and Lb are the useful parts of L to construct the internal domain
locator, and bits 0-1 of the port prefix are constant.
port
shared IPv4 address prefix suffix
<-------------32 --------------><-----><------>
+--------------------------.----+-+---.---------+
| P | L |1|L | |
| | a |1|b | |
+--------------------------'----+-+---'---------+
<-- domain global prefix --><- locID ->
V4E ADDRESS FORMAT
Figure 2
Note: the fact that a host having a v4E address may only use some
dynamic ports for its incoming connections is not new. Using an SRV
record to advertise a dynamic port in the DNS already used in Apple's
technology [Bonjour].
3.2.4. Extended IPv6 global address space (v6E)
An extended IPv6 address format may also be used by SAMs to extend
subnet addressing beyond 64 bits. Thus, a private site that has only
a /64 (typical for some mobile phones, considered as as independent
sites) can thus support several subnets.
The 9th octet is reserved for a v6E tag. Its bits 4-7 are 0xF. This
value differs from any value found in v6G addresses. (Bits 6-7 are
"00, "01"" or "10" in standard 64-bit IIDs, as detailed in
Section 3.2.2). Bits 0 is used for the privacy option of
Section 3.6. Other bits are reserved for extensions, of SAMs or
others.
Figure 3 illustrates the format of a v6E address, as it is seen in a
local domain of prefix P, in the case where the local identifier L
spans the 64-IID boundary. In this case, L has three parts: La and
Lb are the useful parts of L to construct the internal domain
locator, and the .
Despres Expires May 7, 2009 [Page 8]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
<-------------64 --------------><-8-><------------56 ----------->
+-------------------------.-----+---+------.--------------------+
| P | La |Tag| Lb | suffix |
+-------------------------'-----+---+------'--------------------+
<-- domain global prefix -><--- local ID -->
<----------- v4E host address ---------------------------------->
V6E ADDRESS FORMAT
Figure 3
3.3. The four parameters of a SAM (P, H, E, n)
Each SAM is defined by 4 parameters, P, H, E, and n, where :
o "P" is, in the local-domain global prefix. It is the prefix that,
in the global address space, identifies the local domain.
o "H" is the header that is at the beginning of all internal-domain
local prefixes.
o "E" is the local anycast address that, in the local domain, is
routed toward interfaces to the SAM external domain.
o "n" is the length of local identifiers in the local domain. (The
number of possible internal domains is 2 ^ n).
The global address space of a SAM is v4E if E is IPv4 and if p + n
exceeds 32, where p is the length of P.
These parameters must at least be administratively configurable. It
should also be possible to configure SAM parameters of internal
interfaces automatically, e.g. with ad hoc DHCP and DHCPv6 options.
Specifying such options is beyond the scope of this document but is
easy.
3.4. Mapping rules
3.4.1. Packet encapsulation-decapsulation
Mapping a global packet into a local packet, at its entry to a local
domain, is done in the following steps:
1. If the packet is a fragment of an incomplete packet, proceed as
indicated in Section 3.5, and proceed.
2. Check that the source global address is realistic at this
interface (is not obviously spoofed).
Despres Expires May 7, 2009 [Page 9]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
3. Find which SAM applies, if any. For this, find the SAM the
global prefix P of which matches the internal host address.
4. Derive local source and destination addresses from source and
destination global addresses according to Section 3.4.2.
5. Encapsulate the global packet into a local packet having the
source and destination derived addresses, and having the protocol
field set to 41.
Extracting the global packet contained in a local packet having
protocol 41 is done in the following steps:
1. Check that the source address is realistic at this interface (is
not obviously spoofed)
2. Check that source and destination addresses of the local packet
are, according to Section 3.4.2, those that are derived from
source an destination addresses of the encapsulated packet, and
that the source address is realistic at this interface (is not
obviously spoofed).
3.4.2. Address mappings
The local address mapped from the global address of an external host
is the local anycast address E of the SAM .
The local address derived from the global address of an internal host
is obtained as follows:
1. Obtain the "local identifier" L of the local domain in p to p+n
of the global address).
2. If L contains a constant field of the global address, delete it.
3. Add the header H in front of it.
4. If the local address space is IPv6, add to the the just obtained
prefix zeroes up to 120 bits, and insert the 8-bit v6E tag.
5. Else, i.e. if the local address space is IPv4, the header H is
normally chosen such that the just obtained prefix has 32 bits.
If it has been found useful to have it shorter, complete to 32
bits with zeroes.
Figure 4 illustrates a particular case case where constant fields
have to be both deleted and added (a v4E global address mapped to an
IPv6 local address).
Despres Expires May 7, 2009 [Page 10]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
<--------------- 32 -----------><- 6 ->
<2>
+-------------------------------+-+----.--------+ v4E
| P |3| Lb | |address
+-------------------------------+-+----'--------+
| | |
|/ /
<----------------- 64 ------------> |
----//-----------------------------+----+
| H | Lb |
+----//----------------------------+----+
| |\ \
| | \ \
| | \ \
| | \ \
| | \ \
| | \ \
| | \ \
| | \ \
| | | |
+----//----------------------------+--------+----.----//----+
| H | 0f | Lb | 0 |
+----//----------------------------+--------+----.----//----+
<-- 8 -->< 4 >
<----------------------- 128 ------------------------------->
AN EXAMPLE OF V4E GLOBAL PREFIX TO LOCAL ADDRESS MAPPING
Figure 4
3.5. Fragmentation support
Fragmentation is needed when a datagram is too long to fit in the
maximum path transmission unit between source and destination hosts
(PMTU). TCP has evolved to avoid using fragmentation, but some UDP
based applications do use it.
Since SAMs encapsulate global packets, including all fragmentation
related information they may contain, destination hosts have all they
need to reassemble fragmented datagrams.
Within local domains, precautions must be taken so that no
fragmentation of encapsulating packets is needed. (An IPv6 packet of
1280 octets encapsulated with an IPv6 IP header of 40 octets fits
largely in generally supported packet sizes.) At its interfaces, a
local domain is assumed to discard incoming packets that exceed its
supported MTU (and return error ICMP messages to sources).
Despres Expires May 7, 2009 [Page 11]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
If global packets are v4G or v6G, address mappings are only based on
addresses. They can therefore be performed packet per packet.
If global packets are v4E, a mechanism is needed to forward packets
of fragmented datagrams. Since port numbers appear only in the first
fragment, the SAM has to record it for reuse when subsequent packets
of the same datagram will have to be mapped. These packets being
identified by the source address SA and the identification field IF
of the IPv4 datagram, a table entry is needed to match the port
prefix PP to the [SA, IF]. The entry is created when the first
fragment is processed. It is discarded when the last fragment
(having the "more fragments" bit = 0) is processed or, for to deal
with last fragment losses, after a timeout expires since the last
fragment reception.
This mechanism works only if fragments of a same datagram enter a
local domain at its same interface, and in their original order.
Changing from one interface to another in the middle of a fragmented
datagram is acceptable only if it is infrequent, e.g. when routing
information bases need to be changed. (If upstream routing would
alternate among several interfaces on a per packet basis, the effect
would normally be unacceptable but, this problem not being exclusive
of SAMs, routing may be assumed to be stable enough in real
networks.)
3.6. On demand privacy protection
IPv6 end-to-end (i.e. without NAT traversal) is the only way to
restore both global reachability, at stable address and ports without
port restrictions, and the end to end packet preservation which is
needed for transport protocols that apply a stronger checksum
algorithm than the 16-bit one's complement of UDP and TCP (e.g.
SCTP).
On the other hand, NATs are known to provide some privacy protection
because individual hosts behind NATs cannot be identified from the
outside and because, behind NATs, private routing topologies are
hidden. There are consequently some advocates for the deployment of
IPv6 to IPv6 NAT to be endorsed by IETF (NAT66s). Without strong
caveats, and restrictions on what these NAT66s would do, this could
break confidence in IPV6 end-to-end capabilities, and encourage a
longer use of IPv4, with its NATs and NAT cascades.
It is therefore proposed to limit address and port translations to
outgoing connections of internal hosts that use privacy addresses.
Thus, users that consciously request privacy are informed that they
implicitly accept some service limitations, which other users don't
want to accept, and that the same users may not wish to accept at
Despres Expires May 7, 2009 [Page 12]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
different times (then using other local addresses).
In v6G addresses, a privacy demand is already coded as bit 6 of the
9th octet set to 0. In v6E addresses, the proposed coding for
privacy demands is in the v6E tag (Section 3.2.4), with bit 0 set to
1.
When a SAM has to forward an IPv6 global packet to an external domain
with an IPv6 source expressing a privacy demand, it scrambles, in an
arbitrary way provided it is reversible, bits of the internal host
address that follow the global prefix P, and bits 2-15 of the
internal port if it is a dynamic port (thus performing a locally
known 1:1 mapping). The reverse mapping is performed in packets
destined to internal hosts that have privacy requirement in their
address.
The freedom to choose any reversible scrambling algorithm should make
it difficult to discover it from the outside.
4. Application examples
The following sections describe a number of SAM application cases.
A SAM that maps a global address space vXX to a local address space
vYY is noted SAM(XX/YY). For example, the SAM(6G/4P) of the first
example encapsulates global IPv6 packets into private IPV4 packets.
In figures, double arrows "==>" represent routes for prefixes, and
single arrows "-->" represent routes for full length addresses. An
IPv4 prefix is distinguished from an IPv6 prefix with ".." instead of
"::" before the /k which indicates its lengths. The concatenation
operator is the dot ".".
4.1. Already deployed configurations
4.1.1. IPv6 across a private IPv4 site (ISATAP=SAM(6G/4P))
Figure 5 shows SAM parameters for a particular case where global IPv6
connectivity is offered, to dual-stack hosts, across a private site
where routing is private IPv4 only (a particular application of
ISATAP).
The SAM global address prefix P is made of the IPv6 prefix assigned
by the ISP to the private site, followed by the ISATAP IID prefix 00:
00:5efe::/32.
Interfaces of the private site to IPv4 and IPv6 ISPs are shown
Despres Expires May 7, 2009 [Page 13]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
separate, but can be merged if the IPv4 ISP also offers IPv6 on its
interfaces (native or with some encapsulation, e.g. that of [6rd]).
dual-stack hosts private IPv4 site IPv4 ISP
______________________ ________
| V4P ROUTING | |
| 0../0 | | P4G/32
________ | ==> +--+ <==
P4G.X/32 | | | |
P6G.P4G.X::/60 | x | P4G.X/32 | |________
<== SAM +---+ <-- | ________
| | | |
________| | E/32 | | P6G::/48
| --> SAM +--+ <==
| | |
|______________________| |________
IPv6 ISP
IPv6 ACROSS A PRIVATE IPV4 SITE (ISATAP)
SAM(P=P6G.(00:00:5efe)::/96, H=0../0, E, n=32)
Figure 5
4.1.2. IPv6 across an IPv4 ISP network (6rd=SAM(6G/4G))
Figure 6 shows SAM parameters for a particular case where global IPv6
connectivity, across a global IPv4 ISP network, to customer sites
where the CPE is dual stack and supports [6rd].
In this example, the ISP uses one IPv6 prefix, but several IPv4
prefixes (two in the particular case), as typical for an ISP that has
progressively increased the number of customers to be supported.
Having a /28 IPv6 prefix, it assigns /60 prefixes to its customer
sites.
Despres Expires May 7, 2009 [Page 14]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
dual-stack CPEs global IPv4 ISP IPv4 Internet
______________________ ________
| V4G ROUTING | | P4Ga../12
| 0../0 | | P4Gb../14
________ | ==> +--+ <==
P4Gi.X/32 | | | |
P6G.P4Gi.X::/60 | x | P4Gi.X/32 | |________
<== SAM +---+ <-- | ________
| | | |
________| | E/32 | | P6G::/28
| --> SAM +--+ <==
| | |
|______________________| |________
IPv6 Internet
IPv6 ACROSS AN IPV4 ISP NETWORK (6RD)
SAM(P=P6G::, H=0../0, E, n=32)
Figure 6
4.2. New configurations
4.2.1. IPv4 and extended IPv4 across an IPv6 ISP network
This example concerns an ISP that desires to route only IPv6 in its
core infrastructure, and that has to provide IPv4 connectivity to its
dual-stack customer sites. In view of the IPv4 address shortage, it
wishes to distinguish two types of customer sites: a privileged
customer site is assigned one IPv4 global address; an ordinary
customer is only assigned a port-restricted IPv4 global address.
This objective is almost that of [IVI] with its envisaged future
support of port multiplexing.
A difference between IVI and SAM objectives is that SAM implies, for
this configuration, that CPEs that need IPv4 connectivity be dual
stack with SAM support. On the other hand, [IVI] supports CPEs that
are IPv6 only and that, despite this, need IPv4 connectivity
(accepting as a counterpart a lack of end-to-end transparency).
Whether enough customer demand will justify standard solutions for
hosts that have IPv6-only stacks, and/or IPv6-only applications, and
that need to reach IPv4 only servers is still an open question.
Conversely, while the only IPv4 connectivity of IVI is degraded by
IPv6-IPv4 translation, which in particular makes it incompatible with
SCTP [RFC3286], SAM provides end-to-end IPv4 transparency (accepting
as a counterpart that CPEs work with restricted port ranges).
Studies on implications of restricted port ranges are ongoing (see in
Despres Expires May 7, 2009 [Page 15]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
particular [Boucadair]).
Figure 7 shows an example of ISP network configuration to satisfy the
above requirement. It uses two SAMs, respectively for privileged and
for ordinary customer sites.
dual-stack CPEs global IPv6 ISP IPv6 Internet
______________________ ________
2^20 IPv6 /48 sites | V6G ROUTING | |
1 IPv4 /32 per site | 0::/0 | | P6::/24
________ | ==> +--+ <==
P6.(0/4).X::/48 | | | |
P4.(0/1).X/32 | x | P6.(0/4).X::/48 | |________
<== SAM +---+ <== |
________| | |
________ | |
P4Gi.X/32 | | | IPv4 Internet
P6G.P4Gi.X::/60 | y | P6.(1/1).Y::/48 | ________
<== SAM +---+ <== | |
________| | | |
2^23 IPv6 /60 sites | E/128 | | P4../12
2^11 IPv4 ports/site| --> SAM1 & SAM2 +--+ <==
|______________________| |________
IPv4 AND EXTENDED IPV4 ACROSS AN IPV6 ISP NETWORK
SAM1(P=P4.(0/1).., H=P6.(0/4)::, E/128, n=20)
SAM2(P=P4.(1/1).., H=P6.(1/1)::, E/128, n=25)
Figure 7
4.2.2. IPv6 and extended IPv4 across a private IPv4 mobile operator
This example concerns an ISP that uses private IPv4 as address space
of its routing infrastructure and has to provide both IPv6 and
extended global IPv4 connectivities to its hosts.
Figure 8 shows an example of ISP network configuration that satisfies
this objective. It uses two SAMs, respectively for IPv6 and port
restricted IPv4 addresses in mobile phones.
Despres Expires May 7, 2009 [Page 16]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
dual-stack private-IPv4 phone operator IPv6 Internet
phones ______________________ ________
| V4P ROUTING | |
| | |
| 0../0 | | P4a../16
________ | ==> NAT +--+ <==
P4.Xa.(3/2).Xb/38| | | |
P6.Xa.Xb/52 | | P6.(0/4).X::/48 | |
<== SAM1 & SAM2 +---+ <== | |
________| | |
| E1 | | P4b../16
2^19 IPv6 /52 sites | --> SAM2 +--+ <==
2^10 IPv4 ports/site | | |________
| |
| |
| | IPv4 Internet
| | ________
| | |
| | |
| E2 | | P6::/32
| --> SAM2 +--+ <==
| | |
|______________________| |________
IPv4 AND EXTENDED IPV4 ACROSS AN PRIVATE IPV4 MOBILE OPERATOR
SAM1(P=P4.(0/1).., H=P6.(0/4)::, E/128, n=20)
SAM2(P=P4.(1/1).., H=P6.(1/1)::, E/128, n=25)
Figure 8
4.2.3. Host controlled ISP selection in IPv6 dual-homed sites
This example concerns a private site that has two IPv6 ISP
interfaces, and where an internal host must be able to select which
outgoing ISP is used, for its outgoing packets, depending on the
source address it has chosen.
Figure 9 shows an example of private network configuration that
satisfies this objective. For dual-homing, it uses one SAM(V6G/v6P).
It could use one or several other SAMs for global IPv4 connectivity,
but this is ignored in the example.
The SAM in dual-stack hosts, because of its parameters, encapsulates
packets that have the secondary IPv6 source address, that which
starts with the site prefix assigned by the secondary ISP. If
destined to a host outside the private site, its local destination
address being that of the SAM, the packet leaves the private site via
the ISP that has a return route for the chosen source address. This
Despres Expires May 7, 2009 [Page 17]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
is the desired result.
Local routing is, in this example, done in the global IPv6 address
space of the main ISP. This choice preserves compatibility with
hosts that are not SAM-capable dual-stack hosts. They work as though
the site would be single-homed.
Note : another possible choice would have been to use a private IPv6
address space for local routing. This choice has the advantage of
suppressing the need to change it if the main ISP changes, or
replaces the site prefix by another, but implies that all hosts are
dual-stack with SAM support.
dual-stack CPEs private IPv4 site ISPa (main)
______________________ ________
| V6G ROUTING | |
| 0../0 | | P6a::/48
________ | ==> +--+ <==
P6a.(0/12).X/60 | | | |
P6b.X/60 | x | P6a.(0/12).X/60 | |________
<== SAM +---+ <-- |
________| | | ISPb (secondary)
| | ________
| | |
| E/32 | | P6b::/60
| --> SAM +--+ <==
| | |
|______________________| |________
IPv6 Internet
IPv6 DUAL HOMING SITE WITH HOST CONTROLLED ISP SELECTION
SAM(P=P6b::, H=P6a.(0/12)::, E, n=32)
Figure 9
4.2.4. End-to-end IPv4 transparency across a home site
The example of Figure 10 concerns a home site that has a IPv4 global
address, ad that routes locally in private IPV4. For outgoing
connections, some hosts need end-to-end transparency.
To satisfy this requirement, dynamic ports are split into two
subsets, one for the NAT and one for the SAM. In the example, the
upper half (prefix 7/3) is assigned to the SAM. Then, SAM ports are
further split into all permitted hosts. In the example, 13 hosts are
supported, each one having 512 dynamic ports for its use. (13 = 2^4
minus three reserved values all 0s, all 1s, and E).
Despres Expires May 7, 2009 [Page 18]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
dual-stack hosts residential site IPv4 ISP
______________________ ________
| V4P ROUTING | |
13 hosts | | |
512 ports per host | 0../0 ==> NAT | | A4
________ | E/32 ==> SAM +--+ <--
H.X/32 | | | |
P.(7/3).X/39| x | H.X/32 | |
<== SAM +---+ <-- | |
________| | | |
|______________________| |________
END-TO-END TRANSPARENCY ACROSS A HOME SITE
SAM(P=A4.(7/3)../39, H=192.168.0.0/28, E, n=7)
Figure 10
5. Security considerations
Provided consistency checks between local addresses (in encapsulating
packets) and global addresses (in encapsulated packets) are
systematically done, possibilities global address spoofing is
possible, but not more and not less than local addresses spoofing.
As long as SAMs are correctly configured, no other security risk due
to SAM operation has been identified.
6. IANA Considerations
TBD
7. Acknowledgements
8. References
8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
Despres Expires May 7, 2009 [Page 19]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
8.2. Informative References
[6rd] Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd)" - Work in progress
(draft-despres-6rd-02)", October 2008.
[Bonjour] S. Cheshire et al, "Requirements for a Protocol to Replace
AppleTalk NBP - Work in progress
(draft-cheshire-dnsext-nbp-05)", October 2008.
[Boucadair]
M. Boucadair et al, "Provider-Provisioned CPE: IPv4
Connectivity Access in the context of
IPv4 address exhaustion - Work in progress
(draft-boucadair-port-range-00)", October 2008.
[IVI] Xing Li et al, "Prefix-specific and Stateless Address
Mapping (IVI) for IPv4/IPv6 - Work in progress
(draft-xli-behave-ivi-00)", July 2008.
[LISP] D. Farinacci et al, "Locator/ID Separation Protocol (LISP)
- Work in progress (draft-farinacci-lisp-09)",
October 2008.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC3286] Ong, L. and J. Yoakum, "An Introduction to the Stream
Control Transmission Protocol (SCTP)", RFC 3286, May 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
Despres Expires May 7, 2009 [Page 20]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
March 2008.
Author's Address
Remi Despres
3 rue du President Wilson
Levallois,
France
Email: remi.despres@free.fr
Despres Expires May 7, 2009 [Page 21]
Internet-Draft Stateless Address Mappings (SAMs) November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Despres Expires May 7, 2009 [Page 22]