Internet Engineering Task Force R. Despres Internet-Draft October 19, 2009 Intended status: Standards Track Expires: April 22, 2010 Mesh Softwire Solution without BGP and with Stateless Address Mapping (SAM) draft-despres-softwire-mesh-sam-00 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 22, 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 mechanism for packets whose addresses are in an address family to traverse routing domains where this address family Despres Expires April 22, 2010 [Page 1] Internet-Draft Mesh Softwire with SAM October 2009 is not directly supported. Its topological scenarios are in the defined as mesh softwire class, i.e. with point to multipoint tunnels between border nodes so that packets never need to traverse softwire domains twice. SAM exterior to interior address mappings are stateless, i.e; such that border nodes don't need to maintain states about other border nodes. While 6to4, ISATAP, and 6rd, are already solutions for IPv6 tunnels across IPv4 domains, SAM supports all IPvX across IPvY combinations. Also, to mitigate consequences of the IPv4 address shortage during the transition-to-IPv6 period, SAM supports, for protocols that have ports to designate connection endpoints, port-extended IPv4 addresses. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 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. SAM terminology . . . . . . . . . . . . . . . . . . . . . . . 8 4. SAM functional sub-modules and their parameters . . . . . . . 10 5. Mapping from SAM Interior Addresses to SAM short IDs . . . . . 12 5.1. IPv6 Interior Addresses . . . . . . . . . . . . . . . . . 13 5.2. IPv4 Interior Addresses . . . . . . . . . . . . . . . . . 14 6. Mappings between SAM Prefixes and Raw Prefixes . . . . . . . . 15 7. Derivation of Sub-delegated prefixes from Short IDs and Received Prefixes . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 20 9. Detailed Prefixes for the Example Scenarios . . . . . . . . . 21 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 22, 2010 [Page 2] Internet-Draft Mesh Softwire with SAM October 2009 1. Introduction The Softwires Working Group is in charge of standardizing "discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks". The two topological scenarios to deal with are identified in [RFC4925]: o "Hubs and Spokes" targets carriers, or large enterprise networks acting as carriers, that operate Centralized Softwire Concentrators and use only point-to-point tunnels. o "Mesh" concerns networks across which border routers communicate via point-to-multipoint tunnels so that no packet has to traverse these networks twice. covers The particular mesh scenario described in [RFC5565] concerns carriers, or large enterprise networks acting as carriers, all border routers of which support a common exterior Border Gateway Protocol (e-BGP). This draft deals with a complementary mesh scenario, suitable in particular for small and medium enterprises and small to medium Internets service providers (ISPs) that don't operate centralized software concentrators, for which supporting of a common e-BGP in all border routers in not practicable, and for which stateless operation is preferred for scalability and operational simplicity reasons. (Stateless means here that border routers don't need to maintain states about other border routers, a meaning similar to that used in Stateless DHCP [RFC3736]). SAM principles are an extension of principles already put in practice in real deployments with 6to4 [RFC3056], ISATAP [RFC5214], and in 6rd [RFC5569] [6rd]. They all support IPv6 across IPv4 routing domains, encapsulate IPv6 packets in IPv4 packets, and statelessly derive interior addresses from exterior addresses. SAM extends these solutions in the following directions: o other encapsulations than just IPv6/IPv4 o provisions to maintain site to site transparency in IPv4 despite the IPv4 address shortage o autoconfiguration of sub-delegated prefixes o generalized multihoming support, with compatibility with ingress filtering in ISP networks. SAM has also various commonalities with some earlier proposal like ENCAPS (RFC 1955 in 1996), GSE (draft-ipng-gseaddr-00 in 1997), DSTM Despres Expires April 22, 2010 [Page 3] Internet-Draft Mesh Softwire with SAM October 2009 (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). It has however a different scope from all of them. In particular, while LISP is based on an Endpoint Identifier space separate from the Routing Locator space, and necessitates tunnels across the Internet core, SAM only uses global addresses end-to end, across some intermediate tunnels, thus avoiding the need for encapsulation in the Internet core, which facilitates incremental deployment. With protocols such as SCTP [RFC3286] and Shim6 [RFC5533], which specify how to use to multiple addresses in host endpoints, SAM, which introduces additional ways to assign multiple addresses to hosts, is complementary. This draft is an evolution from [SAM-02] and [SAM-03]. The former was focused on how NATs might be totally dispensed with in the long term if SAM would be generalized (somewhat theoretical). The latter was limited to how SAM supports multihoming of sites having private internal addressing in IPv6 (practical, but too restricted). This one is focused on what SAM can provide in the short term for various incremental deployments (more practical and more open). It also introduces some technical improvements and, the author believes, substantial clarifications. The proposed specification, is the result of a long series of alternating attempts at generalization and at simplification. It is intended to be at this stage complete enough to permit compatible of independent implementations, except for DHCP option formats are not specified yet. Being new, the specification is likely to have remaining clumsiness and even, the Devil being in details, to be bugged. Corrections and improvements are expected to be necessary after discussions and further work. Implementation of a subset of this specification is under way at Telecom Bretagne, in view of a first experimentation. 2. Example Scenarios To mitigate consequences of the IPv4 address shortage during the transition-to-IPv6 period, diverse solutions have being studied for different scenarios: [TransFrmwk] and [DSlite] are based on ISP supported NATs (CGNs); [PRR] and [A+P] make CGNs less necessary for various hub and spoke configurations and are based on dynamic reservation of port ranges (i.e. with stateful mappings). Despres Expires April 22, 2010 [Page 4] Internet-Draft Mesh Softwire with SAM October 2009 In the two chosen SAM scenarios below, a complementary approach to the IPv4 address shortage problem is described. On various mesh softwire topologies, they support port-extended IPv4 addresses, with statelessly reserved port prefixes. For legacy hosts that don't support SAM, these scenarios also include NAT-based dynamic address sharing. SAM's applicability is much larger than described with these two scenarios, but they are chosen to show the potential of stateless solution for mesh topologies to solve the IPv4 address shortage problem in some typical scenarios. 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, this ISP can support up to 64K customers. Now, due to the IPv4 address shortage, it has only a /20 IPv4 prefix, which means a maximum of 4K global IPv4 addresses, not enough to assign one to each customer. IPv4 address need therefore to be shared, either dynamically for an optimized multiplexing efficiency, or statically so that assigned addresses and ports can be advertised outside, typically for server or peer-to-peer applications that need incoming connections. For legacy hosts that support only IPv4, the ISP operates a CGN that works as an IPv4 to IPv4 NAT (NAT44), and also assigns to its customers private IPv4 addresses 10.0.0.0/8 [RFC1918]. These addresses are obtained by CEs in DHCP [RFC2131]. In this scenario, the ISP assign to its CGN ports 0 to 32K - 1 of all its IPv4 addresses, and reserves ports 32K to 64K - 1 of the same addresses for the port-extended IPv4 addresses. Despres Expires April 22, 2010 [Page 5] Internet-Draft Mesh Softwire with SAM October 2009 INTERNET SubnetPrefix/64 (RA) BACKBONES IPv6-Add (autoconf) | PrivIPv4-Add (DHCPv6) IPv6-Pref/32 | | | V CUSTOMER-EDGE | | NODES (CEs) | +-------------------------+ | +--------- | | | ISP NETWORK | | | V | | IPv6 & private IPv4 |<=== | +------------+<=== | +-------+ IPV6 | dual stack |<--- | | | | +------+ | | | | | | +--------- +------------+ | | | | +------------+ | +-------+ | dual stack | | | CGN | +--------- | +------+------+ | NAT44 | | | | SAM |<=== | | | | | |<=== |<--- | +-------+-------+ IPV4 | | | | | | | |<=== | +-----+--|---+ | | | SAM | | | | | | | | | +--------- | | +-----------------+-------+ | | | | SubnetPrefix/64 (RA) | | IPv6-Add (autoconf) IPv4-Pref/20 | PrivIPv4-Add (DHCPv6) | 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 in Section 2.1, dual-stack CEs can then each obtain a shared global IPv4 address with 2K reserved ports (in addition to the possibility to use the CGN like any IPv4-capable CE). Each CE has total freedom to use its reserved ports ports its own Despres Expires April 22, 2010 [Page 6] Internet-Draft Mesh Softwire with SAM October 2009 way, and can take advantage of the end-to-end Internet transparency they make possible. In the scenario of the next section, we describe one particular way way to use them in a customer site. 2.2. A small customer site having only a port-restricted IPv4 address Figure 2 shows the configuration of this second scenario which can be seen as a continuation of the previous one, this time in a customer site. The considered site is that of a residential customer, or that of a small office/home office, where the number of hosts is below 16. Only one LAN is deployed (possibly with bridges between different physical media like copper wires, Wifi, or power-lines). The CE router and some hosts supports SAM. For legacy hosts that are IPv4-only, the CE router supports a DHCP server which assigns private IPv4 addresses in the 192.168.0.0/24 range, and supports a NAT44. This NAT uses ports 4K to 64K - 1 on the private-IPv4 address 10.0.x.x of the site. It also uses the lower half of the 1K reserved ports on the global IPv4 address of the site. With these, it can assign ports to port forwarding, possibly with a dynamic reservation protocol such as NAT-PMP or UPnP. In addition to possibilities of other hosts, SAM-capable hosts are automatically assigned /52 IPv6 prefixes. They they may use them freely, for example to run a small LANs behind them, e.g. in Bluetooth, and offer global IPv6 addresses on these LANs. In IPv4, each SAM-capable host is automatically assigned 32 of the reserved ports of the site, to be used with the assigned global IPv4 address. It can use it its own way, in particular to advertise ports on which server and peer-to peer applications are reachable, and/or to further distribute these reserved ports on a LAN behind it. Note that for outgoing connections to IPv4-only servers whose protocols are known to traverse NATs without problem, e.g. for Web requests (remote port 80) and DNS queries (remote port 53), the private IPv4 address with its 64K ports can be used. This leaves more reserved ports for applications that may have problems with NATs. Note that, in the case of the DNS, a known advantage of traversing NATs is that used external ports are less predictable, which is a good precaution to prevent the possible DNS attack identified by Dan Kaminsky [DnsAttack]. Despres Expires April 22, 2010 [Page 7] Internet-Draft Mesh Softwire with SAM October 2009 SubnetPrefix/64 (RA) IPv6-Add (autoconf) PrivIPv4-Add (DHCPv6) HOSTS | SubnetPrefix/64 (RA) | | LAN IPv6-Add (autoconf) | | IPv6 & private IPv4 PrivIPv4-Add (DHCPv6) v | | | +------------+ | | CUSTOMER-EDGE ROUTER (CE) | | dual stack |<=== | +--------------------+ | | only |<--- | | | | | |<--- | | +-------+ | | | +-------------+ | | | | <=== | | | | | NAT44 | | <--- +------------+ | | | | | <--- +-------+ +-------+-------+--------- +------------+ | | | SAM | SAM | | dual stack | | | | |<=== | | +-----+-------------+ | | | | | | | SAM |<=== | +----+-------+--|----+ | |<=== |<--- | | | | | |<--- | IPv6-Pref/48 +------+--|--+ | | IPv4-Add:(PortPref/5) | | | | | SubnetPrefix/64 (RA) | IPv6-Add (autoconf) | PrivIPv4-Add (DHCPv6) | IPv6-Pref/52 V4-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 : 32 / host A SMALL CUSTOMER SITE HAVING A PORT-RESTRICTED IPV4 ADDRESS Figure 2 3. SAM terminology In the SAM model, illustrated in Figure 3, SAM functional modules 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 Despres Expires April 22, 2010 [Page 8] Internet-Draft Mesh Softwire with SAM October 2009 domain (provided their source and destination "endpoint locators", have values that don't endanger security). <---- EXTERIOR ---><-------- INTERIOR --------><-- EXTERIOR ---> CONSUMER SIDE PROVIDER SIDE SUB-DELEGATED RECEIVED 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 COMPONENTS AND TERMINOLOGY Figure 3 An endpoint locator can be just a global-IPv4 or global-IPv6 address, or in a domain where there are not enough global IPv4 addresses, an address plus a port number. In these latter domains, endpoints exist only for connections that use ports (TCP, UDP, DCCP, SCTP) and for ICMP error messages that contain headers of packets of such Despres Expires April 22, 2010 [Page 9] Internet-Draft Mesh Softwire with SAM October 2009 connections. If a SAM functional module (or just "a SAM" for short) is assigned at its exterior interface one or several "received" prefixes, this side of the SAM domain is called one of its "provider-sides" (in simple scenarios, there is typically only one) If, conversely, a SAM functional module delegates at its exterior interface some prefixes, this exterior side is called one of its "consumer-sides", and these prefixes are called "sub-delegated prefixes" (they are derived from the received prefixes of the SAM domain by appending to them the a short ID which identifies this SAM in the domain). Received and sub-delegated prefixes, which are prefixes of endpoint locators, can be port-extended (in IPv6 as well as in IPv4 for generality, and to permit to deploy IPv6 LANs behind hosts that have obtained IPv6 addresses but no prefixes). 4. SAM functional sub-modules and their parameters Sub-modules of customer-side SAMs and of provider-side SAMs are shown in Figure 4. A customer-side SAM has a DHCP client to obtain SAM parameters of its domain. DHCPv6 is used if IPv6 interior addresses are available, IPv4 DHCP otherwise. The SAM stateless autoconfiguration sub-module of a customer-side SAM is in charge of building its SAM interior address. This address conforms to the current SAM interior address format of the SAM domain, received in DHCP. (if two such formats are received, one of them must be in the deprecated state). This format is such that the short ID of a SAM, which identifies it in its SAM domain with a number of bits typically smaller than that of a full address, can be derived from the interior address of this SAM. In IPv4, the autoconfiguration is based on [RFC3927], extended to support addresses that are not only link-local. The SAM map&encap sub-module is present in all SAMs, customer-sides and provider-sides. It is in charge of checking that exterior source and destination locators in packets it receives on either of its interfaces are consistent with parameters of the traversed SAM, and checking in packets received from the interior that source and destination interior addresses of encapsulating packets are consistent with exterior source and destination addresses of encapsulated packets. If these checks don't fail, packets are Despres Expires April 22, 2010 [Page 10] Internet-Draft Mesh Softwire with SAM October 2009 encapsulated as specified in [RFC4213] in the exterior-to-interior direction, and are decapsulated in the interior-to-exterior direction. The DHCP server sub-module is, at least as far as SAM is concerned, stateless (it doesn't need to maintain states about customer-side SAMs). It is in charge of transmitting SAM parameters of the SAM domain to customer-side SAMs that query it. These parameters are those that have been collected by the SAM-parameter gatherer sub- module. The SAM-parameter gatherer sub-module makes a synthesis of: o parameters that are received for the exterior interface of the SAM, i.e. delegated prefixes; o parameters that are administratively configured for this SAM, i.e. formats of SAM interior addresses and, in case of multi-homing, the list of interior addresses of other provider-side SAMs; o parameters that are obtained by the DHCP multiple client sub- module. The SAM-parameter gatherer module queries stateless DHCP servers of other provider-side SAMs, and merges them. It checks that interior- address formats are consistent (identical if they have the same format ID). 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, used as an anycast address. Despres Expires April 22, 2010 [Page 11] Internet-Draft Mesh Softwire with SAM October 2009 CUSTOMER-SIDE SAM <- exterior interior -> +-----------------+ | +-------------+ | | SAM PARAMETERS | | DHCP client | |<=== | (obtained from a provider SAM) | +-------------+ | | | SAM | | | | stateless | | | | autoconfig | | | +-------------+ | PROVIDER-SIDE SAM | | SAM | | | | map & encap | | <-- interior exterior --> | +-------------+ | +-------------------+ +-----------------+ | +---------------+ | | | stateless | | SAM PARAMETERS | <====| | DHCP server | | (sent to requesting consumer SAMs) | | +---------------+ | * Interior parameters | | | 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 ptovider SAMs) | ===>| | multiple | | | | client | | Configured parameters: | +---------------+ | * SAM interior address format(s) |---.->| | * interior addresses of provider SAMs | / +-------------------+ \ '----- delegated prefixes SAM FUNCTIONAL MODULES AND THEIR PARAMETERS Figure 4 5. Mapping from SAM Interior Addresses to SAM short IDs A key feature of SAM is that, given an interior-address format, there is a 1:1 correspondence between the interior address of a SAM and its short ID. An interior-address format has the following sub-parameters: Despres Expires April 22, 2010 [Page 12] Internet-Draft Mesh Softwire with SAM October 2009 o A "format ID". If the SAM domain has several interior-address formats, this ID in its interior addresses and in its short IDs. If two format IDs have different lengths, they must not be overlapping prefixes: for example, 01 and 011 are not permitted to coexist, while 0, 100, 1O1, 110, 1110, and 1111 may coexist. o A constant prefix "C". In SAM domains that use private address spaces, it can be for example 10.0.0.0/8 in IPv4 [RFC1918], or a /48 prefix randomly selected for Unique Local IPv6 addresses in the SAM domain (ULAs of [RFC5375]). If specified to be so, it can also be one of the received prefixes of the SAM domain. In this case the interior address space is a global address space, and tunnels are established only for addresses that don't start with this particular prefix. o The length "s" of subnet IDs. If a SAM domain that has several links with different subnet prefixes, bits that, after the constant prefix, distinguish these subnets are called the "subnet ID". In a site with only one link, subnet IDs are not needed and s can be 0. o The length "h" of "host IDs". 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 must have different host IDs. 5.1. IPv6 Interior Addresses Figure 5 shows how the 1:1 correspondence between SAM interior address and short ID works for IPv6 interior addresses. A SAM tag is necessary to distinguish SAM interior addresses from addresses of legacy IPv6 nodes that are on the same link. It needs for this to have the two lower bits in the 9th octet of the address different from all currently specified IPv6 addresses, i.e. these "u" and "g" bits must be both set to 1 [RFC4291]. Other bits of this octet are proposed to be all set to 1 to keep an escape mechanism for future new IPv6 address formats. Despres Expires April 22, 2010 [Page 13] Internet-Draft Mesh Softwire with SAM October 2009 SAM INTERIOR ADDRESS - IPv6 constant prefix subnet ID SAM format ID host ID | (s may be 0) tag | (optional) | | | | | | V V V V V <----------c---------><--s-> <-8-> <--h---> <------------- 64 -------------><------------- 64 -------------> +---------------------+-----+---+----+---+--------------+------+ | "C" |XXXXX| 0 |0xFF|XXX| 0 |XXXXXX| +---------------------+-----+---+----+---+--------------+------+ | | / / / / Format /\ |_____|______/ / / / Parameters || / __|_________/ / / "C", "F", s, h || /| / | _____________________/ / || / | / | / _____________________/ \/ / |/ |/ / +---+-----+------+ |XXX|XXXXX|XXXXXX| +---+-----+------+ <---- f+s+h ----> SAM SHORT ID 1:1 MAPPING BETWEEN SAM INTERIOR-ADDRESSES AND SAM SHORT IDs IN IPv6 Figure 5 5.2. IPv4 Interior Addresses Figure 6 shows how the 1:1 correspondence between SAM interior address and short ID works for IPv4 interior addresses. IPv4 should be used for SAM interior addresses only in cases SAM domains where IPv6 is not directly routed. In these addresses, there is not, like in IPv6, a place to put the format ID without interfering with the place of subnet IDs. If there is only one link, s must be 0 and the format ID field can be used to identify several host ID lengths. If there are several links, there must be only one format, with unique values of s and h. Despres Expires April 22, 2010 [Page 14] Internet-Draft Mesh Softwire with SAM October 2009 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" |XXX|XXXX| 0 |XXXX| +-------------+---+----+-------+----+ Format /\ | | | / / Parameters || | | | ___/ / "C", f, s, h || | | | / ___/ \/ | | |/ / +---+----+----+ |XXX|XXXX|XXXX| +---+----+----+ <---- s+h ----> SAM SHORT-ID 1:1 MAPPING BETWEEN SAM INTERIOR-ADDRESSES AND SAM SHORT IDs IN IPv4 Figure 6 6. Mappings between SAM Prefixes and Raw Prefixes An important feature of SAM is that the free hierarchical structure of addresses, introduced in IPv4 with CIDR [RFC1519], is extended. In IPv4, where it currently it applies to the 32 bits of IPv4 addresses, it is extended to the 48 bits of port extended IPv4 addresses. In IPv6, it is extended from it's current 64 bits of subnet prefixes to the full 128 bits of IPv6 addresses, and even to the 144 bits of port-extended IPv6 addresses. Despres Expires April 22, 2010 [Page 15] Internet-Draft Mesh Softwire with SAM October 2009 Some precautions are however necessary to respect existing format constraints on port numbers and on IPv6 addresses: o Port numbers whose prefixes are used as address extensions must not belong to the well-known port range 0-1023, and even to the 0-4095 range reported to be avoided by Windows for dynamically assigned ports (otherwise firewalls at either end of transport connections could interfere). For this reason, ports whose prefixes are used for address extension have their first bit always equal to 1. o In IPv6, there has been a debate about the possibility to freely extend hierarchical prefixes beyond 64 bits, with for this a relaxation of the constraint on u and g bit values in the two lower bits of the 9th octet. It now appears that this should be avoided for at least one reason: the protection against routing- loop attacks that have been found to be possible possible with some ISATAP routers and 6to4 relay routers (a debate on the v6ops mailing list was started on July 16 2009 by Gabi Nakibly on this subject). Despres Expires April 22, 2010 [Page 16] Internet-Draft Mesh Softwire with SAM October 2009 IPv4 SAM PREFIX up to 32 bits +------------+-----+ |XXXXXXXXXXXX|.....| IPv4 ADDRESS +------------+-----+ : : +------------+ |XXXXXXXXXXXX| +------------+ SAM RAW PREFIX up to 32 bits IPv4 SAM PREFIX up to 48 bits <------- 32 ------><1><- 15-> +------------------+-+---+--+ IPv4 ADDRESS |XXXXXXXXXXXXXXXXXX|1|XXX|..| & PORT PREFIX +------------------+-+---+--+ : :/ / : : / : : : : : : +------------------+--+ |XXXXXXXXXXXXXXXXXX|XX| +------------------+--+ SAM RAW PREFIX up to 47 bits 1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv4 Figure 7 To deal with these constraint, a distinction is made between "SAM prefixes", and "raw prefixes". SAM prefixes may span all bits of addresses and port numbers, but have some fixed fields, with in IPv4 the 33rd bit set to 1, and in IPv6 the 9th octet set to 0xFF. Raw prefixes are fully hierarchical like in CIDR, with all bit having any values, but with lengths smaller than those of SAM prefixes, in IPv4 by one bit, and in IPv6 by 8 bits. Despres Expires April 22, 2010 [Page 17] Internet-Draft Mesh Softwire with SAM October 2009 IPv6 SAM PREFIX up to 64 bits +------------+-------------------+ |XXXXXXXXXXXX|...................| IPv6 ADDRESS +------------+-------------------+ : : +------------+ |XXXXXXXXXXXX| +------------+ SAM RAW PREFIX up to 64 bits IPv6 SAM PREFIX up to 128 bits +---------------+--+-----+-------+ |XXXXXXXXXXXXXXX|FF|XXXXX|.......| IPv6 ADDRESS +---------------+--+-----+-------+ : : / / <----- 64 ----->:/ / +---------------+-----+ |XXXXXXXXXXXXXX |XXXXX| +---------------+-----+ SAM RAW PREFIX up to 120 bits IPv6 SAM PREFIX up to 144 bits <-------------- 128 ------------><1><- 15-> +---------------+--+-------------+-+--+---+ IPv6 ADDRESS |XXXXXXXXXXXXXXX|FF|XXXXXXXXXXXXX|1|XX|...| & PORT PREFIX +---------------+--+-------------+-+--+---+ : : / / / / : :/ / / / : : : / / : : :/ / +---------------+-------------+--+ |XXXXXXXXXXXXXXX|XXXXXXXXXXXXX|XX| +---------------+-------------+--+ SAM RAW PREFIX up to 135 bits 1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv6 Figure 8 Detailed mappings between SAM prefixes and raw prefixes are shown in Figure 8 and Figure 7, for IPv6 and IPv4 respectively. Despres Expires April 22, 2010 [Page 18] Internet-Draft Mesh Softwire with SAM October 2009 7. Derivation of Sub-delegated prefixes from Short IDs and Received Prefixes Sub-delegated prefixes are built in each SAM domain according to the classical CIDR principle, where each domain in the hierarchy adds its interior ID to its received delegated prefix(es), except that this principle applies rigorously to raw prefixes rather than to SAM prefixes themselves. Figure 9 shows how sub-delegated prefixes are built, in customer-side SAMs, using mappings of the Section 6 between SAML prefixes and raw prefixes. IPv4 or IPv6 +--------------+ | SHORT 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 ADDRESS AND DELEGATED PREFIXES Figure 9 Despres Expires April 22, 2010 [Page 19] Internet-Draft Mesh Softwire with SAM 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 exterior locators, received on the SAM exterior interface, are mapped into the source and destination addresses to be placed in the encapsulating packet: 1. The source locator MUST NOT match any of delegated prefix of the SAM, if any. 2. If the SAM has no delegated prefix, the source locator MUST match one of its sub-delegated prefixes (it MUST have at least one). 3. If the SAM has sub-delegated prefixes, the destination locator MUST NOT match any of them. 4. If the destination locator matches one of the received prefixes, a short ID MUST be extractible from it, in bits that follow this prefix, according to parameters of one of the interior address formats. The DESTINATION INTERIOR ADDRESS is then derived from this format and this short ID. 5. If the destination locator doesn't match any of the received prefixes, then the source locator MUST match one of the sub- delegated prefixes of the SAM. The DESTINATION INTERIOR ADDRESS is then that of a parent SAM that has the delegated prefix from which this sub-delegated prefix has been derived. 6. Provided all previous conditions have been verified, the SOURCE INTERIOR ADDRESS is that of the SAM. 8.2. Decapsulation Function In the decapsulation function of a SAM, the following are the rules to be checked to ensure that, in a packet received on its interior interface, source and destination addresses of the encapsulating packet and source and destination locators of the encapsulated packet are consistent, both among themselves and with parameters of the SAM: 1. The destination locator MUST NOT match any of delegated prefix of the SAM, if any. 2. If the SAM has no delegated prefix, the destination locator MUST match one of its sub-delegated prefixes (it MUST have at least one). Despres Expires April 22, 2010 [Page 20] Internet-Draft Mesh Softwire with SAM October 2009 3. If the SAM has sub-delegated prefixes, the source locator MUST NOT match any of them. 4. If the source locator matches one of the received prefixes, a short ID MUST be extractible from it, in bits that follow this prefix, according to parameters of one of the interior address formats, and the source interior address MUST be that which is derived from this format and this short ID. 5. If the source locator doesn't match any of the received prefixes, then the destination locator MUST match one of the sub-delegated prefixes of the SAM, and the source interior address MUST be that of a parent SAM that has the delegated prefix from which this sub-delegated prefix has been derived. 6. The destination interior address MUST be that of this SAM. 9. Detailed Prefixes for the Example Scenarios We now return to the two example scenarios of Section 2 to show, with detailed address and prefix values, how the SAM mechanisms can deliver what was claimed. 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. Despres Expires April 22, 2010 [Page 21] Internet-Draft Mesh Softwire with SAM October 2009 INTERNET ISP NETWORK BACKBONES | 2001:a::/32 | V | V +-------------------------+ | +--------- | IPv6 & private IPv4 | | | | |<=== | | 0::/0 ===>+-------+ IPV6 | | | | | | CUSTOMER-EDGE | | +--------- IP NODES | | | | LAN (198.0.0.0/20):(0b0/1) V | 2001:a:50000::/64 | / +------------+ | | +-------+ / | dual stack | | | | |/ +--------- | +------+------+--+ 0../0 ===>| NAT44 / | | | SAM |<--- | | | /| | | |<=== |<--- | | +-------+-------+ IPV4 | | | | | | | |<=== | +-----+--|---+ | | --->| SAM | | | | | | | | | | +--------- | | +---------------|-+-------+ | | | | | 2001:a:5000:0:ff00::222 | | | (autoconfig on LAN 5) | 198.0.0.0/20 | 10.0.0x5444 (DHCP) | | | | | 2001:a:5222::/48 2001:a:0000:0:< EUI-64 > 198.0.1.0x22:(0b10010/5) (autoconfig on LAN 0) 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 Figure 10 Despres Expires April 22, 2010 [Page 22] Internet-Draft Mesh Softwire with SAM October 2009 LAN 10.0.0x54.0x44 2001:a:1222:0::/64 98.0.1.0x22:(0b100100/6) 192.168.0.0/16 | | CUSTOMER-EDGE | | ROUTER | | +---------------|----+ | | | | SAM | | +-------+ | | HOSTS | | | | / | | | | | NAT44 |/ | V | | | | | +-------+ +-------+-------+--------- +------------+ | --->| | | ISP |<--- | dual stack | | ===>| | SAM | SAM |<--- | +-----+-------------+ | | | |<=== | | | | SAM |<=== | | +----+-------+--|----+ | | |<=== |<--- | | | | | | | |<--- | | | | +------+--|--+ | | | 2001:a:5222::/48 | | | | 98.0.1.0x22:(0b10010/5) | | | | | | | 2001:a:1222:0: /64 | | | (autoconf) | | | 0.0.0.0/0 | | | | | 2001:a:1222:0::/64 (RA) | | 2001:a:1222:0:ff00::3 2001:a:1000:0:ff00::222 | (autoconfig) 10.0.0x54.0x44 | 192.168.0.x (DHCP) | 2001:a:1222:3000::/51 98.0.1.0x22:(0b100101011/10) Number of SAM hosts : 16 NAT44 shared external ports (via ISP-NAT) : 64K / host NAT44 shared external ports (single NAT) : 64 / host IPv4 assigned ports : 64 / host EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 2 Figure 11 Despres Expires April 22, 2010 [Page 23] Internet-Draft Mesh Softwire with SAM October 2009 10. Applicability to other scenarios Scenarios that can take advantage of such a simple mechanism as SAM are so numerous that listing them is well beyond the scope of this document. Note however that SAM can be used in ISP networks that route exclusively in IPv6, as described in particular in [IVI]. With SAM, IPv4 end-to-end transparency in particular can be offered to customers across the IPv6-only ISP domain, thanks to the encapsulation of IPv4 packets in IPv6 packets. A typical scenario would combine SAM with translation solutions, which remain necessary for hosts that don't support SAM. 11. Security considerations Provided all address checks of Section 8 are performed, as required by this specification, no new security risk has been identified so far. 12. IANA Considerations If and when detailed formats are agreed on for SAM-specific DHCP options, they will have to be submitted to IANA. Also, the SAM tag in the 9th octet of IPv6 addresses, used to distinguish SAM addresses from other IPv6 addresses, should in due time be registered by IANA. 13. Acknowledgments This specification is mostly the result of a personal effort of the author, in continuation to his work that led to the rapid deployment of native IPv6 by Iliad/Free [Free's IPv6 in 2007]. High recognition is however due to Mark Townsley. He listened to intermediate stage presentations, provided useful reactions, and became a convincing an advocate in favor of a Cisco Research Grant to be allocated to Telecom Bretagne for a test of a subset of SAM. Special thanks are due to Laurent Toutain who, having seen the potential of SAM, decided to start an experiment with his team at Telecom Bretagne. Acknowledgments are also due to Dave Thaler who made a precious detailed review of the previous version. Beyond this, the open discussion environment of IETF in general has been a continuous encouragement. Despres Expires April 22, 2010 [Page 24] Internet-Draft Mesh Softwire with SAM October 2009 14. References 14.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. [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 [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", July 2009. [DSlite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", July 2009. [DnsAttack] Friedl, S., "An Illustrated Guide to the Kaminsky DNS Vulnerability", August 2008. [Free's IPv6 in 2007] Despres, R., "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", April 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", June 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", 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. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. Despres Expires April 22, 2010 [Page 25] Internet-Draft Mesh Softwire with SAM October 2009 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3286] Ong, L. and J. Yoakum, "An Introduction to the Stream Control Transmission Protocol (SCTP)", RFC 3286, May 2002. [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. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 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. [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. Despres Expires April 22, 2010 [Page 26] Internet-Draft Mesh Softwire with SAM October 2009 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 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". [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. [TransFrmwk] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 Translation", February 2009. Author's Address Remi Despres 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires April 22, 2010 [Page 27]