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]