Internet Engineering Task Force R. Despres Internet-Draft October 26, 2009 Intended status: Standards Track Expires: April 29, 2010 Stateless Address Mapping (SAM) - Mesh Softwires without e-BGP draft-despres-softwire-mesh-sam-01 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 April 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract SAM is a generic and simple mechanism for packets having addresses in a family IPvX to traverse routing domains where this address family is not directly routed. Despres Expires April 29, 2010 [Page 1] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 SAM topological scenarios are those of Mesh Softwire, i.e. with point to multipoint tunnels between border nodes of interior routing domains. In the mesh-softwire context, SAM differs from RFC 5565 in that SAM uses no protocol between border nodes of the domain, and in that customer border nodes don't need to maintain states for all other border nodes. (RFC 5565 is based on an Exterior Border-Gateway Protocol e-BGP between border nodes, with dynamic routing tables to be maintained in all of them). SAM's address mappings are stateless, based on only a few domain parameters. SAM is thus suitable to small to medium enterprises, and small to medium ISPs, that cannot afford e-BGP in all their border nodes. All combinations of IPv4 and IPv6, global or private, are supported. Also, to mitigate consequences of the IPv4 address shortage, SAM supports port-extended IPv4 addresses (A+P). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 2.1. A small ISP lacking enough global IPv4 addresses . . . . . 5 2.2. A small customer site having only a port-restricted IPv4 address . . . . . . . . . . . . . . . . . . . . . . . 7 3. The SAM Model and its Terminology . . . . . . . . . . . . . . 9 4. SAM functional sub-modules and their parameters . . . . . . . 10 5. Mapping between SAM Interior Addresses and SAM interior IDs . 13 5.1. SAM-interior-address Formats . . . . . . . . . . . . . . . 13 5.2. SAM Interior Addresses and SAM Interior IDs in IPv6 . . . 14 5.3. SAM Interior Addresses and SAM Interior IDs in IPv4 . . . 15 6. SAM Prefixes and SAM Raw Prefixes . . . . . . . . . . . . . . 16 7. Derivation of Sub-delegated prefixes from Delegated Prefixes and Interior IDs . . . . . . . . . . . . . . . . . . 19 8. Mapping from Source and Destination Endpoint Locators to Source and Destination Interior Addresses . . . . . . . . . . 20 8.1. Encapsulation Function . . . . . . . . . . . . . . . . . . 20 8.2. Decapsulation Function . . . . . . . . . . . . . . . . . . 21 9. Detailed Prefixes for the Example Scenarios . . . . . . . . . 22 10. Applicability to other scenarios . . . . . . . . . . . . . . . 24 11. Security considerations . . . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Despres Expires April 29, 2010 [Page 2] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 1. Introduction The Softwires Working Group standardizes discovery, control, and encapsulation methods, for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks. Two topological scenarios have been identified for this in [RFC4925]: Hubs and Spokes and Mesh. o Hubs and Spokes targets carriers, or large enterprise networks acting as carriers, that deploy Centralized Softwire Concentrators. o The particular mesh framework described in [RFC5565] targets carriers or large-enterprises whose networks support, in all their border nodes, a common exterior Border Gateway Protocol (e-BGP). Stateless Address Mapping (SAM) targets small to medium enterprises, or small to medium Internets service providers (ISPs), that don't operate centralized software concentrators, and in whose networks a common e-BGP in all border nodes in not practicable. (In SAM, stateless means that border nodes are not obliged to maintain states for all other border nodes - a meaning similar to that used in Stateless DHCP of [RFC3736]). SAM principles are an extension of those already in practice with 6to4 [RFC3056], ISATAP [RFC5214], and 6rd [Free's IPv6 in 2007] [RFC5569] [6rd], which support IPv6 across IPv4 routing domains, encapsulate exterior packets into interior packets, and statelessly map from exterior addresses to interior addresses. SAM unifies and generalizes their scopes in the following directions: o Other encapsulations than just global IPv6 in global or private IPv4 are supported, with all combinations of IPv6 and IPv4, including with the IPv4 private addresses of [RFC1918] and the IPv6 private addresses of [RFC4193] for interior routing. o Provisions are made so that, despite the IPv4 address shortage [Ipv4Shortage], the end-to-end transparency of [RFC2775] can be restored in IPv4. o Stateless autoconfiguration of sub-delegated prefixes [PrefSubDeleg] is made possible in addition to the IPv6 stateless address autoconfiguration of [RFC2462]. o Support of multihoming is generalized [RFC3582] [RFC4219], with compatibility with ingress filtering in ISP networks [RFC3704]. Despres Expires April 29, 2010 [Page 3] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 SAM's design has some commonalities with various earlier proposals, like ENCAPS (RFC 1955 in 1996), GSE (draft-ipng-gseaddr-00 in 1997), DSTM (draft-ietf-ngtrans-dstm in 1999-2002), LISP (draft-farinacci-lisp in 2007-2009), RANGERS (draft-templin-ranger in 2008-2009), IVIT (draft-xu-behave-ivit in July 2009). But it has a significantly different scope from all of them. In particular, LISP introduces an Endpoint Identifier space different from the Routing Locator space. Tunnels across the Internet core are consequently always necessary. On the contrary, SAM's endpoint identifiers are based on routable IPv4 and IPv6 address spaces. Tunnels across the Internet core are therefore not necessary, which is important for incremental deployability [RFC5218]. Compared to protocols such as SCTP [RFC4960] and Shim6 [RFC5533], which specify how to use to multiple addresses in host endpoints, SAM is complementary. It introduces new ways to assign multiple addresses to hosts so that they can be used by SCTP or Shim6. This SAM specification is an evolution from [-SAM-02] and [-SAM-03]. The former was focused on how NATs might be totally dispensed with if SAM would be generalized (somewhat theoretical); the latter was limited to how SAM supports multihoming in sites using private IPv6 addresses (practical, but too restrictive). This one is focused on what SAM can provide, in a reasonable short term, in many configurations (more practical, not restrctive). It also introduces some technical improvements and, the author believes, substantial clarifications. The proposed specification is intended to be complete enough now to permit compatible independent implementations, by developers skilled in the art, with administratively configured parameters. (DHCP- option formats have yet to be specified). Being new, this specification is likely to have remaining inadequacies and even, the devil being in details, sheer bugs. Many improvements and corrections are therefore expected to be necessary after more work, but the approach is believed to sound. Implementation of a subset of this specification is under way at Telecom Bretagne, in view of a first experimentation. Despres Expires April 29, 2010 [Page 4] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 2. Example Scenarios To mitigate consequences of the IPv4 address shortage during the transition-to-IPv6 period, diverse solutions have been identified for different scenarios: [Frmwk-trans] and [DSlite] are based on ISP provisioned NATs (CGNs); [PRR] and [A+P], which can coexist with CGNs or in some cases make them unnecessary, target hubs-and-spokes configurations. They support dynamic reservations of port ranges (with stateful mappings). The two example scenarios below are similar to the latter (coexistence with CGNs, with possibilities to bypass them), but concerns mesh configurations, and is based on static port-range assignments (stateless mappings). SAM's applicability is much larger than described in these two examples. They have been been chosen to insist on SAM's potential to face the more and more pressing IPv4 address shortage problem. 2.1. A small ISP lacking enough global IPv4 addresses Figure 1 shows the configuration of this first scenario. The considered small ISP offers native IPv6 to its customers. Because it has a /32 IPv6 prefix and assigns /48s to its customers, it can support up to 64K of them. Now, due to the IPv4 address shortage, it has only a /20 IPv4 prefix (a maximum of 4K global IPv4 addresses). This not being enough to assign one IPv4 address to each customer, IPv4 address have to be shared. This can be done both dynamically, for an optimized multiplexing efficiency but at a cost of non-transparent NAT traversal, and statically, to avoid NAT traversals and so that assigned addresses and ports can be safely advertised outside (typically for server or peer-to-peer applications that need incoming connections). To support IPv4-only legacy hosts, and to offer dynamic port sharing to all hosts including SAM-capable ones, the ISP of this scenario operates a CGN for IPv4-to-IPv4 address translations (NAT44). To use it, customers are assigned private IPv4 addresses of [RFC1918]. These addresses are obtained by customer-edge routers (CEs) in DHCPv4 [RFC2131]. The ISP assigns ports 0 to 32K - 1 of all its global IPv4 addresses to its CGN, and ports 32K to 64K - 1 to SAM for its port-extended IPv4 addressing. Despres Expires April 29, 2010 [Page 5] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 INTERNET IPv6-SubnetPrefix/64 (RA) BACKBONES IPv6-Add (autoconf) | PrivIPv4-Add (DHCPv4) IPv6-Pref/32 | | | V CUSTOMER-EDGE | | NODES (CEs) | +-------------------------+ | +--------- | | | ISP NETWORK | | | V | | IPv6 & private IPv4 |<=== | +------------+<=== | +-------+ IPV6 | dual stack |<--- | | | | only +------+ | | | | | | +--------- +------------+ | | | | +------------+ | +-------+ | dual stack | | | CGN | +--------- | +------+------+ | NAT44 | | | | SAM |<=== | | | | | |<=== |<--- | +-------+-------+ IPV4 | | | | | | | |<=== | +-----+--|---+ | | | SAM | | | | | | | | | +--------- | | +-----------------+-------+ | | | | IPv6-SubnetPrefix/64 (RA) | | IPv6-Add (autoconf) IPv4-Pref/20 | PrivIPv4-Add (DHCPv4) | IPv6-Pref/48 IPv4-Add:(PortPref/5) Number of customer sites: 64K NAT44 external ports : 2K / customer site IPv4 assigned ports : 2K / customer site AN ISP EXAMPLE WITH LESS IPv4 ADDRESSES THAN IPV6 /48 PREFIXES Figure 1 With SAM, in a way that will be explained in subsequent sections, and detailed for this example in Section 2.1, each dual-stack CE, in addition to its possibility to use shared ports of the CGN like any IPv4-capable CE, is statically assigned 2K reserved ports on a shared global IPv4 address. Despres Expires April 29, 2010 [Page 6] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Each CE has freedom to use these reserved ports its own way to take advantage of the end-to-end Internet transparency they make possible. In the next-section scenario, we describe how a particular CE uses its reserved ports. 2.2. A small customer site having only a port-restricted IPv4 address Figure 2 shows a possible scenario for a customer site whose ISP is that of the previous section. The considered customer site is residential or is that of a small- office/home-office. It has up to 16 hosts on a single LAN. (This LAN may include a switch between different physical media, like copper wires, Wifi, power-lines, etc.). For IPv4-only legacy hosts, the CE supports a NAT44, and a DHCP server which assigns private IPv4 addresses. This NAT uses ports 4K to 64K - 1 of the site private-IPv4 address. It also uses 1K ports among the 2K reserved ports of the site global-IPv4 address. (With these ports, it can support administratively configured port forwarding, and dynamic reservation protocol such as NAT-PMP or UPnP.) In addition to IPv6 possibilities of all dual-stack hosts, SAM- capable hosts are statically assigned IPv6 /52 prefixes. They may use these prefixes freely, for example to run small LANs behind them, e.g. in Bluetooth, with global-IPv6 addresses assignable to hosts of these LANs. In IPv4, each SAM-capable host is automatically assigned, besides its private IPv4 address, 64 reserved ports of the site global IPv4 address. It can use them its own way, in particular to advertise outside its ports on which it has server and/or peer-to peer applications. It can also further distribute some of these reserved ports to SAM-capable hosts on a LAN behind it. Some protocols are known to traverse NATs without problem, like that of Web requests (remote port 80) and that of DNS queries (remote port 53). In order to save ports of the site global IPv4 address for other usages, outgoing connections having these protocols can use the site private address and traverse both the site NAT44 and the CGN. Note that, in the case of DNS queries, a known advantage of traversing NATs is that used external ports are less predictable. This is a known precaution to prevent the DNS attack identified by Dan Kaminsky [DnsAttack]. Despres Expires April 29, 2010 [Page 7] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 IPv6-SubnetPrefix/64 (RA) IPv6-Add (autoconf) PrivIPv4-Add (DHCPv4) HOSTS | IPv6-SubnetPrefix/64 (RA) | | LAN IPv6-Add (autoconf) | | IPv6 & private IPv4 PrivIPv4-Add (DHCPv4) v | | | +------------+ | | CUSTOMER-EDGE ROUTER (CE) | | dual stack |<=== | +--------------------+ | | only |<--- | | | | | |<--- | | +-------+ | | | +-------------+ | | | | <=== | | | | | NAT44 | | <--- +------------+ | | | | | <--- +-------+ +-------+-------+--------- +------------+ | | | SAM | SAM | | dual stack | | | | |<=== | | +-----+-------------+ | | | | | | | SAM |<=== | +----+-------+--|----+ | |<=== |<--- | | | | | |<--- | IPv6-Pref/48 +------+--|--+ | | IPv4-Add:(PortPref/5) | | | | | IPv6-SubnetPrefix/64 (RA) | IPv6-Add (autoconf) | PrivIPv4-Add (DHCPv4) | IPv6-Pref/52 IPv4-Add:(PortPref/9) Number of SAM hosts: 16 NAT44 external ports via ISP NAT44 : 60K = ~ 4K / host NAT44 external ports on its public address: 512 = 64 / host IPv4 assigned ports : 64 / host A SMALL CUSTOMER SITE HAVING A PORT-RESTRICTED IPV4 ADDRESS Figure 2 Despres Expires April 29, 2010 [Page 8] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 3. The SAM Model and its Terminology Th SAM model is illustrated in Figure 3. SAM functional modules, or "SAMs" for short, are located in "border nodes" of the SAM interior routing domain (or "SAM domain" for short). These modules encapsulate packets they receive from "exterior" domains, and forward them across the SAM "interior" domain. In the other direction, they decapsulate packets received from the interior to forward them on their exterior domain. .--------------- EXTERIOR --------------. / \ ------'----> <---- INTERIOR ----> <----'------- <--- CONSUMER SIDE --- --- PROVIDER SIDE ---> SUB-DELEGATED DELEGATED prefixes prefixes | interior | endpoint | ADDRESSES | LOCATOR endpoint | / \ | | LOCATOR | / \ +--|------|------- | | +---/-----------\---+ | | | -----|----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--|----+ | | +-------+ | | | | | | | | | | | | +--+ | | | | | | | | | | +--+ | +<--- |<=== |<--- --->| |<=== --->+ | +--+ | SAM | | SAM | +--+ ENDPOINT | | SAM DOMAIN | | ENDPOINT +-------+ +-------+ | | with defined | | | ^ | INTERIOR ADDRESS | ^ | -----------+ : | FORMAT(S) | : | : +-------------------+ : | : : +----------- : : <-------> <-------> in a BORDER NODE in a BORDER NODE (host or router) (router) SAM TERMINOLOGY Figure 3 Despres Expires April 29, 2010 [Page 9] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 An endpoint "locator" can be a global-IPv4 or global-IPv6 address or, if its endpoint is in a domain where port-extended IPv4 addressing is used, an address-plus-port couple (A+P). (In domains using port- extended addressing, endpoints exist only for applications that use ports, i.e. all applications using TCP, UDP, DCCP, or SCTP. ICMP error messages returned when packets of such connections are discarded, because they contain the port numbers of discarded packets, can reach such endpoints.) With SAM, port-extended-addressing applies not only to IPv4, to deal with the IPv4 address shortage, but also to IPv6. This not only maintains orthogonality of features (avoidance of restrictions for which there is no identified reason), but has also identified applications. In particular, if a LAN is deployed behind a host having a global IPv6 address but no IPv6 prefix, and if this LAN has a frame format such that bridging in the host is not possible, then port-extended IPv6 addressing on this LAN is a useful tool to provide global IPv6 reachability to hosts on this LAN. If one or several delegated prefixes are received from the exterior side of a SAM (in DHCP or otherwise), these prefixes are called "delegated prefixes" of the SAM domain, and the exterior side of this SAM is called a "provider side" of the SAM domain. If, conversely, a SAM delegates one or several prefixes to its exterior domain, these prefixes are called "sub-delegated prefixes" of the SAM, and the exterior side of this SAM is called a "consumer side" of the SAM domain. As detailed in Section 7, prefixes that are sub-delegated by a SAM are derived from the delegated prefixes of the SAM domain and the "interior ID" of this SAM. Delegated and sub-delegated prefixes, are prefixes of endpoint locators. As such, they can be port-extended (up to 48 bits in IPv4 and 144 in IPv6). 4. SAM functional sub-modules and their parameters Sub-modules of SAMs, both customer-side and provider-side, are shown in Figure 4. Despres Expires April 29, 2010 [Page 10] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 customer-side SAM <- exterior interior -> +-----------------+ | +-------------+ | | SAM PARAMETERS | | DHCP client | |<=== | (obtained from a provider-side SAM) | +-------------+ | | | SAM | | | | stateless | | | | autoconf | | | +-------------+ | | | SAM | | provider-side SAM | | map & encap | | <-- interior exterior --> | +-------------+ | +-------------------+ +-----------------+ | +---------------+ | | | stateless | | SAM PARAMETERS | <====| | DHCP server | | (provided to consumer-side SAMs) | | +---------------+ | * Interior parameters | | | SAM | | - SAM interior-address format(s) | | | map & encap | | * Exterior parameters | | +---------------+ | - provider-SAM interior address(es) | | |SAM-parameter | | - their delegated prefix(es) | | | gatherer | | | +---------------+ | SAM PARAMETERS | | | DHCP | | (obtained from other provider SAMs) | ===>| | multiple | | | | client | | Configured parameters: | +---------------+ | * SAM interior-address format(s) |---.->| | * interior addresses of provider SAMs | / +-------------------+ \ '----- delegated prefixes of this SAM SAM FUNCTIONAL MODULES AND THEIR PARAMETERS Figure 4 A customer-side SAM has a DHCP client to obtain SAM parameters that apply to its SAM domain. The DHCPv6 of [RFC3736] is used if IPv6 interior addresses are available, the DHCPv4 of [RFC2131] otherwise. The SAM stateless autoconfiguration sub-module is, in a customer-side SAM, in charge of building its "SAM interior address". This address conforms to one of the SAM interior-address formats of the SAM domain. This format is such that the interior ID of the SAM, shorter than an address, can be derived from its SAM interior address. For the IPv6 stateless address autoconfiguration of [RFC2462] to still work with legacy hosts that may be on the same links, SAM interior- Despres Expires April 29, 2010 [Page 11] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 addresses must have a different format from all possible addresses of such hosts. For this, SAM interior addresses have a SAM tag that distinguishes them, as detailed in Section 5.2. In IPv4, the autoconfiguration is based on [RFC3927], applied to interior addresses of Section 5.3. IPv4 SAM interior addresses, having no place for a SAM tag, have to be distinguished from other interior addresses by means of distinct subnet prefixes. The SAM map&encap sub-module is present in all SAMs, customer-side as well as provider-side. It checks that source and destination locators received by a SAM from either of its sides are authorized. It also has to check that, in packets received from its interior side, source and destination interior addresses of encapsulating packets are consistent with source and destination endpoint locators of encapsulated packets. If these checks don't fail, packets are in the exterior-to-interior direction encapsulated as specified in [RFC4213], and are in the interior-to-exterior direction decapsulated. The DHCP-server sub-module is, as far as SAM parameters are concerned, stateless (no need to maintain states about customer-side SAMs). It is in charge of transmitting SAM parameters of the SAM domain to customer-side SAMs from which it receives queries. These parameters are those that have been collected by the SAM-parameter gatherer sub-module. In a node that already needs a DHCP server for other purposes, the SAM DHCP-server sub-module can be this DHCP server. The SAM-parameter gatherer sub-module makes a synthesis of: o delegated prefixes received from the exterior side of the SAM; o the interior address of the SAM. o parameters that are administratively configured for this SAM (i.e. formats of SAM interior addresses and, if the SAM domain is multi- homed, the list of interior addresses of other provider-side SAMs); o parameters that are obtained from other provider-side SAMs by the DHCP multiple client sub-module; The interior address of a provider-side SAM must be distinguishable from that of a customer-side SAM for routing-loop-attack prevention as explained in Section 8. It has therefore to be obtained as a classical IPv6 address (whose format is different from that of SAM interior addresses that customer-side SAMs obtain as detailed in Section 5). Despres Expires April 29, 2010 [Page 12] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 The SAM-parameter gatherer module queries stateless DHCP servers of other provider-side SAMs. It merges all parameters it thus receives with those received locally. It checks that SAM interior-address formats are consistent (identical if they have the same format ID, as specified in Section 5). All SAM functions being stateless, each SAM can be duplicated to sustain traffic loads that exceed a single processor capacity. All instances must have the same SAM interior address (routed as an anycast address in the SAM domain). 5. Mapping between SAM Interior Addresses and SAM interior IDs 5.1. SAM-interior-address Formats A SAM interior-address format has the following sub-parameters: o A "format ID" F. Having several formats in a SAM domain permits to have in a SAM domain link subnets having different lengths, and to sub-delegate prefixes having different lengths. If a SAM domain has only one SAM interior-address format, the format ID is not needed. Its length can then be set to 0. If there are several non-null-length formats, their IDs must be non overlapping prefixes so that they can be recognized in locators. (For example, 0, 100, 1O1, 110, 1110, and 1111, are compatible format IDs, but not 01 and 011). o A "common prefix" C. In SAM domains that use private address spaces, C can for example be in IPv4 10.0.0.0/8 [RFC1918]. In IPv6, it can be a /48 randomly selected prefix of [RFC4193], used to build Unique Local IPv6 addresses in the SAM domain. In one of the provider-side SAMs of the domain, C can be administratively specified to be a received delegated prefix of the SAM (as short as possible if there are several) rather than a given constant. In this case the interior address space is a global, as in examples of Section 9. o The "subnet-ID" length s. If a SAM domain has several links having different subnet prefixes, it needs several formats. Subnet IDs are the fields that appear after Cs to distinguish subnet prefixes. In a site with only one link, subnet IDs are not needed, and s can be set to 0. o The "host-ID" length h. In a SAM interior address, the host ID is in the lower part of the address. Two consumer SAMs that are on a common link have different host IDs, obtained by autoconfiguration. Despres Expires April 29, 2010 [Page 13] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 5.2. SAM Interior Addresses and SAM Interior IDs in IPv6 Figure 5 shows the reversible mapping between SAM interior address and interior ID in IPv6. A SAM tag is necessary, in the stateless address autoconfiguration of [RFC2462], to distinguish SAM interior addresses from other IPv6 addresses on the same link. It is enough for this that the two lower bits of addresses 9th octet be set to 0b11 (a value which differs from that of all currently IPv6 addresses specified in [RFC4291]). Other bits of the octet are proposed to be all set to 1 to keep an escape mechanism for future new IPv6 address formats. SAM INTERIOR ADDRESS - IPv6 common prefix subnet ID SAM format ID host ID | (s may be 0) tag | (f may be 0) | | | | | | V V V V V <----------c---------><--s-> <-8-> <--h---> <------------- 64 -------------><------------- 64 -------------> +---------------------+-----+---+----+---+--------------+------+ | C |XXXXX| 0 |0xFF| F | 0 |XXXXXX| +---------------------+-----+---+----+---+--------------+------+ | | / / / / Format /\ |_____|______/ / / / Parameters || / __|_________/ / / F, C, s, h || /| / | _____________________/ / || / | / | / _____________________/ \/ / |/ |/ / +---+-----+------+ |"F"|XXXXX|XXXXXX| +---+-----+------+ <---- f+s+h ----> SAM INTERIOR ID MAPPING BETWEEN SAM INTERIOR ADDRESSES AND SAM INTERIOR IDs IN IPv6 Figure 5 Despres Expires April 29, 2010 [Page 14] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 5.3. SAM Interior Addresses and SAM Interior IDs in IPv4 Figure 6 shows the reversible mapping between SAM interior addresses and SAM interior IDs in IPv4. In IPv4 SAM interior addresses, there is not, like in IPv6, a place to have different format IDs without interfering with routable subnet prefixes. If there are several links in a SAM domain, there should then be only one format. SAM interior IDs have then the same length for all consumer-side SAMs of the SAM domain. If on the other hand there is only one link in the SAM domain, different format IDs can be used to have several host-ID lengths, which permits several sub- delegated-prefix lengths. SAM INTERIOR ADDRESS - IPv4 format constant ID prefix (optional) host ID | | | | | subnet | | | ID | | | (s may be 0) | | | | | V V V V <------c-----><-s-> <-h-> <--------------- 32 ---------------> +-------------+---+----+-------+----+ | C |"F"|XXXX| 0 |XXXX| +-------------+---+----+-------+----+ Format /\ | | | / / Parameters || | | | ___/ / F, C, s, h || | | | / ___/ \/ | | |/ / +---+----+----+ |"F"|XXXX|XXXX| +---+----+----+ <---- s+h ----> SAM INTERIOR ID MAPPING BETWEEN SAM INTERIOR ADDRESSES AND SAM INTERIOR IDs IN IPv4 Despres Expires April 29, 2010 [Page 15] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Figure 6 Because of this lack of flexibility of IPv4 SAM interior addresses, IPv6 should be used for SAM interior addresses if both IPv6 and IPv4 are possible. 6. SAM Prefixes and SAM Raw Prefixes An important feature of SAM is that the free hierarchical structure of addresses, which has been advantageously introduced in IPv4 with the classless inter-domain routing of [RFC1519] (CIDR), is generalized: in IPv4, where it currently applies only to the 32-bits of IPv4 addresses, it is extended to 48 bits with port-extended IPv4 addresses; in IPv6, where it currently applies only to the first 64 bits of IPv6 addresses, it is first extended to their full 128 bits, and then to 144 bits with port-extended IPv6 addresses. This flexibility in prefix lengths considerably extends the possibility to organize routing domains in a hierarchical setup. Each domain receives delegated prefixes from its provider-side domains, and assigns sub-delegated prefixes to its customer-side domains. Some precautions are however necessary, due to format constraints which exist on IPv6 addresses [RFC4291] and on port numbers [RFC1700]. Concerning IPv6 address formats, there is an ongoing debate about accepting, or not, that subnet prefixes of IPv6 addresses that never appear directly as destinations on IPv6 links might be extended beyond 64 bits, with any value in 9th octet. (For example, ISATAP addresses of [RFC5214] are such IPv6 addresses. They do comply with the 9th octet constraint of [RFC4291] but, with the freedom under discussion, they could have been specified without it). The only technical reason known by the author against this new freedom on IPv6 address formats relates routing-loop-attack prevention. (These attacks have been found to be possible with some ISATAP and 6to4-relay routers. It was first documented on July 16 2009 by Gabi Nakibly in an e-mail to the v6ops mailing list. It is still unclear whether the 9th octet constraint is useful to prevent some of these attacks or not). By precaution, we assume in this draft that the 9th octet constraint still holds. If it can be relaxed, some of the complexity introduced below to distinguish SAM raw prefixes from SAM prefixes can disappear. Despres Expires April 29, 2010 [Page 16] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Concerning port-number prefixes used as address extensions, they must exclude the well-known-ports range 0-1023 of [RFC1700] because it has specific interpretations in firewalls and in hosts. For this reason, ports prefixes used for address extension will have their first bit always set to 1. IPv6 SAM PREFIX up to 64 bits +------------+-------------------+ |XXXXXXXXXXXX|...................| IPv6 ADDRESS +------------+-------------------+ (128 bits) : : +------------+ |XXXXXXXXXXXX| +------------+ IPv6 SAM RAW PREFIX up to 64 bits IPv6 SAM PREFIX up to 128 bits <----- 64 -----><8><----> +---------------+--+-----+-------+ |XXXXXXXXXXXXXXX|FF|XXXXX|.......| IPv6 ADDRESS +---------------+--+-----+-------+ (128 bits) : : / / : :/ / +---------------+-----+ |XXXXXXXXXXXXXX |XXXXX| +---------------+-----+ IPv6 SAM RAW PREFIX up to 120 bits IPv6 SAM PREFIX up to 144 bits <----- 64 -----><8><--- 56 ----><1><> +---------------+--+-------------+-+--+---+ IPv6 ADDRESS |XXXXXXXXXXXXXXX|FF|XXXXXXXXXXXXX|1|XX|...| + PORT +---------------+--+-------------+-+--+---+ (144 bits) : : / / / / : :/ / / / : : : / / : : :/ / +---------------+-------------+--+ |XXXXXXXXXXXXXXX|XXXXXXXXXXXXX|XX| +---------------+-------------+--+ IPv6 SAM RAW PREFIX up to 135 bits 1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv6 Despres Expires April 29, 2010 [Page 17] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Figure 7 To deal with the above format constraints, a distinction is made between "SAM raw prefixes", and "SAM prefixes": o SAM raw prefixes are fully hierarchical, like classical CIDR prefixes, with all their bits permitted to have any values. o SAM prefixes, which may span all bits of A+P locators, have some fixed fields to be complied with if they are long enough to reach these fixed fields. Detailed mappings between SAM prefixes and SAM raw prefixes are shown in Figure 7 and Figure 8, for IPv6 and IPv4 respectively. IPv4 SAM PREFIX up to 32 bits +------------+-----+ |XXXXXXXXXXXX|.....| IPv4 ADDRESS +------------+-----+ (32 bits) : : +------------+ |XXXXXXXXXXXX| +------------+ IPv4 SAM RAW PREFIX up to 32 bits IPv4 SAM PREFIX up to 48 bits <------- 32 ------><1><-> +------------------+-+---+--+ IPv4 ADDRESS |XXXXXXXXXXXXXXXXXX|1|XXX|..| + PORT +------------------+-+---+--+ (48 bits) : :/ / : : / : : : : : : +------------------+--+ |XXXXXXXXXXXXXXXXXX|XX| +------------------+--+ IPv4 SAM RAW PREFIX up to 47 bits 1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv4 Figure 8 Despres Expires April 29, 2010 [Page 18] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 7. Derivation of Sub-delegated prefixes from Delegated Prefixes and Interior IDs Raw sub-delegated prefixes are built, in each SAM domain, according to the CIDR principle: each domain in the hierarchy adds its SAM interior ID to its raw delegated prefixes. Actual sub-delegated prefixes are then derived from raw sub-delegated prefixes as detailed in Section 6. Figure 9 shows successive steps of sub-delegated- prefix constructions. IPv4 or IPv6 +--------------+ | INTERIOR ID | +--------------+ IPv4 or IPv6 | || : +------------------------+ || : | a DELEGATED PREFIX | || : +------------------------+ || : : || : || : : \/ : || : +------------------------+ || : | its derived RAW PREFIX | || : +------------------------+ || : : || : || : : \/ : \/ : +---------------------------------------+ | the derived SUB-DELEGATED RAW PREFIX | +---------------------------------------+ : || : : \/ : +---------------------------------------+ | the derived SUB-DELEGATED PREFIX | +---------------------------------------+ IPv4 or IPv6 1:N MAPPING BETWEEN INTERIOR IDs AND DELEGATED PREFIXES Figure 9 Despres Expires April 29, 2010 [Page 19] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 8. Mapping from Source and Destination Endpoint Locators to Source and Destination Interior Addresses 8.1. Encapsulation Function In the encapsulation function of a SAM, the following rules govern how source and destination addresses of encapsulating packets are derived from source and destination locators found in packets to be encapsulated: PROVIDER-SIDE-SAM ENCAPSULATION 1. The source locator MUST NOT match any delegated prefix of this SAM (spoofing prevention), and the destination locator MUST match one of them (there is upstream a routing-configuration error if it doesn't). 2. In the destination locator, an interior ID MUST be extractible from bits that follow the prefix of this SAM that is matched. The destination interior address is then derived from this interior ID, and the source interior address is the interior address of this SAM. CUSTOMER-SIDE-SAM ENCAPSULATION 1. The source locator MUST match a sub-delegated prefix of this SAM (spoofing prevention), and the destination locator MUST NOT match any of them (there is upstream a routing-configuration error does match). 2. If the destination locator matches a delegated prefix of the SAM domain, an interior ID MUST be extractible from bits that, in this destination locator, follow the matched delegated prefix. The destination interior address is then derived from this interior ID, and the source interior address is the SAM interior address of this SAM. 3. If the destination locator doesn't match any delegated prefix of the SAM domain, the destination interior address is that of the provider-side SAM that has, among its delegated prefixes, one that matches the source locator. The source interior address is the interior address of this provider-side SAM. Despres Expires April 29, 2010 [Page 20] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 8.2. Decapsulation Function In the decapsulation function of a SAM, the following rules have be complied with to ensure that source and destination addresses of encapsulating packets and source and destination locators of encapsulated packet are valid. (They have to be consistent both among themselves and with parameters of the SAM.) PROVIDER-SIDE-SAM DECAPSULATION 1. The source locator MUST match a delegated prefix of this SAM (spoofing prevention), and the destination locator MUST NOT match any of them (there is upstream a routing-configuration error if it does match). 2. An interior ID MUST be extractible, in the source locator, from its bits that follow the matched delegated prefix. The source interior address MUST be the SAM interior address which is derived from this interior ID. (This check makes it impossible that a packet coming from another provider-side SAM be accepted, the interior address of this other SAM being different from any SAM interior address. Routing-loop attacks are thus prevented). The destination interior address MUST be this SAM's interior address. CUSTOMER-SIDE-SAM DECAPSULATION 1. The source locator MUST NOT match any sub-delegated prefix of this SAM (spoofing prevention), and the destination locator MUST match one of them (there is upstream a routing-configuration error if it doesn't). 2. If the source locator matches a delegated prefix of the SAM domain, an interior ID MUST be extractible from this source locator in bits that follow the matched delegated prefix. The source interior address MUST be that which is derived from this interior ID, and the destination interior address MUST be the interior address of this SAM. 3. If the source locator doesn't match any delegated prefix of the SAM domain, the destination locator MUST match one of the sub- delegated prefixes of the SAM, and the source interior address MUST be that of a provider-side SAM whose delegated prefix is at the beginning of this sub-delegated prefix. The destination interior address MUST be the interior address of this SAM. Despres Expires April 29, 2010 [Page 21] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 9. Detailed Prefixes for the Example Scenarios We now return to the two scenarios of Section 2 to show how the described SAM mechanisms can deliver what was claimed. INTERNET ISP NETWORK BACKBONES | 2001:a::/32 | V | V +-------------------------+ | +--------- | IPv6 & private IPv4 | | | | |<=== | | 0::/0 ===>+-------+ IPV6 | | | | | | CUSTOMER-EDGE | | +--------- NODES | link 5 | | | 2001:a:50000::/64 (198.0.0.0/20):(0/1) V | 10.0.0x50.0x44 | / +------------+ | | +-------+ / | dual stack | | | | |/ +--------- | +------+------+--+ 0../0 ===>| NAT44 / | | | SAM |<--- | | | /| | | |<=== |<--- | | +-------+-------+ IPV4 | | | | | | | |<=== | +-----+--|---+ | | --->| SAM | | | | | | | | | | +--------- | | +---------------|-+-------+ | | | \ | | 2001:a:5000:0:ff00::222 | | | (SAM autoconf on link 5) | 198.0.0.0/20 | 10.0x52.0x22.0 (DHCPv4) | | | | | 2001:a:5222::/48 2001:a:0000:0: 198.0.1.0x22:(0b10010/5) (autoconf on link 0) SAM interior-address format: C=2001:a::/32; F=0/0; s=4; h=12 Number of customer sites: 64K NAT44 external ports : 2K / customer site IPv4 assigned ports : 2K / customer site (IPv6 assigned ports : 64K / customer site) EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 1 Despres Expires April 29, 2010 [Page 22] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Figure 10 Figure 10 and Figure 11 respectively deal with the small ISP scenario of Section 2.1 and with the customer site scenario of Section 2.2. LAN 10.0.0x54.0x44 2001:a:5222:0::/64 198.0.1.0x22:(0b100100/6) 192.168.0.0/24 | | | | CUSTOMER-EDGE ROUTER | | +---------------|----+ SAM | | +-------+ | | HOSTS | | | | / | | | | ==>| NAT44 |/ | V | | | | | +-------+ +-------+-------+--------- +------------+ | --->| | | ISP |<--- | dual stack | | ===>|--->| SAM | SAM |<--- | +-----+-------------+ | | | |<=== | | | | SAM |<=== | | +----+-------+--|----+ | | |<=== |<--- | | | \ | | | |<--- | | | | +------+--|--+ | | 2001:a:5222::/48 | | | | 198.0.1.0x22:(0b10010/5) | | | | | | | 2001:a:1222:0: /64 | | | (autoconf) | | | 0.0.0.0/0 | | | | | 2001:a:5222:0::/64 (RA) | | 2001:a:5222:0:ff00::3 2001:a:5000:0:ff00::222 | (SAM autoconf) (SAM autoconf) | 192.168.0.x (DHCPv4) 10.0.0x54.0x44 (DHCPv4) | 2001:a:1222:3000::/51 198.0.1.0x22:(0b1001010011/10) SAM interior-address format: C=2001:a:5222::/48; F=0/0; s=0; h=4 Number of SAM hosts : 16 NAT44 shared external ports via ISP-NAT : 4K / host NAT44 shared external ports on a global add : 64 / host IPv4 assigned ports : 64 / host EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 2 Figure 11 Despres Expires April 29, 2010 [Page 23] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 10. Applicability to other scenarios SAM can be used across ISP networks that route exclusively in IPv6 like those of in [IVI]. With SAM, IPv4 end-to-end transparency, port extended or not, can be offered as an additional possibility to IVI customers that are SAM-capable (with IPv4 packets encapsulated in IPv6 packets). Other SAM scenarios, which are numerous, are beyond the scope of this particular version of the draft. Some should be added in later versions. 11. Security considerations Provided all address checks of Section 8 are performed, as required by this specification, no new security risk has been identified. 12. IANA Considerations The SAM tag in the 9th octet of IPv6 addresses, used to distinguish SAM interior addresses from other IPv6 addresses, should in due time be registered by IANA. Also, if an when detailed formats for SAM-specific DHCP options are agreed on, they will have to be submitted to IANA. 13. Acknowledgments This specification is mostly the result of a personal effort of the author, in continuation with what he did for 6rd [Free's IPv6 in 2007], but high recognition is due to Mark Townsley who listened to intermediate stage presentations, provided useful reactions, and was a convincing advocate for a Cisco Research Grant to be allocated to Telecom Bretagne, for a validation of a subset of SAM. Special thanks are also due to Laurent Toutain. After having seen SAM's potential, he planned an experiment with students at Telecom Bretagne. Dave Thaler made a precious detailed review of an earlier draft. Beyond this, the open discussion environment of IETF in general has been a continuous encouragement. Despres Expires April 29, 2010 [Page 24] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 14. References 14.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. [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. 14.2. Informative References [-SAM-02] Despres, R., "Stateless Address Mapping (SAM) - Avoiding NATs and restoring the end-to-end model in IPv6", March 2009. [-SAM-03] Despres, R., "Scalable Multihoming across IPv6 Local- Address Routing Zones - Global-Prefix/Local-Address Stateless Address Mapping (SAM)", July 2009. [6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider Networks, draft-ietf-softwire-ipv6-6rd", August 2009. [A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage - draft-ymbk-aplusp-04", July 2009. [DSlite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion - draft-ietf-softwire-dual-stack-lite-01", July 2009. [DnsAttack] Friedl, S., "An Illustrated Guide to the Kaminsky DNS Vulnerability - http://unixwiz.net/techtips/ iguide-kaminsky-dns-vuln.html", August 2008. [Free's IPv6 in 2007] Despres, R., "IPv6 Rapid Deployment on IPv4 infrastructures (6rd) - draft-despres-6rd-03", April 2009. Despres Expires April 29, 2010 [Page 25] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 [Frmwk-trans] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 Translation - raft-baker-behave-v4v6-framework-02", February 2009. [IVI] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 - Coexistence and Transition - draft-xli-behave-ivi-02", June 2009. [Ipv4Shortage] Levis, P., Boucadair, M., Grimault, JL., and A. Villefranque, "IPv4 Shortage: Needs and Open Issues - draft-levis-behave-ipv4-shortage-framework-01", March 2009. [PRR] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "Pv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture - draft-boucadair-port-range-02", July 2009. [PrefSubDeleg] Baker, F., "Prefix Sub-delegation in a SOHO/SMB Environment - draft-baker-ipv6-prefix-subdelegation-00", July 2009. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. Despres Expires April 29, 2010 [Page 26] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 [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. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [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) - Publication delayed since May 2009 for a reason common to all independent-submission RFCs". Despres Expires April 29, 2010 [Page 27] Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Author's Address Remi Despres 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires April 29, 2010 [Page 28]