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