Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Experimental July 5, 2010 Expires: January 6, 2011 Rapid Deployment of Native IPv6 Behind IPv4 NATs (6rd+) draft-despres-softwire-6rdplus-00 Abstract The [6rd] mechanism permit IPv6 "rapid deployment" across IPv4 infrastructures of Internet Service Providers, but only in cases where customer-premise equipments can be upgraded to support it. 6rd+ extends this IPv6 rapid deployment capability to hosts behind customer-premise equipments that cannot be upgraded (provided these hosts can be upgraded themselves to support 6rd+). Like [6rd], 6rd+ provides native IPv6 addresses, so that quality of service can be guaranteed by Internet Service Providers; it operates statelessly, which ensures simplicity and scalability; and it transmits encapsulated IPv6 packets along optimized paths, which contributes to efficiency and acceptability. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Despres Expires January 6, 2011 [Page 1] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The 6rd+ Protocol . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Participating Entities and IPv6 Paths . . . . . . . . . . 5 3.2. 6rd+C Locator Formats . . . . . . . . . . . . . . . . . . 7 3.3. 6rd+ Datagram Formats . . . . . . . . . . . . . . . . . . 9 3.4. Mapping Rules of 6rd+Cs and 6rd+Ps . . . . . . . . . . . . 11 3.5. Acquisition of 6rd+ parameters by 6rd+Cs . . . . . . . . . 14 3.6. Anti-Spoofing and Anti-Routing-Loop Protections . . . . . 16 4. Security considerations . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Despres Expires January 6, 2011 [Page 2] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 1. Introduction Although most operating systems now support IPv6, the large installed base of IPv4-only customer-premise equipments (CPEs) acts as a deterrent to IPv6 rapid deployment. Mechanisms such as [Tunnel Broker] and [Teredo] are designed to provide IPv6 connectivity behind such CPEs, but with too severe limitations to be generalized: [Tunnel Broker] necessitates that hosts be individually registered in tunnel- broker servers, and tends to produce unnecessarily long IPv6 paths; [Teredo] does not work with all types of customer-site NATs, and, because it uses IPv6 addresses that start with a Teredo-specific prefix, prevents Internet Service Providers (ISPs) to control the IPv6 quality of service (QoS) experienced by their customers. 6rd+ is designed to avoid these limitations: o All types of NATs are supported. o IPv6 addresses obtained behind IPv4-only CPEs are "native" (unicast starting with ISP-allocated prefixes), so that ISPs can control the IPv6 QoS experienced by their customers. o IPv6 paths are optimized. o Hosts don't need to be individually registered in any specific server. The name 6rd+ is derived from that of [6rd], to express that it extends its IPv6 "rapid deployment" to cases not covered so far. Like [6rd], 6rd+ uses IPv6-packet encapsulations and stateless address mappings, but where [6rd] necessitates CPEs to be upgraded, 6rd+ does not. The counterpart is that hosts behind non-upgraded CPEs have to support 6rd+ to obtain their native IPv6 connectivity. Their upgrade is expected to be feasible with a downloadable module, at least with Linux for which similar stateless functions have been shown to be downloadable. Other approaches to extend [6rd] to traverse IPv4-only CPEs have been proposed in [6rd UDP] and [SAMPLE], but without optimization of IPv6 paths. As this optimization is expected to be important for a wide use of native IPV6, 6rd+ is proposed as a more complete solution. Formats 6rd+ based IPv6 addresses presuppose that the rule of Despres Expires January 6, 2011 [Page 3] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 [RFC4291] that IPv6 addresses must contain 64-bit-IIDs is partially relaxed. This relaxation is needed to keep formats of 6rd+ based addresses simple, and does not conflict with the technical rationale for this rule. The 64-bits IID is indeed justified for addresses that, on some link, are subject to the neighbor discovery protocol [ND], but only for these. As 6rd+ addresses that don't have 64-bits IIDs are only assigned to host interfaces on virtual links, where the [ND] protocol is not used, the conflict doesn't exist. (Note that the viability of virtual links having no [ND] has been abundantly validated with [6to4], and that an independent proposal to partially relax the 64-bits-IID rule is available in [IPv6 /127 prefix].) At this stage, the 6rd+ design is so new that some fixes are likely to be needed, in particular after running code has been developed. This is the reason why it is proposed as experimental. But the intent is to progress it to the standard track as soon as possible: the urgency of IPv6 actual use continues to grow. 2. Terminology IPv4+: The extended-address family whose addresses have 48 bits, 32 of unicast IPv4 addresses plus 16 of a port numbers. Locator: Any routable address or prefix, in a specified address space among IPv4, IPv6, and IPv4+. IPv4+ datagram : An IPv4 datagram that contains a 6rd+ message, or an IPv6 packet in which at least one address has been obtained with 6rd+. The protocol above IPv4 is either UDP or the SAM protocol whose ID has to be assigned by IANA (see Section 3.3. If it is UDP, at least one of the two UDP ports is one of the two 6rd+ well-known ports, to be also assigned by IANA. NAT: In this document, only IPv4-to-IPv4 network address translations are considered (NAT44s). They typically translate address plus ports couples, as described in [RFC2663]. EIM, EDM: An EIM NAT is one that does endpoint-independent mappings as specified in [RFC4787] (also known as a "full-cone" NAT). An EDM NAT is one that does endpoint-dependent mappings (the opposite of an EIM NAT). 6rd+C, 6rd+P: A 6rd+C is a 6rd+ "customer" function, and a 6rdP is a 6rd+ "provider" function. Each one has one lower-layer interface, and two upper-layer interfaces. The lower-layer interface is that of an IPv4 link layer. One of its upper-layer interfaces is a replication of the lower-layer interface? the other is an IPv6 Despres Expires January 6, 2011 [Page 4] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 pseudo interface (as in [6to4]. Between two 6rd+Cs, or between a 6rd+C and a 6rd+P, IPv6 packets are encapsulated in IPv4+ datagrams. 6rd+ domain: A network domain delimited by 6rd+Ps and 6rd+Cs of a given ISP. Local, Interior: The "local" address space of a 6rd+C is that available at its lower-layer interface. Its interior address space is that available after traversal of all NATs that may exist between this 6rdC and 6rd+Ps. It is the same for all 6rd+Cs of the domain. (A 6rd+C that has no NAT between itself and 6rd+Ps has identical local an interior address spaces.) Shortcut: An path, between two 6rd+Cs of the same 6rd+ domain, that doesn't go via any domain 6rd+P. 3. The 6rd+ Protocol 3.1. Participating Entities and IPv6 Paths In a 6rd+ domain, participating entities are the following [Figure 1]: o 6rd+Ps (6rd+ Provider functions) o 6rd+Cs (6rd+ Customer functions) o CPE NATs of two types * EIM CPE NAT (doing endpoint-independent mapping) * EDM CPE NAT (doing endpoint-dependent mapping) o ISP NATs 6rd+Ps are stateless. They can be duplicated in any number of nodes. Their interior unicast address is then routed like any other anycast address. 6rd+C functions are also stateless. However, if there are NATs between them and 6rd+Ps, their operation depends on states that are maintained in these NATs. In this case, they cannot be duplicated in several nodes. Despres Expires January 6, 2011 [Page 5] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 <================= 6rd+ domain =================> local address spaces interior address space IPv6 +-----+Private IPv4 +-----+ Public or private IPv4 | |------->O------| |------------.----. +-----+ / +-----+ \ \ 6rd+C <--' EIM CPE NAT : : : : IPv6 : : +-----+Private IPv4 +-----+ : : | |------->O------| |-----------------. | +-----+ / +-----+ : \: 6rd+C <--' EDM CPE NAT ^ : ' IPv6 \ : : +-----+ \: : +-----+| O \ | || /: :---->O |---- / : / /| |+ v : : <--' +-----+ possibly : : 6rd+Ps IPv6 other . . +-----+Private IPv4 NATs +-----+ /: /: | |-------- - - - - - ---->O |---'----' : +-----+ /+-----+ : : 6rd+C <--' ISP NAT : : : : IPv6 . . +-------+Public or private IPv4 No NAT / / | 6rd+C |--------------------------------'----' +-------+ 6rd+ PARTICIPATING ENTITIES AND IPv6 PATHS Figure 1 The distinction between EIM and EDM NATs is key, like in [STUN] and in [Teredo], to find some shortcuts that are possible only with EIM NATs. CPE NATs, being in legacy devices of unknown types, may be either EIM or EDM. ISP NATs are assumed to be EIM and to support hairpinning, as specified in [RFC4787]. Paths that can be followed by IPv6 packets are illustrated in Figure 1. Possible shortcuts are the following: Intra-site shortcut: This shortcut concerns two 6rd+Cs that are on the same LAN behind a common CPE NAT (EIM CPE NAT or EDM CPE NAT). IPv6 packets are exchanged via the LAN, without going to the CPE. Despres Expires January 6, 2011 [Page 6] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 Intra-ISP shortcut: This shortcut concerns 6rd+Cs that are behind EIM CPE NATs, or ISP NATs, or no NAT. IPv6 packets between them, unless intra-site shortcuts which are shorter are possible, traverse the IPv4 routing infrastructure of the domain without going to any of its 6rd+Ps. ISP-NAT hairpin shortcut: If two 6rd+Cs are behind the same ISP NAT, IPv6 packets they exchange follow an hairpin path whose turning point is in this ISP NAT. 3.2. 6rd+C Locator Formats Formats of IPv6 locators that 6rd+Cs obtain depend on the types of NATs that exist between themselves and 6rd+Ps of the domain. Each such IPv6 locator is chosen to contain all addressing information that is needed to reach it via with or without shortcut, and nothing more. The different formats that result from this principle are detailed in Figure 2 (where the dot is used as concatenation operator). The three NAT-type codes, C, C' and C", because they must be distinguishable in a prefix-match search, have to be be disjoint prefixes (no one starting with another). Besides that, they may have different lengths: o NAT-type code C", which is that of 6rd+Cs that have no NAT to traverse, should typically be short so that IPv6 locators E=D.C".X remain within a 64-bits limit. These locators can thus be used as link prefix on ordinary IPv6 links (subject to [ND]). o NAT-type codes C and C', which are those of 6rd+Cs behind NATs, appear in IPv6 locators E=D.C.X.Z, E=D.C.X.Z.Y, and E=D.C'.X.Z.Y, which contain too much information to have a chance to fit in 64- bits. In order to limit the amount of ISP IPv6 address space devoted to 6rd+, C and C' may therefore be chosen significantly longer than C". These locators, which are too long to be used as link prefixes on ordinary IPv6 links, can be used to obtain native-IPv6 host addresses (duly completed with trailing 0s if needed to reach 128 bits). Other possible uses of these locators are beyond the scope of this draft. Despres Expires January 6, 2011 [Page 7] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 E=D.C.X.Z.Y A=Q.Y +-----+ +-------+ L=A:W | EIM | N=P.X | 6rd+C |----->O-------| CPE |------------.----. +-------+ / | NAT | \ \ <--' +-----+ : : L<->I=P.X:Z : : : : E=D.C'.X.Z.Y A=Q.Y +-----+ : : +-------+ L=A:W | EDM | N=P.X : : | 6rd+C |----->O-------| CPE |-----------------. | +-------+ / | NAT | : \: <--' +-----+ ^ : ' L<->I=N:Z | : : B.W +-----+ \ : \ B'.W'|6rd+P| D :--O :-----|-->O-|---- / : / | | | : : +-----+ v : : 6rd+P PARAMETERS: E=D.C.X.Z A possibly +-----+ . . D,P,C,C',C" +-------+ L=A:W other NATs | ISP | /: /: ISP-NAT locators | 6rd+C |-------- - - - - - --->|O----|---'----' : +-------+ L<->x /| NAT | : : / +-----+ : : <--' x<->I=P.X:Z : : : : E=D.C".X A=P.X . . +-------+ L=A:W No NAT / / | 6rd+C |---------------------------------'----' +-------+ I=L E : 6rd+C IPv6 locator D : ISP prefix assigned to 6rd+ C,C',C" : NAT-type code (resp. EIN or ISP, EDM, NoNAT) X : complement of P in N Z : complement to N in I (port number) Y : complement to Q in L A : 6rd+C local IPv4 address (= Q.Y) W,W' : 6rd+ well-known UDP ports (to be assigned by IANA) Q : prefix of RFC 1918 in A (10/8, 172.16/12, or 192.168/16) L : 6rd+C local locator (= A.W) I : 6rd+C interior locator (IPv4+) N : IPv4 part of the interior locator I P : common prefix of the interior address space (possibly /0) B,B' : 6rd+ well-known IPv4 public addresses (to be assigned by IANA) 6RD+ LOCATOR FORMATS Figure 2 Despres Expires January 6, 2011 [Page 8] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 3.3. 6rd+ Datagram Formats 6rd+Cs and 6rd+Ps encapsulate IPv6 packets they have to forward across their 6rd+ domain. For this they have to derive the interior destination address of each encapsulating packet from addresses contained in the IPv6 packet it encapsulates. If this interior destination has 32bits, encapsulation is in an IPv4 datagram, with the protocol field set to 41 (IP in IP). If it has 48 bits, encapsulation is in a UDP datagram. Its destination port is copied from the last 16 bits of the interior destination, and its source port is the 6rd+ well-known prefix W. Formats of IPv4+ datagrams are shown on Figure 3 and Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +=======+=======================================================+---- |Vrsn=4 | | +-------+ + | | + +---------------+ + | | Prot.=17 (UDP)| |IPv4 +---------------+---------------+-------------------------------+ | IPv4 Source Address | +---------------------------------------------------------------+ | IPv4 Destination Address | +=======+=======================+===============================+---- | Source Port (*) | Destination port (*) | +-------------------------------+-------------------------------| UDP | | +===============================================================+---- . . . IPv6 packet OR 6rd+ message . . . + + ---------------------------------------+ | | +=========//===========+ (*) At least one of the two ports is one of the two 6rd+ well-known prefixes W and W'. FORMATS OF 6RD+ DATAGRAMS FOR IPV4+ INTERIOR DESTINATIONS Figure 3 Despres Expires January 6, 2011 [Page 9] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 +=======+=======================================================+---- |Vrsn=4 | | +-------+ + | | + +---------------+ + | |Prot=41 (IP/IP)| |IPv4 +---------------+---------------+-------------------------------+ | IPv4 Source Address | +---------------------------------------------------------------+ | IPv4 Destination Address | +===============================================================+---- . . . IPv6 packet . . . + + ---------------------------------------+ | | +=========//===========+ +=======+=======================================================+---- |Vrsn=4 | | +-------+ + | | + +---------------+ + | |Prot=SAM (TBD)| |IPv4 +---------------+---------------+-------------------------------+ | IPv4 Source Address | +---------------------------------------------------------------+ | IPv4 Destination Address | +===============================================================+---- . . . 6rd+ message . . . + + ---------------------------------------+ | | +=========//===========+ FORMATS OF 6RD+ DATAGRAMS FOR IPV4 INTERIOR DESTINATIONS Figure 4 Recommendations of [RFC4213] that concern these encapsulations have to be followed. Since IPv6 packets are encapsulated in IPv4 datagrams which may be fragmented on their way, a large IPv6 packet can in general be encapsulated in a single IPv4 datagram, independently of path MTUs of the traversed domain. However, reassembly of multi-fragment datagrams tends to consume processing power and can bring some Despres Expires January 6, 2011 [Page 10] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 buffer-size problems. It is therefore advisable to limit the size of accepted IPv6 packets (and to return ICMPv6 packet-too-big error messages when received IPv6 packets are too big to be forwarded). Forwarding only IPv6 packets that don't exceed the 1280 octets, the size that [RFC2460] requests every link to support, is the choice that minimizes the risk of such reassembly problems. Yet, accepting somewhat larger sizes may be preferred to obtain a different trade- off between reassembly avoidance and accepted IPv6 packet sizes. The protocol ID to be used for 6rd+ messages exchanged directly in IPv4 datagrams is that of the more general [SAM] protocol, of which the 6rd+ protocol is a subset. 3.4. Mapping Rules of 6rd+Cs and 6rd+Ps Mapping rules that, in 6rd+Cs, determine interior destinations iDSTs are detailed in Table 1. For each NAT type, the listed rules have to be tested in the indicated order, until one is found to apply. If none applies, the IPv6 packet is invalid, and silently discarded. The logic of these mapping rules directly results from shortcuts that have to be supported, and from IPv6 locator formats of Section 3.2. In Table 1: o Lower-case letters represent lengths of fields whose symbols are upper-case letters (e.g. d is the number of bits of D). o Column 1 indicates the NAT type of the 6rd+C (EIM CPE NAT, EDM CPE NAT, ISP NAT, No NAT). o In column 2, a prefix indicates that the rule applies only if the IPv6 destination address eDST starts with this prefix. o In column 3, a number of bits n indicates that the rule applies only if both the IPv6 destination address and the 6rd+C IPv6 locator start with the same n bits. o In column 4, a prefix indicates that the rule applies if the IPv6 source address eSRC starts with this prefix. A rule has contents in one and only one of the first three columns. o In column 5, a prefix indicates that, if the rule applies, this prefix has to be included the interior destination iDST. o In column 6, a number of bits n indicates that, if the rule applies, n bits in the IPv6 destination address eDST have to be skipped, after those that may have already been matched if any. Despres Expires January 6, 2011 [Page 11] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 +------+------+-------------+-------+------+-------+---------+------+ | -1- | -2- | -3- | - 4 - | -5- | -6- | -7- | -8- | | ---- | ---- | --------- | ---- | ---- | ---- | ----- | ---- | | NAT | eDST | length of | eSRC | iDST | Skip | Add to | iDST | | Tpe | prfx | common | prfx | prfx | in | iDST | sffx | | | | prefix of | | | eDST | from | | | | | eDST & | | | | eDST | | | | | IPv6-lctr | | | | | | +------+------+-------------+-------+------+-------+---------+------+ | EIM | | d+c+32-p | | Q | 16 | 32-q | | | CPE | | | | | | | | | NAT | | | | | | | | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | D.C | | | P | | 48-p | | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | D.C" | | | P | | 32-p | W | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | | | D | B:W | | | | | ==== | ==== | ========= | ==== | ==== | ==== | ==== | ==== | | EDM | | d+c'+32-p | | Q | 16 | 32-q | | | CPE | | | | | | | | | NAT | | | | | | | | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | | | D | B:W | | | | | ==== | ==== | ========= | ==== | ==== | ==== | ==== | ==== | | ISP | D.C | | | P | | 48-p | | | NAT | | | | | | | | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | D.C" | | | P | | 32-p | W | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | | | D | B:W | | | | | ==== | ==== | ========= | ==== | ==== | ==== | ==== | ==== | | No | D.C | | | P | | 48-p | | | NAT | | | | | | | | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | D.C" | | | P | | 32-p | W | | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | | " | | | D | B | | | | +------+------+-------------+-------+------+-------+---------+------+ 6rd+C MAPPING RULES Table 1 Despres Expires January 6, 2011 [Page 12] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 o In column 7, a number of bits n indicates that, if the rule applies, n bits of the IPv6 destination eDST, after those that may have already been matched and/or skipped, have to be included in the interior destination iDST, after any bits it may have already been included. o A column-8 square may contain a suffix. If the rule applies, it is included in the interior destination iDST, after any bits it may already contain. 6rd+P mapping rules are straightforward, as no possible shortcuts have to be considered. Using the same notation as in Table 1, they are detailed in Table 2 (without any implication on how they can be implemented). As shown, packets exchanged between 6rd+Ps and 6rd+cs of the "No NAT" type are encapsulated in UDP/IP rather than directly in IPv4 as it would have been possible. This adds a little overhead to these packets, but has two advantages: hairpinning in 6rd+Ps for 6rd+Cs of the "No NAT" that exchange packets with 6rd+Cs of the EDM CPE NAT" type is facilitated, as received and transmitted datagram headers have the same length; routing loops with other tunneling mechanisms such as [6to4], [6rd], and [ISATAP], are made impossible (these three mechanisms encapsulate IPv6 in IPv4 while 6rd+Ps only encapsulate IPv6 in IPv4+ (see also Section 3.6. +----------------------+---------------------+----------------------+ | eDST prefix | iDST prefix | Add to iDST from | | | | eDST | +----------------------+---------------------+----------------------+ | d+c | P | 48-p | | -------------------- | ------------------- | -------------------- | | d+c' | P | 48-p | | -------------------- | ------------------- | -------------------- | | d+c" | P | 48-p | +----------------------+---------------------+----------------------+ 6rd+P MAPPING RULES Table 2 Despres Expires January 6, 2011 [Page 13] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 3.5. Acquisition of 6rd+ parameters by 6rd+Cs This 6rd+ protocol is a particular instance of the more general "stateless address mapping" protocol proposed in [SAM], where the exterior address family is IPv6 and the interior address family is IPv4+. Rules of the 6rd+ protocol, partially illustrated in Figure 5, are the following: R1: If a 6rd+C that has an IPv4 address but no IPv6 address or prefix, it tries to obtain its parameters from a 6rd+P (its IPv6 locator an its mapping rules). For this, it sends two SAM messages containing a "Parameter Request" indication. The first one is sent to IPv4 address B. The second one is sent IPv4+ address B:W, with the local IPv4 address A as parameter. These two requests are also retransmitted from time to time to check whether newly received answers differ from previous ones, and for the second one to maintain mappings in all NATs that may exist between the 6rd+C and 6rd+Ps. 6rd+C 6rd+P v ----- ----- : :\ A -> B SamMsg("ParamReq") A -> B : '->------------------------>--------------- - ??? - -------->-. : \ : : : A <- B SamMsg(ParamSetforNoNat) A <- B / : <------------------------<--------------------------------<-' : \ A.W -> B.W SamMsg("ParamReq", A) I -> B.W '->------------------------<-------------------------------->-. \ if I belongs : to an ISP NAT : A.W <- B.W SamMsg(ParamSetForIspNat) I <- B.W /: <------------------------->-------------------------------<-' : : otherwise : : A.W <- B.W SamMsg(ParamSetForEdm) I <- B.W : <------------------------->-------------------------------<-. : \. A.W <- B':W' SamMsg(ParamSetForEim) I <- B'.W' / <------- - ??? - ---------<-------------------------------<-' Despres Expires January 6, 2011 [Page 14] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 6rd+ PROTOCOL Figure 5 R2: If a 6rd+P receives a SAM message at its IPv4 address B without a UDP header, it knows that this message crossed no NAT on its way. If the message contains a parameter request, it returns a SAM message containing parameters suitable for this 6rd+C, known to be of the "No NAT" type. R3: If a 6rd+P receives a SAM message at its IPv4+ address B:W, it first tests whether its IPv4 source address starts with the IPv4 prefix of one ISP NATs of the domain. if yes, it returns an answer containing parameters suitable for this 6rd+C, known to be of the "ISP-NAT" type. Otherwise, it returns two answers. The first answer is sent from the B:W IPv4+ address so that it can reach its destination with on its way NATs of any types. It contains parameters suitable for this 6rd+C if it is of "EDM CPE NAT" type. The second answer is sent from the B':W' IPv4+ address so that it can reach its destination only if either there is no NAT on its way, or if the first traversed NAT is EIM. It contains parameters suitable for this 6rd+C if it is of the "EIM CPE NAT' type. R4: If a 6rd+C receives an answer, it first checks that its source address is valid (is B, B:W, or B':W'). If the received parameters are better than those of its current parameter set or if it has no current parameter set, it takes them as the new current parameter set. The decreasing order of best parameter sets is: (1) received from B (No NAT); (2) received from B':W' (EIM CPE NAT or ISP NAT); (3) received from B:W (EDM CPE NAT). If the received parameter set is less good as the current one, but has a lifetime longer than the the remaining lifetime of the current one, it should be memorized to possibly become current one if the current one becomes obsolete. Despres Expires January 6, 2011 [Page 15] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 R5: If a 6rd+C receives at its IPv4 address Q.Y a 6rd+ datagram without UDP header, in which the IPv6 destination doesn't match its IPv6 locator D.X.Z.Y, it infers that an intra-site shortcut must have been attempted which cannot be taken. This may happen in the very specific case where: there is at least one NAT, internal to the site, between the source 6rd+C and the intended- destination 6rd+C; there is no NAT between the source 6rd+C and the receiving 6rd+C; the receiving 6rd+C has the same private IPv4 local address as the intended-destination 6rd+C. A SAM message is then returned to the IPv4 address of the source 6rd+C with a "SAM unreachability" indication, and the receiving 6rd+C disables its intra-site-shortcut mapping rule if it still has one (a rule leading to a 32-bits iDST). R6: If a 6rd+C receives at its IPv4 address a SAM message containing a "SAM unreachability" indication, it disables its intra-site- shortcut mapping rule if it has one. With this rule ad the previous one, IPv6 connectivity between 6rd+C IPv6 locators is always ensured even in complex intra-site configuration with internal NATs, with IPv6 packets having in this case to go via the CPE. Detailed formats of SAM messages used for 6rd+ are beyond the scope of this document. They should be specified in the wider context of [SAM]. 3.6. Anti-Spoofing and Anti-Routing-Loop Protections Anti-spoofing protection can be ensured by applying the general ingress-filtering principle: a packet received at an interface is valid only if the same packet with inverses source and destination may be transmitted at that same interface: o An IPv6 packet received by a 6rd+C or by a 6rd+P in an IPv4+ datagram must be silently discarded if the source address of the datagram (IPv4 or IPv4+) is not that which mapping rules obtain as iDST if applied to a an IPv6 destination eDST equal to the IPv6 source address of the datagram. o Routing-loop protection is necessary if an ISP operates two point- to-multipoint tunneling mechanisms on the same domain with the same exterior and interior address families. (Example with [ISATAP] and [6to4] are analyzed in [RoutingLoops].) o As long as 6rd+ as specified here is the only point-to-multipoint tunneling mechanism used with IPv6 as exterior address space and IPv4+ as interior address space, no particular protection against routing loops is needed for IPv4+ tunnels. Despres Expires January 6, 2011 [Page 16] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 4. Security considerations With precautions taken in previous sections, no new security issue has been identified so far. More work on this specification is however desirable to improve confidence in this respect. 5. IANA Considerations For plug-and-play operation of 6rd+, the following assignments have to be made by IANA: o The two well-known IPv4 addresses B and B' and the two well-known UDP ports W and W' of Section 3.2; o The SAM protocol ID of Section 3.3 (to be shared with [SAM] 6. Acknowledgments A very early version of this proposal has been informally submitted to a number of delegates at IETF 77. Thanks are due to Dan Wing and Pascal Thubert for their encouragements to pursue in this direction, and also to Brian Carpenter for his strong support that the objective of 6rd+: native IPv6 across legacy CPEs. 7. References 7.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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. 7.2. Informative References [6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider Networks - draft-ietf-softwire-ipv6-6rd-10", February 2010. [6rd UDP] Lee, Y. and P. Kapoor, "UDP Encapsulation of 6rd - draft-lee-softwire-6rd-udp-01", May 2010. Despres Expires January 6, 2011 [Page 17] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 [6to4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", February 2001. [ARP] Plummer, D., "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1992. [IPv6 /127 prefix] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L. Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router Links - draft-kohno-ipv6-prefixlen-p2p-01", March 2010. [ISATAP] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [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 Despres Expires January 6, 2011 [Page 18] Internet-Draft Native-IPv6 across NAT44s (6rd+) July 2010 infrastructures (6rd)", January 2010. [RoutingLoops] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations - draft-nakibly-v6ops-tunnel-loops-02", May 2010. [SAM] Despres, R., "Stateless Address Mapping (SAM) for Softwire-Lite Solutions (NOTE: only the revised draft-despres-softwire-sam-01 will be consistent with this draft. It should be posted before the deadline for IETF 78)", July 2010. [SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises - Legacy Equipment (SAMPLE) - draft-carpenter-softwire-sample-00", June 2010. [STUN] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [Teredo] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [Tunnel Broker] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. Author's Address Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires January 6, 2011 [Page 19]