Internet Engineering Task Force R. Despres
Internet-Draft RD-IPtech
Intended status: Experimental March 1, 2010
Expires: September 2, 2010
Stateless Address Mapping (SAM) for Softwire-Lite Solutions
draft-despres-softwire-sam-00
Abstract
Stateless Address Mapping (SAM) is a generic mechanism which permits,
in a number of new scenarios, to easily establish tunnels for packets
of some address family to traverse domains where this family is not
directly routed (softwires). It generalizes address mapping
principles of already deployed technologies such as 6to4, ISATAP, and
6rd, where encapsulations of IP over IP are used for point-to-
multipoint tunnels (mesh softwires).
Identified use cases of SAM include native IPv6 across IPv4 NATs,
IPv6 multihoming with provider-aggregatable prefixes, public IPv4
across IPv6-only domains and, to mitigate consequences of the IPv4
address shortage, extended IPv4 prefixes for statically shared IPv4
public addresses.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 2, 2010.
Despres Expires September 2, 2010 [Page 1]
Internet-Draft Stateless Address Mapping (SAM) March 2010
Copyright Notice
Copyright (c) 2010 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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The SAM model . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Stateless Address Mappers (SAMs) . . . . . . . . . . . . . 3
2.2. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Mapping Functions . . . . . . . . . . . . . . . . . . . . 7
2.4. Encapsulations and Decapsulations . . . . . . . . . . . . 9
2.5. Fragmentation Considerations . . . . . . . . . . . . . . . 9
2.6. Extended IPv4 Prefixes and their Port Sets . . . . . . . . 10
2.7. Acquisition of Mapping Rules by Customer Nodes . . . . . . 12
3. Use-Case examples . . . . . . . . . . . . . . . . . . . . . . 15
3.1. IPv6 across IPv4-only Domains . . . . . . . . . . . . . . 15
3.1.1. Native IPv6 across NAT44 CPEs (6rdE) . . . . . . . . . 15
3.1.2. Optimized Mapping for Multiple IPv4 Prefixes . . . . . 18
3.2. IPv4 across IPv6-only Domains . . . . . . . . . . . . . . 20
3.2.1. Single IPv4 Prefix . . . . . . . . . . . . . . . . . . 20
3.2.2. Multiple IPv4 Prefixes . . . . . . . . . . . . . . . . 21
3.3. Public IPv6 across Private-IPv6 Domains . . . . . . . . . 22
3.3.1. Multihoming with Provider-Aggregetable Prefixes . . . 22
3.3.2. Renumbering with Unchanged Internal Routing . . . . . 24
3.3.3. Merging Two Private-Addressing Sites using ULAs . . . 25
3.4. A Planned Experiment at Telecom Bretagne . . . . . . . . . 27
4. Security considerations . . . . . . . . . . . . . . . . . . . 30
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Despres Expires September 2, 2010 [Page 2]
Internet-Draft Stateless Address Mapping (SAM) March 2010
1. Introduction
Stateless Address Mapping (SAM) is a generalization of address-
mapping and encapsulation mechanisms used in deployed technologies
such as 6to4 [RFC3056], 6rd [RFC5569] [Standard-track 6rd], and
ISATAP [RFC5214]. Like these, it establishes point-to-multipoint
tunnels (mesh softwires of [RFC4925]). Like these also, but unlike
mesh softwire mechanisms of [RFC5565], it establishes them without
needing a common routing protocol between border nodes of traversed
domains. to keep justifies to call it a "softwire lite" solution.
Another characteristic of SAM that keeps it simple is that traversed
domains are treated as virtual links like those of 6to4, i.e. as
links on which neither link-local addresses nor any link-layer
protocol are needed.
A detailed specification of SAM is proposed in Section 2, after what
a number of typical use cases are described in Section 3. Security
considerations are covered Section 4.
Section 3.1 on IPv6 across IPv4-only domains, Section 3.2 on public
IPv4 across IPv6-only domains, and Section 3.3 on public IPv6 across
private-IPv6 domains, can be read in any order, and it is unnecessary
to have read Section 2.7 on how mapping rules can be acquired by
customer nodes to understand them.
Readers not interested in IPv4 address-plus-port locators, a subject
considered so far as controversial, can just skip Section 2.6 and
ignore, in the experimental scenario of Section 3.4, what concerns
them.
2. The SAM model
2.1. Stateless Address Mappers (SAMs)
Figure 1 summarizes the essentials of SAM, with an illustration of
the terminology used in the upper part, with below mapping-rule
parameters listed in Section 2.2, and at the end a synthetic
representation of mapping functions detailed in Section 2.3
A "SAM domain", is a routing domain in which border nodes (hosts or
routers) contain "stateless address mappers" (SAMs). Some of them
are "customer SAMs" (C-SAMs) and some of them, optional, are
"provider SAMs" (P-SAMs). Each SAM, being stateless, can be
physically replicated if necessary to support heavy traffic loads.
In this case, they share the same prefixes and locators. Addresses
to reach them are configured in routers as anycast addresses.
Despres Expires September 2, 2010 [Page 3]
Internet-Draft Stateless Address Mapping (SAM) March 2010
customer customer provider domain domain
exterior interior interior interior exterior
prefix E prefix I locator G prefix K prefix D
|______ |___ | | __________|
| | | | |
| | | | +---|------------------
exterior | +---|-----|------------|-+ | exterior
endpoint locator | | | | | | | endpoint locator
(customer-side) | | | | K <====: | (provider side)
| | | | |__________ | | |
--|-------------|--+ | | P-SAM | |
| | | | G ---->S<==== D ---->
| | | | provider SAM eLOC (not D...)
| |C-SAM | |
<---- I <====S<==== I=P.X |
eLOC=E... E <====S |
E=R.X | |
customer SAM |
| |
CUSTOMER DOMAIN | SAM DOMAIN |
-------------------+ (iSRC ----> iDST) | PROVIDER DOMAIN
+------------------------+
(in a border node) +----------------------
(in a border node)
MAPPING RULE(S): {R; P; x[; G][; T]}, where:
R = rule exterior prefix = D[.C]
P = rule interior prefix = K[.H]
C = domain-exterior-prefix code (optional)
H = domain-exterior-prefix code (optional)
X = customer index (length x)
T = lifetime (optional)
MAPPING FUNCTIONS:
E( I=P... , {R; P; x}) = R.(I-P)/r+x
iDST(eDST=R... , any eSRC,{R; P; x}) = P.(eDST - R).0*/p...
iDST(eDST not R... , eSRC = R... ,{R; ... ; G}) = G
THE SAM MODEL
Figure 1
Each SAM has an "interior interface" and an "exterior interface". At
the interior interface, it is addressed in the SAM interior locator
family of the domain. At the exterior interface, it can be addressed
in several locator families. These locator families can be IPv4,
IPv6 or, for some scenarios of the IPv4-IPv6 coexistence period
Despres Expires September 2, 2010 [Page 4]
Internet-Draft Stateless Address Mapping (SAM) March 2010
during which there is an IPv4 address shortage, extended IPv4
(IPv4E). An IPv4E locator is port-extended, i.e. composed of a
public IPv4 address plus a transport layer port number.
a SAM domain may contain any number of interior nodes, which forward
packets whose locators are in the interior locator family.
Each provider SAM is assigned, at its interior interface, a "provider
interior locator" (G). At its exterior interface, the P-SAM is
assigned one or several "domain exterior prefixes" (D).
Each customer SAM is assigned, at its interior interface, an interior
prefix called its "customer interior prefix" (I). At its interior
interface, it assigns to the customer domain behind this interface
one or several "customer exterior prefixes" (E).
Customer interior and exterior prefixes I and E have a common part,
in their lower bits, called the "customer index" (X). What precedes
X in a customer exterior prefix E is called "rule exterior prefix"
(R), and what may precede X in a customer interior prefix I is called
"rule interior prefix" (P).
In SAM, prefixes are not only address prefixes (IPv4 or IPv6, public
or private), but more generally locator prefixes, including port-
extended prefixes. Their lengths are not restricted to be shorter
than that of locators of their families so that a prefix parameter
can contain a full address or address plus port.
We use throughout the following notation:
o The dot is the a concatenation operator for prefixes, and the
minus sign is the extraction operator, so that we can write E =
R.X, I = P.X, also noted X = E - R = I - P.
o A locator that matches a prefix Z is noted Z... .
o The length of a prefix whose symbol is an upper-case letter is
noted with the same letter in lower case (d is the length of D, x
that of X).
o The length of a locator Z... is noted z... (e... = 128 if the
locator family of E is IPv6, and e... = 48 if this family is
IPv4E.)
Despres Expires September 2, 2010 [Page 5]
Internet-Draft Stateless Address Mapping (SAM) March 2010
A customer exterior prefix E assigned by a customer SAM to its
customer domain must belong to the locator space of the SAM domain.
It must therefore be an extension of one of the domain exterior
prefixes D. For this, each rule exterior prefix R must start with one
of the domain exterior prefixes D.
In a SAM domain a common part at the beginning of a number interior
locator can be identified. It is then called "domain interior
prefix" (K) of the domain. If interior locators are not constrained
to start with any specified prefix, there is only one K whose length
is 0. If there are several Ks, it must be possible to unambiguously
determine which one is at the beginning of any interior locator.
These Ks must therefore be non-overlapping prefixes. Customer
interior prefixes I assigned in a SAM domain to customer SAMs having
to be extensions of these Ks, each rule interior prefix P must start
with one of them.
If a rule exterior prefix R is longer than its contained domain
exterior prefix D, the remainder is a "domain-interior-prefix code"
(C), i.e. R = D.C, or C = R - D. When present, this code C
identifies one of the domain interior prefixes K.
If a rule interior prefix P is longer than its contained domain
interior prefix K, the remainder is a "domain-exterior-prefix code"
(H), i.e. P = K.H, or H = P - K. When present, this code H
identifies one of the domain exterior prefixes D.
2.2. Mapping Rules
To forward an exterior packet across a SAM domain a SAM derives an
interior destination locator iDST from the destination and source
locators eDST and eSRC of the exterior packet. For this, it applies
a "locator mapping function" which depends on the set of "mapping
rules" of the SAM domain: iDST = iDST(eDST, eSRC, mapping rules).
To assign customer exterior prefixes E to its customer domain,
customer SAMs apply to their prefixes I a "prefix mapping function"
which depends on the set of mapping rules of the SAM domain: E = E(I,
mapping rules).
Despres Expires September 2, 2010 [Page 6]
Internet-Draft Stateless Address Mapping (SAM) March 2010
Parameters of mapping rules are the following:
R: The "rule exterior prefix". Its family (IPv4, IPv6 or IPv4E)
determines that of exterior prefixes E that start with it, and
that of exterior endpoint locators eDST and eSRC.
P: The "rule interior prefix". Its family (IPv4, IPv6 or IPv4E)
determines that of interior prefixes I that start with it, and
that of interior locators iDST and iSRC. The length p of this
prefix may be 0.
x: The "customer-index length". It is the length of the field X that
is common to customer interior and exterior prefixes I and E. It
determines the lengths of customer interior and exterior prefixes
(i = p + x, and e = r + x).
G: The "provider interior prefix" (optional). It specifies a P-SAM
that has been assigned the domain exterior prefix D that appears
at the beginning of the customer exterior prefix R of the rule.
If G is present but has length g = 0, it means that the interior
interface of this P-SAM is the default exit from the SAM domain (a
SAM use cases where this is used is not present in this draft but
may be included in a later version). If G is absent, the rule
applies only to packets whose source and destination exterior
locators eSRC and eDST both start with the rule-exterior-prefix R
of the rule (eDST = R... and eSRC = R...).
T: The "rule lifetime" (optional). Its absence means an unbounded
lifetime. If a SAM sees that the lifetime of a rule has expired
since the rule was received, no mapping using it is permitted any
longer. The rule should then be discarded. If present, the
lifetime is expressed in seconds.
A mapping rule is represented between curly brackets, with its
parameters in the order R, P, x, G, T, as shown in Section 2 with
square brackets to indicate what is optional.
2.3. Mapping Functions
Ignoring for the time being security checks, which are discussed in
Section 4, prefix mapping functions are detailed in Figure 2, with
the following pseudo-code notation:
o As above, the dot is the concatenation operator and the minus sign
is the extraction operator: "(A.B)-D" means that A and B are
concatenated and that D, which must be present at the beginning of
the result, is extracted from it to give the final result.
Despres Expires September 2, 2010 [Page 7]
Internet-Draft Stateless Address Mapping (SAM) March 2010
o The slash notation indicates how many bits are retained in
concatenation results. "A.B/(c+d" means that A and B are
concatenated and that only the first c + d bits are retained.)
o 0* represents a filler composed of a number of 0 bits which are
appended to reach the specified total length. Its length may be
0.
CUSTOMER-SAM PREFIX MAPPING
E(I, mapping rules):
FOR each rule {R; P; x[; G][; T]} such that I=P..., DO:
Take, as valid E, E = R.(I-P)/r+x, with lifetime T
CUSTOMER-SAM DESTINATION-LOCATOR MAPPING
iDST(eDST, eSRC, mapping rules):
Take rules {R; P; x[; G][; T]} such that eDST=R...
Select among them those that have the maximum R length
Select among them one that has the maximum T (or no T)
IF there is such a rule and eSRC=R..., DO:
iDST = P.(eDST-R).0*/p...
ELSE DO:
Take rules {R; P; x[; G][; T]} such that eSRC=R... :
Select among them those that have a G
Select among them one that has the maximum T (or no T)
IF there is such a rule, DO:
iDST = G
ELSE: Return a "Destination unreachable" error message
PROVIDER- SAM DESTINATION LOCATOR MAPPING:
- iDST(eDST, eSRC, mapping rules):
Take rules {R; P; x[; G][; T]} such that eDST=R...
Select among them those that have the maximum R length
Select among them one that has the maximum T (or no T)
IF there is such a rule and eSRC=R...,, DO:
iDST = P.(eDST-R).0*/p...
ELSE: Return a "Destination unreachable" error message
SAM MAPPING FUNCTIONS
Figure 2
Despres Expires September 2, 2010 [Page 8]
Internet-Draft Stateless Address Mapping (SAM) March 2010
2.4. Encapsulations and Decapsulations
To traverse SAM domains with end-to-end network transparency,
exterior packets are encapsulated in interior packets. Destination
locators iDST of these interior packets are those obtained by the
mapping functions of Section 2.3. The source locators iSRC is in a
customer SAM its interior prefix I, completed if necessary by a
filler of 0s. In a provider SAM, it is its provider interior locator
G
If the interior locator family is IPv4 or IPv6, encapsulation is in
IP over IP, with the protocol/next-header field of the encapsulating
packet set to 41 (an extension of what this value means for 6to4,
ISATAP and 6rd).
If the interior locator family is IPv4E, encapsulation is in IP over
UDP over IP. UDP ports are the last 16 bits of 48-bit interior
locators of the IPv4E family.
At tunnel exit, interior packets from which exterior packets have to
be extracted are recognized by their protocol/next-header field = 41,
if the interior locator family is IPv4 or IPv6, and by their UDP
destination port being that assigned to encapsulation if this family
is IPv4E.
ICMP/ICMPv6 error messages of the interior locator family that are
received at tunnel exits are analyzed to determine the original
source and destination locators eSRC and eDST of encapsulated packets
whose discarding is signaled. ICMP/ICMPv6 error messages are then
constructed with the same or appropriately translated error type,
with this eSRC as destination, with the exterior-interface address of
the SAM as source SAM, and with the part of the original exterior
packet found in the received error message after the constructed
ICMP/ICMPv6 header.
2.5. Fragmentation Considerations
If the exterior locator family of a SAM domain is IPv6, datagram
fragmentation has to remain an end-to-end issue. Exterior packets
that don't exceed the size that is guaranteed to traverse the SAM
domain without fragmentation are forwarded. (To comply with
[RFC2460], this size must be at least 1280 octets). Exterior packets
having more than this size may either be discarded (with the
appropriate ICMPv6 error message returned to the source), or
forwarded. In the latter case, the ICMP "Packet too big" error
messages may be received, and must be translated as indicated in
Section 2.4.
Despres Expires September 2, 2010 [Page 9]
Internet-Draft Stateless Address Mapping (SAM) March 2010
If the exterior locator family of a SAM domain is IPv4, a packet size
that traverses the SAM domain without risking to be found too big has
to be known. Exterior packets that have more than this size and
don't have their "Don't fragment" bit set are then fragmented in IPv4
and each resulting packet is independently encapsulated in an
interior family datagram. Exterior packets having more than this
size and having the "Don't fragment" bit set to 1 may either be
discarded (with the appropriate ICMPv6 error message returned to the
source), or forwarded. In the latter case, the ICMP "Packet too big"
error messages may be received, and must be translated as indicated
in Section 2.4.
If the exterior locator family of a SAM domain is IPv4E, other
fragments of a fragmented datagram than the first one don't contain
the necessary UDP port numbers, and therefore cannot be individually
forwarded. Tunnel-entrance SAMs must first reassemble each datagram,
using for this a classical datagram reassembly function, and then
treat the result like an IPv4 packet of the previous paragraph. In
tunnel-exit SAMs interior and exterior datagrams are reassembled
before forwarding.
2.6. Extended IPv4 Prefixes and their Port Sets
Port forwarding is used for IPv4-only hosts that are behind an IPv4
NAT (NAT44) to be reachable from the Internet. Mappings between
transport-layer ports and host private addresses can be configured by
administrative commands, or automatically by a protocol such as the
NAT Port Mapping Protocol of [NAT-PMP]). Now that more and more
sites will have no public IPv4 address of their own, new mechanisms
are needed for this intra-site port forwarding to remain possible.
The SAM answer to this need consists in ISPs statelessly assigning
disjoint port sets to customer sites that share a common public IPv4
address. This permits customer NAT44s to configure at any time their
internal port forwarding with ports of their assigned port set. No
new protocol between customer-site NATs and ISP provided NATs within
their infrastructures is needed for this.
Note that this partial palliative of the IPv4 address shortage does
not avoid limitations that are inherent to public-address sharing
between customers: less ports available for port consuming
applications, impossibility for customers to obtain any specific port
number, etc. Enabling IPv6 in addition to IPv4 remains therefore the
only complete solution to restore good host reachability across the
Internet, on any chosen ports.
Despres Expires September 2, 2010 [Page 10]
Internet-Draft Stateless Address Mapping (SAM) March 2010
For port sets assigned to customer domains that share public IPv4
addresses not to include ports that have more value than others,
ports numbers below 4096 have to be excluded. (This exclusion is
chosen by reference to Windows which has been reported to dynamically
bind ports to applications starting at 4096, because lower numbered
ports are subject to specific behaviors, in particular well known
ports below 1096. If a port range other than above 4095-65535 should
be preferred, the logic described below could easily be adapted to
it.)
Figure 3 shows how SAM derives a port set from an extended IPv4
prefix, i.e. a prefix of the IPv4E family having a length from 33 to
48.
Bits of the prefix after the first 32 are called the port-set index
S. If its length s is less than 13, S identifies 4 port ranges. The
largest of these ranges has 2 ^ (15 - s) elements; the second 2^(14 -
s); etc. For port-set indexes of lengths s > 12, the number of port
ranges of the port set is limited to 15 - s, with the smallest range
having only one element. An extended prefix E of less than 45 bits
has thus 15 / 16 * 2^(48 - e) elements.
Note that, if desired for simplicity, implementations may use only
the first contiguous range, leaving unused less than half of the
ports in the assigned set.
<-------- extended-IPv4 prefix E ------>
<--- IPv4 address (32 bits) ---><------>
|
"port set index" S ________| port-prefix number
| lengths of ports
| V V
/ 1<------> s + 1 2^(15-s)
port prefixes / 01<------> s + 2 2^(14-s)
of the port set \ 001<------> s + 3 2^(13-s)
if s < 13 \ 0001<------> s + 4 2^(12-s)
--------
15/16*2^(16-s)
CORRESPONDENCE EXTENDED-IPv4 PREFIXES AND LOCATOR PORT SETS
Figure 3
Despres Expires September 2, 2010 [Page 11]
Internet-Draft Stateless Address Mapping (SAM) March 2010
2.7. Acquisition of Mapping Rules by Customer Nodes
For early experimentations or advanced uses, a customer SAM may
acquire the SAM rules of its SAM domain by administrative
configuration. But for extensive deployments, they must be acquired
automatically. The DHCP of [RFC2131] and DHCPv6 of [RFC3315]) can be
used for this. Alternatively, in particular for scenarios where
NAT44s have to be traversed, using the DNS as proposed in section 6
of [DNS-SD] can be a better approach.
Figure 4 shows how classical functions of DHCP clients and servers
can be combined with some SAM-specific functions to build a solution:
o A "local SAM-rule configurator" is present in each provider-SAM
border node. It derives one or several SAM mapping rules from its
local parameters. These parameters may have been administratively
configured and/or obtained by automated prefix delegation from the
provider domain. The obtained mapping rules are then submitted,
in a DHCP-option format shown in Figure 5, to a collocated
classical DHCP server.
o A "SAM multiple DHCP client" is present in each "SAM-capable DHCP
server", i.e. in each stateless DHCP server that border nodes of
customer SAMs query to obtain their parameters. A SAM multiple
DHCP client is administratively configured with locators of all
provider SAMs of the domain. It queries them to obtain their
mapping rules. It then submits all of them to the collocated SAM-
rule merger.
o A "SAM-rule merger" is present in each SAM-capable DHCP server.
It gathers all rules submitted to it by the collocated SAM
multiple DHCP client, and merges them into a single SAM DHCP
option. In a sophisticated version, it may retain only some of
these rules, according to some criteria that are beyond the scope
of this version of the draft. The resulting DHCP option, suitable
for a stateless DHCP operation, is then submitted to the
collocated classical stateless DHCP server.
o If a SAM-capable DHCP server is collocated with a provider SAM,
the local SAM-rule configurator can directly submit its rules to
the local SAM-rule merger, without needing a DHCP client-server
relationship.
Despres Expires September 2, 2010 [Page 12]
Internet-Draft Stateless Address Mapping (SAM) March 2010
customer SAM
+-----------------+
| +-------------+ |====>|SAM-rules and other requests
| | DHCP client | | |(to a SAM-capable DHCP server)
| +-------------+ |
+-----------------+
SAM-capable DHCP server
+-------------------+
| +---------------+ |
SAM-rules and other Requests|====>| | DHCP server | |
(from customer-SAMs)| | | (stateless) | |
| +---------------+ |
| | SAM-rule | |
| | merger | |
| +---------------+ |
SAM-rule Requests|<====| | SAM multiple | |
(to all P-SAMs, the list of which| | | DHCP client | |
is administratively configured)| | +---------------+ |
+-------------------+
Provider SAM
+-------------------+
| +---------------+ |
SAM-rules Requests|====>| | DHCP server | |
(from SAM-capable DHCP servers)| | | (stateless) | |
| +---------------+ |
| |local SAM rules| |
| | configurator | |
| +---------------+ |
+-------------------+
FUNCTIONAL ENTITIES TO AUTOMATE SAM-RULES ADVERTISEMENT
Figure 4
The proposed format for the SAM DHCP option is the same for both IPv4
DHCP and DHCPv6. It is detailed in Figure 5. Codes of rule
parameters are chosen to be easy to recognize by maintenance
personnel. (In particular, the first hexadecimal digit is 4, 5,or 6,
distinguishes whether the exterior locator family of the rule is
IPv4, IPv4E, or IPv6). To ensure compactness of prefix
representations, the number of significant bits of their last octets
is included in parameter codes themselves.
Despres Expires September 2, 2010 [Page 13]
Internet-Draft Stateless Address Mapping (SAM) March 2010
1 octet each in DHCP
2 octets in DHCPv6
/\
/ \
<---><---><---------------- n octets ---------------->
+----+----+---...---+--- ... ---+---...---+--- ... ---+
| . | n | rule 1 | | rule i | |
+--|-+----+---...---+--- ... ---+---...---+--- ... ---+
| _________________/ \________________
option code / \
+-----...-----+-- ... --+-----...-----+-- ... --+
| parameter 1 | | Parameter j | |
+-----...-----+-- ... --+-----...-----+-- ... --+
order of parameters _____/ \_____
R, P, x[, E][,T] / \
+----+----+----+--...--+----+
| . | k | parameter value |
+--|-+----+----+--...--+----+
parameter code <--- k octets -->
PARAMETER-CODE VALUES (in Hexadecimal)
1F : x
2F : G
3F : T
4n : IPv4-family prefix (R or P) \
5n : IPv4E-family prefix (R or P) > where n = prefix length mod 8
6n : IPv6-family prefix (R or P) /
PROPOSED DHCP AND DHCPv6 OPTION FORMATS FOR SAM
Figure 5
For rules to be acquired by means of the DNS, in SRV records, a
textual representation has to be used. That which is used in figures
of use cases could serve this purpose. A more compact representation
may be preferable, but is beyond the scope of this version of the
draft.
Despres Expires September 2, 2010 [Page 14]
Internet-Draft Stateless Address Mapping (SAM) March 2010
3. Use-Case examples
3.1. IPv6 across IPv4-only Domains
3.1.1. Native IPv6 across NAT44 CPEs (6rdE)
We consider an ISP whose infrastructure is IPv4, and whose customers
use their own choice of CPEs. Some of these CPEs are likely to
remain IPv4 for quite some time, with NAT44s and port-forwarding
included but no IPv6 support. By provisioning a P-SAMs (possibly
physically duplicated for increased availability and/or performance),
this ISP can offer native IPv6 to all SAM-capable hosts behind these
NATs. We call this application "extended 6rd" or "6rdE".
An IPv6 prefix can be assigned to each host behind such a NAT44 by
concatenating an IPv6 prefix belonging to the ISP, the IPv4 address
of the host customer site and the port that is forwarded to it.
because typical ISPs would not be able to chose for this /16s, these
prefixes will typically be longer than the /64 limit of [RFC4291].
But we note that the /64 limit is technically not necessary for
prefixes only used on virtual links (they don't use the stateless
address autoconfiguration protocol [RFC2462] which does rely on
interface IDs and subnet prefixes to having each 64 bits). We
therefore choose to accept, for this application, host IPv6 prefixes
longer than /64. (How to officialize a relaxation of the /64
constraint of [RFC4291] for this type of IPv6 addresses is beyond the
scope of this draft.)
Figure 6 details the configuration of a 6rdE use case, with the two
applicable mapping rules . The first rule concerns IPv6 packets
exchanged between two customer sites and between a customer site and
the Internet. The second concerns IPv6 packets exchanged between two
hosts within a customer site.
The IPv6 prefix assigned by the ISP to 6rdE is supposed to be D =
2001:db8:9::/48. As nothing is needed in customer exterior locators
E between this D and customer-site IPv4 addresses, the first rule
will have its rule exterior prefix R1 = D. The provider interior
locator G is made of the IPv4 address the P-SAM, supposed to be
192.88.99.3 (an anycast address similar to that of 6to4), and the UDP
port assigned to 6rdE in the P-SAM, supposed to be port 9999. This
ISP is supposed to have a number of independent IPv4 prefixes so that
no common IPv4 prefix is supposed to exist, and the length of the
domain interior prefix P1 of the first rule is 0.
Despres Expires September 2, 2010 [Page 15]
Internet-Draft Stateless Address Mapping (SAM) March 2010
+---------------------------+------------------------+--------
| CUSTOMER SITE | ISP NETWORK | IPv4
| | |BACKBONE
| | multiple prefixes <=========
| | |
| | P-SAM
| | G=192.88.99.3:9999 ---->S<==== D
| | D=2001:db8:9:/48(v6)
| | | IPv6
| | |BACKBONE
| NAT44 |
| K2=192.168.0.0/16 <====N |
| 0.0.0.0/0 ====>N<---- Y=198.16.2.2 |
| 192.168.0.2 N port 4098 |
HOSTS | 192.168.0.3 N port 4099 |
| | and, at least for each SAM-capable host, |
V | 192.168.a.b N port 4096+256*a+b |
-------+ | |
C-SAM | |
I <====S<==== I=192.168.0.2 | |
E <====S | |
E=2001:db8:9:c610:202:1002/96(v6) | |
-------+ | |
C-SAM | |
I <====S<==== I=192.168.0.3 | |
E <====S | |
E=2001:db8:9:c610:202:1003/96(v6) | |
-------+ | |
+---------------------------+------------------------+--------
MAPPING RULES {R1, P1, x1, G} and {R2,P2, x2}
with R1=D, p=0/0(v4), x1=32+16=48, R2=D.Y, P2=K2, x2=32-p2 :
{R1=2001:db8:9::/48(v6); P1=0/0(v4); x1=48; G=192.88.99.3:9999}
{R2=2001:db8:9:c610:2:2::/80; P2=192.168.0.0/16(v4); x2=16}
IPv6 ACROSS NAT44s WITH 6rdE
Figure 6
The customer-index length x1 is that of an IPv4 address plus a port,
i.e. x1 = 48. With the first mapping rule thus defined {R1=2001:db8:
9::/48(v6); P1=0/0(v4); x1=48; G=192.88.99.3:9999}, IPv6 packets
between two hosts of different customer sites and between a host and
the Internet are encapsulated in UDP over IPv4. They are routed in
private IPv4 across customer sites and in public IPv4 across the ISP
network.
Despres Expires September 2, 2010 [Page 16]
Internet-Draft Stateless Address Mapping (SAM) March 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
| IPv4 | |
+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+ +
| | UDP | | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| iSRC = 192.88.99.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| iDST = NAT external address Y = 198.16.2.2 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
| 4098 | 9999 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
| IPv6 | |
+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| eSRC = any IPv6 address not 2001:db8:9::/48 |
+ +
| |
+ +
| | IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ eDST = any IPv6 address 2001:db8:9:c610:202:1002::/96 +
| |
+ +
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+==+=+=+=+=+=++....
| |
+ IPv6 payload + higher
| | layer
EXAMPLE OF PACKET TRAVERSING THE CUSTOMER SITE
Figure 7
Despres Expires September 2, 2010 [Page 17]
Internet-Draft Stateless Address Mapping (SAM) March 2010
Note that hosts must use as source addresses of encapsulating packets
they send their interface addresses, which are in their site private
address spaces (not their site public addresses which are embedded in
in their exterior IPv6 prefixes). Similarly, the host receives and
must accept its IPv4 private address as valid destination in received
encapsulating headers. Figure 6 shows the format, with its
encapsulation headers, of an IPv6 packet that go from the NAT44 to a
host, coming from the Internet.
Now, we need a mapping rule for IPv6 packets exchanged between two
hosts in the same customer site. In the shown customer site, there
is a domain interior prefix K2 = 192.168.0.0/16, so that the customer
index length is x2 = 32 - k2 = 16. Since there is no need to
distinguish among several domain exterior prefixes the customer
interior prefix P2 is equal to the domain interior prefix K2, i.e.
P2 = 192.168.0.0/16. The customer exterior prefix, which determines
whether a locator belongs to the site or not, is D followed by the
customer site public address Y, supposed to be 198.16.2.2, i.e. R2 =
2001:db8:9:c610:2:2::/80. With this in the second rule, IPv6 packets
exchanged between two hosts of the site are encapsulated in IPv4
packets that are routed within the site, as desired.
3.1.2. Optimized Mapping for Multiple IPv4 Prefixes
Although 6rd has been successfully used as a tool for "rapid
deployments" of IPv6 across IPv4 ISP networks, which is its only
purpose, some people have expressed criticisms that the number of
bits used to embed IPv4 addresses in IPv6 prefixes could be better
optimized. The example which we now present makes such an
optimization possible.
Note that this, is not to suggest that SAM should be used in place of
6rd to rapidly deploy IPv6, but only to show that, if and when SAM is
eventually an IETF approved design, it will permit, at a price of
some more complexity, more optimized IPv6 prefix lengths than with
6rd.
In this example, shown in Figure 8, the IPv4 ISP network has 3 IPv4
domain interior prefixes (K1=198.16.0.0/15, K2=198.34.0.0/16,
K3=198.36.0.0/16), and one IPv6 prefix to be used for SAM (D=2001:
db8::/32). Three mapping rules will then be defined, to optimize
exterior prefix lengths, with an objective that all customer sites
have the same IPv6 prefix length.
Despres Expires September 2, 2010 [Page 18]
Internet-Draft Stateless Address Mapping (SAM) March 2010
+------------------------------+
| ISP NETWORK |
| | IPv4 BACKBONE
| K1=198.16.0.0/15 <=========
| K2=198.34.0.0/16 |
| K3=198.36.0.0/16 |
| P-SAM
HOSTS | G=198.16.0.1 ---->S<==== D=2001:db8::/32
| | | IPv6 BACKBONE
V | |
-------+ |
c-SAM |
I <====S<==== I=198.16.2.2/32(v4) |
E <====S |
E=2001:db8:c610:202 |
-------+ |
C-SAM |
I <====S<==== I=198.34.2.2/32(v4) |
E <====S |
E=2001:db8:c622:202 |
-------+ |
C-SAM |
I <====S<==== I=198.36.2.2/32(v4) |
E <====S |
E=2001:db8:c624:202 |
-------+ |
+------------------------------+
MAPPING RULES {Rn; Pn; xn; G}
with Rn=D.Cn, Pn=Kn, i=32, e=56, xn=i-kn,
cn=e-d-xn=20-xn, Cn=n000::/cn :
{R1=2001:db8:1::/39(v6); P1=198.16.0.0/15(v4) ; x1=17; G=198.16.0.1}
{R2=2001:db8:2::/40(v6); P2=198.16.0.0/15(v4) ; x2=16; G=198.16.0.1}
{R3=2001:db8:3::/40(v6); P3=198.16.0.0/15(v4) ; x3=16; G=198.16.0.1}
OPTIMIZED v6/v4 MAPPING FOR MULTIPLE IPv4 PREFIXES
Figure 8
Since there is only one domain exterior prefix D, there is no need
for domain-exterior-prefixes codes C in customer interior prefixes so
that, for n = 1 to 3, Pn = Kn.
On the other hand, since there are several domain interior prefixes
Kn, each customer exterior prefix Rn will include a domain-interior
prefix code Cn after the common D. These codes are chosen so that all
customer exterior prefixes E have the same length. We take e = 56,
Despres Expires September 2, 2010 [Page 19]
Internet-Draft Stateless Address Mapping (SAM) March 2010
i.e. long enough to identify all customer sites after the common /32
prefix D, and constrained to be a multiple of 4 bits for convenience.
Each customer-index length xn is then determined by the length of the
domain interior prefixes Kn which precedes customer indexes X in IPv4
addresses, i.e. xn = 32 - kn. Lengths cn are then 56 - d - xn = kn -
8, i.e. c1 = 7 and c2 = c3 = 8. We choose a value of the first 4
bits of each cn to be n. The 3 rules are then as shown on the
Figure.
3.2. IPv4 across IPv6-only Domains
As some ISPs have started deploying IPv6-only networks, typically for
high bandwidth applications, some of their customers may need
connectivity with the IPv4 Internet. (This need is the reverse from
that satisfied by 6rd where IPv6 connectivity is offered across IPv4-
only ISP networks).
The following sections describe how this can be achieved with SAM,
first if only one ISP IPv4 prefix is used for this, then if there are
several.
3.2.1. Single IPv4 Prefix
+----------------------------+
| ISP NETWORK | IPv6 BACKBONE
| <========= K=2001:db8/32(v6)
| |
| | IPv4 BACKBONE
| P-SAM
------------------+ G=2001:db8::1 ---->S<==== D =198.16.0.0/16
CUSTOMER SITE | |
C-SAM |
I <====S<==== I=2001:db8:4:4/48(v6) |
E=198.16.4.4 <====S |
------------------+ |
+----------------------------+
MAPPING RULE : {R; P; x; G}
with R=D, P=K, x=e...-p,
{R=198.16.0.0/16 ; P=2001:db8::/32; x=16; G=2001:db8:::1}
IPv4 ADDRESSES ACROSS AN IPv6-ONLY NETWORK
Figure 9
Figure 9 presents an example configuration where all global IPv4
Despres Expires September 2, 2010 [Page 20]
Internet-Draft Stateless Address Mapping (SAM) March 2010
addresses that have to be assigned to customer sites across the ISP
IPv6-only infrastructure have the common domain exterior prefix D =
198.16.0.0/16. The customer index length x is then set to 32 - d,
i.e. x = 16.
The ISP is supposed to assign to this application an IPv6 domain
interior prefix K=2001:db8/32, and to have as interior locator of the
provider SAM G = 2001:db8::1. Since there is only one domain
exterior prefix D, no domain-exterior-prefix C is needed, and R = D.
Since there is only one D, we also have P = K. With the resulting
mapping rule {R=198.16.0.0/16; P=2001:db8::/32; x=16;
G=2001:db8:::1}, customer sites that are assigned /48 prefixes are
also assigned public IPv4 addresses. IPv4 packets are encapsulated
in IPv6 packets to traverse the ISP network. Between two customer
sites, they take the same path as packets that are natively IPv6.
Between a customer site and the Internet, they go via the P-SAM.
3.2.2. Multiple IPv4 Prefixes
We now consider a scenario, detailed in Figure 10, in which an ISP,
whose IPv6 infrastructure is IPv6 only, has a fragmented IPv4 address
space. It has three IPv4 prefixes giving a total of 2^19 addresses:
D1=198.16.0.0/14, D2=198.36.0.0/15, and D3=198.34.0.0/15. Its IPv6
address space is contiguous, with K = 2001:db0/28 as domain interior
prefix. It could support 2^20 customer sites with a /48 for each,
but, willing to offer a uniform service, with an IPv4 address for
each, it will use half the available space. Three mapping rules will
be set up.
The customer index Xn of a customer site whose domain exterior prefix
is Dn must have length xn = 32 - dn, i.e. x1 = 18 and x2 = x3 = 17.
Since there are 3 domain exterior prefixes Dn, we have to choose 3
domain-exterior-prefix codes Cn. Supposing we want to assign /48s as
customer interior prefixes P, the length of each Cn must be such that
that k + cn + xn = 48, i.e. cn = 20 - xn, i.e. c1 = 2, c2 = c3 = 3.
The Cn having to be non-overlapping prefixes, with otherwise
arbitrary values, we chose binary values C1 = 00, C2 = 010, and C3 =
011.
Assuming that the IPv6 address of the provider SAM is G=2001:d00::1,
the resulting mapping rules are {R1=198.16.0.0/14; P1=2001:db!::/30;
x1=18; G=2001:d00::1}, {R2=198.36.0.0/15; P2=2001:d20::/31; x2=17;
G=2001:d00::1}, and {R3=198.16.0.0/15; P3=2001:d30::/31; x3=17.
G=2001:d00::1}. With them, customer sites of the ISP have each one
one of the 2^19 IPv4 addresses and a /48 prefix starting with the
common 2001:db0::/29 prefix.
Despres Expires September 2, 2010 [Page 21]
Internet-Draft Stateless Address Mapping (SAM) March 2010
+------------------------------+
| ISP NETWORK | IPv6 BACKBONE
| K <=========
| K=2001:db0/28(v6)
| |
| | IPv4 BACKBONE
CUSTOMER SITES | P-SAM
| | G=2001:db0::1 ----->S<=====
V | | D1=198.16.0.0/14
------------------+ | D2=198.34.0.0/15
C-SAM | D3=198.36.0.0/15
I <====S<==== I=2001:db0:404::/48(v6) |
E=198.16.4.4 <====S |
------------------+ |
C-SAM |
<====S<==== I=2001:db4:505::/48(v6) |
E=198.34.5.5 <====S |
------------------+ |
C-SAM |
<====S<==== I=2001:db6:707::/48(v6) |
E=198.36.7.7 <====S |
------------------+ |
+------------------------------+
MAPPING RULES : {Rn, P, xn, G}
with Rn=Dn, P=K.Cn, xn=32-dn, cn=48-k-xn :
{R1=198.16.0.0/14; P1=2001:db0::/30; x1=18; G=2001:db0::1}
{R2=198.36.0.0/15; P2=2001:db4::/31; x2=17; G=2001:db0::1}
{R3=198.16.0.0/15; P3=2001:db6::/31; x3=17; G=2001:db0::1}
IPv4 ACROSS AN IPv6-ONLY NETWORK - MULTIPLE IPv4 PREFIXES
Figure 10
3.3. Public IPv6 across Private-IPv6 Domains
3.3.1. Multihoming with Provider-Aggregetable Prefixes
A well known problem of IPv4 is that more and more provider
independent prefixes (PIs) are needed to support customer-site
multihoming. This has led to a dramatic growth of Internet-core
routing tables [RFC3582]. The well known reason for this is that, in
multihomed customer sites that have multiple provider-aggregetable
prefixes (PAs), each packet having an intra-site address starting
with one of the PAs has to be routed toward the Internet via the ISP
that provided this PA (ingress-filtering compatibility, discussed in
particular in Section 4.7 of [RFC4864]).
Despres Expires September 2, 2010 [Page 22]
Internet-Draft Stateless Address Mapping (SAM) March 2010
While it has been expected that the need for PI prefixes might
disappear with IPv6, a complete solution remains to be specified for
this to eventually happen.
+------------------------------+
| CUSTOMER SITE | ISP NETWORK
| |
| K=fc00::/56 <====:
| |
| P-SAM
| G1=fc00::7:0:0:0:1 ---->S<==== D1
| D1=2001:db8:1::/48(v6)
| |
| P-SAM
------------+ G2=fc00::6:0:0:0:1 ---->S<==== D2
HOST | D2=2001:db8:2:2200::/56(v6)
| |
I <====S<==== I=fc00::8:0:3:3:3(v6) |
E1,E2 <====S |
E1=22001:db8::1:8:0:3:3:3/128(v6) |
E2=2001:db8:2:2208:3:3:3:3/128(v6) |
| |
------------+ |
+------------------------------+
MAPPING RULES {Rn=Dn.Cn; P=K; x; Gn}
with i=e=128, Cn=::/e-x-dn, x=128-k :
{R1=2001:db8:1::/56(v6); P=fc00::/56; x=72; G=fc00::7:0:0:0:1}
{R2=2001:db8:2:2200::/56(v6); P=fc00::/56; x=72; G=fc00::6:0:0:0:1}
MULTIHOMED SITE WITH IPv6 PROVIDER-AGGREGETABLE PREFIXES
Figure 11
We now show on an example, detailed in Figure 11, that hosts of IPv6
multihomed sites that are SAM capable can take advantage of
multihoming with multiple PAs.
The customer site is assumed to have two PA prefixes, which we take
as domain exterior prefixes D1=2001:db8:1::/48 and D2=2001:db8:2:
2200::/56. They have different lengths for generality of the case.
We assume that the site has several IPv6 interior links, with routing
between based on a private address space and an 8-bit index to
identify each link. The domain interior prefix which precedes these
8 bits is supposed to be K = fc00::/56, in compliance with
[RFC4193]). Provider SAMs that face the two ISPs are supposed to
Despres Expires September 2, 2010 [Page 23]
Internet-Draft Stateless Address Mapping (SAM) March 2010
have as provider interior addresses G1=fc00::7:0:0:0:1 and G2=fc00::
6:0:0:0:1.
Since we want host IPv6 addresses to be assigned as usual, i.e.
possibly with the Stateless Address Autoconfiguration of [RFC2462],
all bits that follow the common domain interior prefix K must be
taken as customer indexes, i.e. x = 128 - 56 = 72.
With the resulting mapping rules {R1=2001:db8:1::/56(v6);
P=fc00::/56; x=72; G=fc00::7:0:0:0:1} and {R2=2001:db8:2:2200::/
56(v6); P=fc00::/56; x=72; G=fc00::6:0:0:0:1}, and with the customer-
SAM locator mapping function of Section 2.3, packets of the shown
host that leave the site have as interior destination iDST G1 or G2
depending on whether their exterior source eSRC matches R1 or R2,
i.e. D1 or D2. Thus, compatibility with ingress filtering exercised
by the ISPs is ensured, as desired.
Packets exchanged between two hosts of the site, with their public
addresses as source and destination eSRC and eDST, are encapsulated
in IPv6 packets having private source and destination addresses iSRC
and iDST.
3.3.2. Renumbering with Unchanged Internal Routing
This example is the same as that of Section 3.3.1 except that, as an
additional feature, the renumbering which is needed when an ISPs
modifies the prefix assigned to the site is automated: the periodical
refresh of SAM parameters, imposed by limited lifetimes assigned to
mapping rules, does the job.
For this, SAM rules, similar to those of Section 3.3.1 now contain
non-default lifetime parameters T, as shown in Figure 12. These are
taken shorter than those of received exterior prefixes, e.g. set to
half their values. Assuming that ISP-2 plans a replacement of prefix
D2 by a new one, say D3, it advertises the new prefix D3 with a
lifetime shorter than that of D2, the still valid but deprecated
prefix. Mapping-rule lifetimes T2 and T3, being derived from
prefixes advertised by ISP-2 for D2 and D3, rule R2 is automatically
deprecated and will be eliminated after some time.
As long as bot R2 and R3 are still valid, each customer SAM has two
ISP-2 exterior prefixes, with different lifetimes. The prefix that
has the longer lifetime is the preferred one, i.e. hosts may use it
in source addresses of transmitted packets, and may accept it in
destination addresses of received packets. The other is deprecated,
i.e. hosts may accept it in destination addresses of received
packets, but may not use it in source addresses of transmitted
packets.
Despres Expires September 2, 2010 [Page 24]
Internet-Draft Stateless Address Mapping (SAM) March 2010
+------------------------------+
| CUSTOMER SITE | ISP NETWORK
| |
| K=fc00::/56 <====:
| |
| P-SAM
| G1=fc00::7:0:0:0:1 ---->S<==== D1
| D1=2001:db8:1::/48(v6),lifetime=80,000
| |
| P-SAM
| G2=fc00::6:0:0:0:1 ---->S<==== D2
------------+ D2=2001:db8:2:2200::/56(v6), lifetime=64,000
HOST | D3=2001:db8:3:::/48(v6), lifetime=86,400
| |
I <====S<==== I=fc00::8:0:3:3:3(v6) |
E1,E2 <====S |
E1=22001:db8::1:8:0:3:3:3/128(v6) <- unique address
E2=2001:db8:2:2208:3:3:3:3/128(v6) <- valid address
E3=2001:db8::3:8:3:3:3:3/128(v6) <- preferred address
| |
------------+ |
+------------------------------+
MAPPING RULES {Rn=Dn.Cn; P=K; x; Gn; Tn}
with i=e=128, Cn=::/e-x-dn, x=128-k, Tn=lifetime(Dn)/2 :
{R1=2001:db8:1::/48(v6); P=fc00::/56; x=72;
G1=fc00::7:0:0:0:1; T1=40,000}
{R2=2001:db8:2:2200::/56(v6); P=fc00::/56; x=72;
G2=fc00::6:0:0:0:1; T2=32,000}
{R3=2001:db8:3:::/48(v6); P=fc00::/56; x=72;
G2=fc00::6:0:0:0:1; T2=43,200}
RENUMBERING IN A MULTIHOMED IPv6 SITE USING PRIVATE ADDRESSING
Figure 12
After the deprecated rule has been discarded, the configuration
returns back back to normal, i.e. with only one customer exterior
address per ISP in each host.
3.3.3. Merging Two Private-Addressing Sites using ULAs
We consider, as shown in Figure 13, two customer sites where interior
routing is based on unique local IPv6 unicast addresses (ULAs) of
[RFC4193].
Despres Expires September 2, 2010 [Page 25]
Internet-Draft Stateless Address Mapping (SAM) March 2010
I=fd12:3456:7890:9:4:4:4:/128(v6)
| K1=fd12:3456:7890::/56(v6)
Host-A +---|-----------------------|--+
-------+ | CUSTOMER SITE-1 | |
C-SAM | K1 <====:
I <====S<==== I |
E <====S P-SAM
----|--+ G1=fd12:3456:7890::1 ---->S<==== D1
| | K2 K1 D1=2001:db8:1::/48(v6)
| | || /\ |
| +-----------\/-----||----------+
|
E=2001:db8:1:9:4:4:4:4/128(v6)
I=fd09:8765:4321:88:3:3:3:3/128(v6)
|
| || /\ K2=fd09:8765:4321::/56(v6)
Host-B +---|--------\/-----||------|--+
-------+ | K2 K1 | |
C-SAM | K2 <====:
I <====S<==== I |
E <====S P-SAM
| | G2=fd09:8765:4321::1 ---->S<==== D2
----|--+ D2=2001:db8:2:220:/56(v6)
| | CUSTOMER SITE-2 |
| +------------------------------+
|
E=2001:db8:2:2288:3:3:3:3/128(v6)
MAPPING RULES: {Rn=Dn.Cn; Pn=Kn; x; Gn}
with e=i=128, Cn=::/e-x-dn, Pn=Kn, x= 72:
{R1=2001:db8:1::/56(v6); P1=fd12:3456:7890:/56(v6); x=72;
G1=fd12:3456:7890::1}
{R2=2001:db8:2:2200:/56; P2=fd09:8765:4321::/56(v6); x=72;
G2=fd09:8765:4321::1}
MERGER OF TWO IPv6 SITES USING UNIQUE LOCAL ADDRESSES
Figure 13
For end-to-end transparency to be preserved in IPv6 despite the use
of intra-site private addressing, hosts and customer-site edge
routers are supposed to be SAM capable.
Mapping rules are established with only one domain exterior prefix D
Despres Expires September 2, 2010 [Page 26]
Internet-Draft Stateless Address Mapping (SAM) March 2010
per site, but otherwise with the same principles as in the
multihoming example of Section 3.3.1, in particular with also 8 bits
to identify IPv6 links within each site. These rules are supposed to
be in site-1 {R1=2001:db8:1::/56(v6); P1=fd12:3456:7890:/56(v6);
x1=68; G1=fd12:3456:7890::1}, and in site-2{R2=2001:db8:2:2200:/56;
P2=fd09:8765:4321::/56(v6); x2=72; G2=fd09:8765:4321::1}.
Now, we want to interconnect the two sites in such a way that traffic
between hosts of the two sites goes via direct inter-site links.
Since this is precisely the purpose ULAs, we want to do this without
having to renumber private addresses in any of the two sites.
For this, it is sufficient that routes be opened between the two
sites for their respective ULA prefixes, and that DHCP servers of
each sites have site their lists of provider-SAM locators completed
with that of the other site.
After some delay, which depends on timers of DHCP refreshes, all
hosts know the two rules. Then, mapping rules of Section 2.3 are
such that packets going from a site to the global Internet continue
to reach it via the same provider SAM as before, but that inter-site
packets go via the shortcuts, as desired.
For example, if a packet from host A is addressed to host B, it has
eDST = 2001:db8:2:2288:3:3:3:3 which matches, the customer exterior
prefix of the second rule R2 = 2001:db8:2:2200:/60. The derived
interior destination locator is then iDST = P2.(eDST - R2).0*/128 =
fd09:8765:4321:88:3:3:3:3, i.e. the interior address of host B.
If a more complete merger is desired, with the merged site becoming
multihomed so that all hosts become able to transmit via either
provider SAM, this is also possible. Two rules have for this to be
added: {{R1=2001:db8:1::/56(v6); P2=fd09:8765:4321::/56(v6); x=72;
G1=fd12:3456:7890::1} and {R2=2001:db8:2:2200:/56; P1=fd12:3456:
7890:/56(v6); x=72; G2=fd09:8765:4321::1}.
3.4. A Planned Experiment at Telecom Bretagne
A particular experiment of SAM is planned at Telecom Bretagne, an
academic institution in France. It involves a two-layer hierarchy of
SAM domains. The layer-1 domain is a student-residence network;
layer-2 domains are LANs within rooms of some of the students that
participate in the experiment.
Each student room, which has today a DHCP advertised private IPv4
address and an auto-configured IPv6 public address, will obtain in
addition, with SAM, a /60 IPv6 prefix and 240 ports on a shared
public IPv4 address.
Despres Expires September 2, 2010 [Page 27]
Internet-Draft Stateless Address Mapping (SAM) March 2010
+------------------------------+
| STUDENT-RESIDENCE NETWORK |TELECOM BRETAGNE
| | NETWORK
| |IPV6
| <=========
| 2001:660:7301:4666::/64
| |
| NAT44 IPv4
| K=192.168.0.0/24<====N<----
| 0.0.0.0/0 ====>N
| |
-------------+ P-SAM
| G=192.168.0.1/32 ---->S<=====
STUDENT ROOM | D1=2001:660:7301:3000/52(v6)
| D2=192.108.119.26/32(v4)
<---------- |
2001:660:7301:4666:2:3:4:5 |
| |
C-SAM |
I <----S<---- I=192.168.0.4(v4) <- IPv4 private address
<====S |
E1=2001:660:7301:3040/60(v6) <- IPv6 public prefix
E2=192.108.119.26.4/40(v4) <- 240 ports on a public IPv4 address
| (15/16*2^(48-40))
-------------+ |
+------------------------------+
STUDENT-RESIDENCE MAPPING RULES : {Rn; P; x; G}
with Rn=Dn, P=K, x=32-p :
{R1=2001:660:7301:3000/52(v6); P=192.168.0.0/24; x=8}
{R2=192.108.119.26/32(v4); P=192.168.0.0/24; x=8}
STUDENT-RESIDENCE NETWORK AT TELECOM-BRETAGNE
Figure 14
In rooms equipped with a SAM-capable CPE, each SAM-capable host will
have, in addition to its DHCP advertised private IPv4 address, a /64
IPv6 prefix and 15 ports on the shared IPv4 address.
The configuration planned for this is shown in Figure 14 and
Figure 15.
Despres Expires September 2, 2010 [Page 28]
Internet-Draft Stateless Address Mapping (SAM) March 2010
+---------------+========================+
| STUDENT-ROOM | IN STUDENT-ROOM CPE | STUDENT-RESIDENCE
| LAN | | NETWORK
| | |
| | <----------
| | 2001:660:7301:4666:2:3:4:5
|K= 198.0.0.0/28| |
| | | |
| | NAT44 C-SAM
| <====N<---- 192.168.0.4 <----S<---- I
| ====>N S I=192.168.0.4(v4)
| 0.0.0.0/0| S
| | S
| P-SAM S
| G ---->|<==== D1,D2 E2,E2 <====S
| G=198.0.0.1| D1=E1=2001:660:7301:3040/60(v6)
| | D2=E2=192.108.119.26.4/40(v4)
| | |
-------+ +========================+
STUDENT| |
HOST | |
| |
C-SAM |
I <----S<---- I=192.168.0.2(v4) <- IPv4 private address
<====S |
E1=2001:660:7301:3042:/64(v6) <- IPv6 public prefix
E2=192.108.119.26.4.32/44(v4) <- 15 ports on a public IPv4 address
| | (15/16*2^(48-44))
-------+ |
+---------------+
STUDENT-ROOM MAPPING RULES : {Rn; P; x; G}
with Rn=Dn, P=K, x=32-p :
{R1=2001:660:7301:3040/60(v6); P=192.168.0.0/28; x=4}
{R2=192.108.119.26/32(v4); P=192.168.0.0/28; x=4}
STUDENT-ROOM EXAMPLE AT TELECOM-BRETAGNE
Figure 15
In a border node of the residence, a provider SAM will be set up, in
a PC under Linux, to derive from the 8 lower bits of private IPv4
addresses two public prefixes: an IPv6 /60 and an extended IPv4 /40.
Despres Expires September 2, 2010 [Page 29]
Internet-Draft Stateless Address Mapping (SAM) March 2010
In each room participating to the intra-room experiment, a router
under Linux will be supplied. In addition to its classical NAT44
which assigns private IPv4 addresses to hosts in the room, it will
include a customer SAM and a provider SAM. The customer SAM will
derive the IPv6 /60 and the IPv4E /40 of the room from its private
address on the residence LAN. The provider SAM will further
distribute these prefixes so that each host in the room can derive
from it's DHCP assigned IPv4 address an IPv6 /64 and an IPv4E /44.
Thus, each host will have not only it's own IPv6 address, but will
also be able to to manage a small IPv6 LAN behind it. It will also
be reachable from the Internet in IPv4 at it's shared public address
on one of it's 15 assigned ports.
4. Security considerations
To avoid to introduce new spoofing opportunities, SAMs should
ascertain that source and destination iSRC and iDST of each received
interior packet are, with the mapping rules of the domain, valid
derivate from the exterior source and destination eSRC and eDST
contained in the encapsulated packet.
Against denial of service attacks, the fact that mapping functions
and encapsulations are stateless is clearly favorable. An exception
exists however with IPv4E exterior locator spaces because of the the
datagram reassembly function of Section 2.6 which has a stateful
internal operation. (This vulnerability is the same as found in NATs
that don't forward fragmented datagrams.)
A systematic study has still to be done on which routing-loop-
attacks, similar to those documented for ISATAP and 6to4 in
[RoutingLoops], might be possible. As a minimal precaution, provider
SAMs should discard any interior packets received whose source iSRC
is the provider interior locator G of any provider SAM, and should
not forward any interior packet whose destination iDST is such a G.
Any interior address of a 6to4 relay that would be set up in a SAM
domain, or of a default ISATAP router giving access to the IPv6
Internet, should be considered also as a forbidden G.
5. IANA Considerations
DHCP and DHCPv6 option codes have to be specified by IANA.
It could also be convenient that a number be assigned by IANA for the
port used in provider SAMs to encapsulate over UDP over IP.
Despres Expires September 2, 2010 [Page 30]
Internet-Draft Stateless Address Mapping (SAM) March 2010
6. Acknowledgments
Although this specification is mostly the result of a personal work
of the author, in continuity with that which led to the 6rd of
[RFC5569], recognition is due to a number of colleagues who provided
useful reactions as the proposal evolved. Mark Townsley provided
precious encouragements since the early phases of the project. He
also acted as a convincing advocate for a Cisco Research Grant to be
allocated, a SAM experiment with port-extended IPv4 addressing, at
Telecom Bretagne. Laurent Toutain, who leads the team in charge of
this experiment, deserves special gratitude for the confidence he has
shown for the concept, and for the time spent for experiment to be
organized. Dave Thaler has to be thanked for the detailed review he
made on a previous draft. Satoru Matsushima was first to point out
that, because some providers already operate IPv6-only networks,
public IPv4 across such networks could become a not-so-long-term
application of SAM.
7. References
7.1. Normative References
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Despres Expires September 2, 2010 [Page 31]
Internet-Draft Stateless Address Mapping (SAM) March 2010
7.2. Informative References
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery
- draft-cheshire-dnsext-dns-sd-05", September 2008.
[NAT-PMP] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
(NAT-PMP) - draft-cheshire-nat-pmp-03", April 2008.
[NatClassification]
Jennings, C., "NAT Classification Test Results -
draft-jennings-behave-test-results-04", July 2007.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
Despres Expires September 2, 2010 [Page 32]
Internet-Draft Stateless Address Mapping (SAM) March 2010
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd)", January 2010.
[RoutingLoops]
Nakibly, G. and F. Templin, "Routing Loops using ISATAP
and 6to4: Problem Statement and Proposed Solutions - -
draft-nakibly-v6ops-tunnel-loops-01", February 2010.
[Standard-track 6rd]
Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks - draft-ietf-softwire-ipv6-6rd-04",
February 2010.
Author's Address
Remi Despres
RD-IPtech
3 rue du President Wilson
Levallois,
France
Email: remi.despres@free.fr
Despres Expires September 2, 2010 [Page 33]