idnits 2.17.1 draft-carpenter-softwire-sample-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 7, 2010) is 5071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-despres-softwire-sam-00 == Outdated reference: A later version (-02) exists of draft-lee-softwire-6rd-udp-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Standards Track S. Jiang 5 Expires: December 9, 2010 Huawei Technologies Co., Ltd 6 June 7, 2010 8 Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises 9 Legacy Equipment (SAMPLE) 10 draft-carpenter-softwire-sample-00 12 Abstract 14 IPv6 deployment is delayed by the existence of millions of subscriber 15 network address translators (NATs) that cannot be upgraded to support 16 IPv6. This document specifies a mechanism for traversal of such 17 NATs. It is based on an address mapping and on a mechanism whereby 18 suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via 19 a stateless server, known as a SAMPLE server, operated by their 20 Internet Service Provider. SAMPLE is an alternative to the Teredo 21 protocol. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 9, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Detailed specification . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Appendix A. Main differences from Teredo . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 At the moment, there are two traversal techniques for IPv6 users who 73 find themselves behind Customer Premises Equipments (CPEs) which are 74 in fact Network Address Translators (NAT) supporting only IPv4: 75 1. A configured tunnel (IPv6 in IPv4 or even IPv6 in UDP), involving 76 a managed tunnel broker, e.g. [RFC3053], with which the user 77 must register. Well known examples include deployments of the 78 Hexago tool, and the SixXs collaboration. However, this approach 79 does not scale well; it requires significant support effort and 80 is really only suitable for "hobbyist" early adopters of IPv6. 81 2. Teredo [RFC4380]. This is an automatic UDP-based tunneling 82 solution that relies on a Teredo server, and on Teredo relays 83 willing to carry the traffic. Unfortunately experience shows 84 that this is sometimes an unreliable process in practice, with 85 clients sometimes believing that they have Teredo connectivity 86 when in fact they don't, or alternatively with the Teredo server 87 and relay being very remote from the client and causing extremely 88 long latency for IPv6 packets. This leads to user frustration 89 and even to advice from help desks to disable IPv6. 91 It is well established that IPv4-only CPEs are the worst product 92 related deployment problem for IPv6 [I-D.ietf-v6ops-isp-scenarios], 93 and it is also clear that it will be many years before such CPEs, 94 being consumer devices sold in millions, will all be replaced. 95 Therefore, a scaleable and reliable method for IPv6 traversal of such 96 CPEs is desirable. 98 The method described here uses a subset of the stateless address 99 mapping (SAM) mechanism proposed by [I-D.despres-softwire-sam] and 100 elements of the Teredo method. However, it is intrinsically much 101 simpler than Teredo, since it is designed for managed deployment by 102 an ISP and its own clients. The authors understand that an 103 alternative formulation of this idea, explicitly in terms of the SAM 104 model, may also be published. The idea is also quite similar to 105 [I-D.lee-softwire-6rd-udp] and is published in a preliminary form so 106 that the community can evaluate the alternatives. 108 The method is intended for explicit adoption by an Internet Service 109 Provider (ISP) that wishes to provide IPv6 service to customers 110 behind IPv4-only CPE NATs, the common case today. The method is 111 called Simple Address Mapping for Premises Legacy Equipment (SAMPLE). 112 The ISP is required to operate a SAMPLE server and (unless operating 113 system implementers choose to support SAMPLE directly) to provide 114 customers with downloadable code for popular operating systems. The 115 SAMPLE download will create a virtual IPv6 interface on top of the 116 real IPv4 interface (just as Teredo, 6to4 and tunnel broker clients 117 do). This is suggested to be a more practical alternative than 118 requiring all customers to replace their CPE. However, customers 119 with an unsuitable operating system, or unwilling to install a 120 download, will be advised to buy an IPv6-capable CPE. 122 The following figure illustrates the method symbolically: 124 Host CPE/NAT SAMPLE 125 server 126 ___________ ___________ ___________ 127 | v6| | V4| | V4| | V4| | V4| | V6| 128 | |EN | | Private | | | | Native | |EN | | Native 129 | S |DE | S | IPv4 | S | N | S | IPv4 | S |DE | S | IPv6 130 | T | C | T |---------| T | A | T |--------| T | C | T |------ 131 | A | A | A | | A | T | A | | A | A | A | 132 | C | P | C | | C | 4 | C | | C | P | C | 133 | K | | K | | K | 4 | K | | K | | K | 134 |___|___|___| |___|___|___| |___|___|___| 136 - Customer IPv4 - - ISP IPv4 - 137 address realm address realm 139 The principle of operation is that each host that starts IPv6 140 communication via the SAMPLE server is assigned an IPv6 address which 141 forms part of the ISP's regular routeable IPv6 address space. This 142 address embeds the NAT's native IPv4 address (assigned from the ISP's 143 IPv4 address space). It also embeds the port number assigned to the 144 IPv6 communication stream by the NAT. Note that this applies even if 145 the ISP is using private addressing itself; the ISP IPv4 address 146 realm does not need to use global addresses. Needless to say, all 147 IPv6 addresses are globally unique. 149 2. Normative Notation 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Detailed specification 157 The IPv6 address assigned to a host is mapped as follows: 158 o Let PSAMPLE be a /64 IPv6 prefix assigned to the SAMPLE server. 159 It may be any native IPv6 prefix chosen out of the routeable 160 address space assigned to the ISP. 162 o Let V4ADDR be the /32 native IPv4 address assigned by the ISP to 163 the CPE. 164 o Let PN be the external 16 bit port number assigned by the legacy 165 CPE NAT to the host's SAMPLE interface when it first sends traffic 166 to the SAMPLE server. (See below.) 168 (Note that the private IPv4 address assigned to the host behind the 169 NAT is of no importance in the mapping.) 171 The IPv6 address assigned to the host is the concatenation: 173 0 64 80 96 174 +-------------+-------------+-------+------+-------------+ 175 | PSAMPLE | FILL | PN | V4ADDR | 176 +-------------+-------------+-------+------+-------------+ 178 There is no restriction on the 16 FILL bits except that they MUST 179 respect [RFC4291]. 181 IPv6 packets travelling between the host and the SAMPLE server in 182 either direction MUST be encapsulated in UDP as described in 183 [RFC4380]. At the host, they are decapsulated and processed by the 184 local IPv6 stack. At the SAMPLE server, they are decapsulated and 185 forwarded into the native IPv6 network. No state is required in the 186 SAMPLE server; it performs blind encapsulation and decapsulation. 188 The SAMPLE interface in the host MUST be configured with the IPv4 189 address and UDP listener port number of the SAMPLE server. Apart 190 from this, it performs blind encapsulation and decapsulation, once it 191 has been assigned an IPv6 address. 193 [COMMENT: We don't want any sloppiness about reachability of the 194 server - so an anycast address used by default seems like a really 195 Bad Idea, judging by 6to4 experience.] 197 [QUESTION: Do we need a registered port number for this, or is it OK 198 to make it configured? Or, could we re-use the Teredo listener port, 199 3544?] 201 When a host's SAMPLE interface starts up, it MUST send a Router 202 Solicitation message to the SAMPLE server. The details are as for 203 Teredo, except that there is no equivalent of the 'cone' bit 204 procedure. Either the SAMPLE server will reply with a Router 205 Advertisement within a timeout TBD, or the method will fail. 207 Teredo's Origin Indication mechanism is used to convey the values of 208 PN and V4ADDR with the Router Advertisement. The SAMPLE interface 209 can complete its own configuration upon receipt of such an RA 210 message. 212 Once an IPv6 address has been configured, the SAMPLE interface MUST 213 send "keep alive" probes to the SAMPLE server whenever there has been 214 no traffic through the interface for TBD seconds, in order to keep 215 the relevant NAT state alive. 217 [COMMENT: Need to specify that in detail. Probably, the probe can 218 simply be a "no next header" IPv6 packet, and the timeout will be 219 configured to a value determined by experience.] 221 The SAMPLE server will act as an IPv6 router. In the simplest case, 222 it will forward all IPv6 packets to a default route, except those 223 whose destination address lies within the PSAMPLE prefix, which will 224 be encapsulated and sent towards the host (CPE) and port indicated by 225 the V4ADDR and PN values. 227 [QUESTION: Do we need to optimise hairpinning? ] 229 [QUESTION: We want the server to be stateless. Is there any 230 particular defence against DoS using bogus V4ADDR/PN values? ] 232 4. Security Considerations 234 A basic assumption of SAMPLE is that it is deployed entirely within 235 the administrative boundary of a single ISP and its customers. 236 SAMPLE-encapsulated packets should never leave or enter that 237 administrative boundary. Threats arising within that boundary need 238 to be considered. 240 A SAMPLE server SHOULD be configured to discard (with logging if 241 required) any incoming SAMPLE packet whose IPv4 source address does 242 not belong to any customer of the ISP concerned. The only exception 243 is if [RFC2827] is in use by the ISP. 245 [COMMENT: There is work to do here. It seems intrinsically more 246 controlled than either 6to4 or Teredo, since the entire tunnel is 247 confined to the ISP's IPv4 realm, but we have to look at the threats 248 identified for those two solutions and see which apply here. 250 Points to consider: should the user IPv4 address be obfuscated, as in 251 Teredo? Should some random bits be included in the FILL bits, to 252 defeat address scanning, as in Teredo? ] 254 5. IANA Considerations 256 This document requests no action by IANA. 258 6. Acknowledgements 260 This document builds on an idea extracted and simplified from 261 [I-D.despres-softwire-sam]. 263 Valuable comments and contributions were made by ... 265 This document was produced using the xml2rfc tool [RFC2629]. 267 7. Change log 269 draft-carpenter-softwire-sample-00: original version, 2010-06-07 271 8. References 273 8.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, March 1997. 278 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 279 Defeating Denial of Service Attacks which employ IP Source 280 Address Spoofing", BCP 38, RFC 2827, May 2000. 282 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 283 Architecture", RFC 4291, February 2006. 285 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 286 Network Address Translations (NATs)", RFC 4380, 287 February 2006. 289 8.2. Informative References 291 [I-D.despres-softwire-sam] 292 Despres, R., "Stateless Address Mapping (SAM) for 293 Softwire-Lite Solutions", draft-despres-softwire-sam-00 294 (work in progress), March 2010. 296 [I-D.ietf-v6ops-isp-scenarios] 297 Carpenter, B. and S. Jiang, "Emerging Service Provider 298 Scenarios for IPv6 Deployment", 299 draft-ietf-v6ops-isp-scenarios-00 (work in progress), 300 April 2010. 302 [I-D.lee-softwire-6rd-udp] 303 Lee, Y. and P. Kapoor, "UDP Encapsulation of 6rd", 304 draft-lee-softwire-6rd-udp-01 (work in progress), 305 May 2010. 307 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 308 June 1999. 310 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 311 Tunnel Broker", RFC 3053, January 2001. 313 Appendix A. Main differences from Teredo 315 There is a critical difference from Teredo. The client address in 316 Teredo is like this (quoting [RFC4380]): 318 +-------------+-------------+-------+------+-------------+ 319 | Prefix | Server IPv4 | Flags | Port | Client IPv4 | 320 +-------------+-------------+-------+------+-------------+ 322 - Prefix: the 32-bit Teredo service prefix. 323 - Server IPv4: the IPv4 address of a Teredo server. 324 - Flags: a set of 16 bits that document type of address and NAT. 325 - Port: the obfuscated "mapped UDP port" of the Teredo service at 326 the client. 327 - Client IPv4: the obfuscated "mapped IPv4 address" of the client. 329 (end quote) 331 Also, in Teredo, the client has to figure out which relay to use: 332 "Teredo clients have to discover the relay that is closest to each 333 native IPv6 or 6to4 peer. They have to perform this discovery for 334 each native IPv6 or 6to4 peer with which they communicate." 336 In the SAMPLE scheme we bind IPv6 routing in both directions to the 337 PSAMPLE /64 IPv6 locator; the client sends and receives all its IPv6 338 packets to and from the same SAMPLE server's IPv4 address. 340 This does introduce a single point of failure and a scaling 341 bottleneck, but in exchange we get simplicity and reliability. We 342 don't need Teredo's flag bits; any NAT that supports outbound UDP 343 flow initiation will work. 345 The other major difference (and hence simplification) is that we 346 assume that any NAT CPE is capable of straightforward port mapping 347 for a bidirectional UDP stream, so there is no mechanism for 348 detecting what type of NAT is in the way. 350 As noted above, the security threats are limited to those that can 351 occur inside a single ISP's administrative boundary. 353 Authors' Addresses 355 Brian Carpenter 356 Department of Computer Science 357 University of Auckland 358 PB 92019 359 Auckland, 1142 360 New Zealand 362 Email: brian.e.carpenter@gmail.com 364 Sheng Jiang 365 Huawei Technologies Co., Ltd 366 KuiKe Building, No.9 Xinxi Rd., 367 Shang-Di Information Industry Base, Hai-Dian District, Beijing 368 P.R. China 370 Email: shengjiang@huawei.com