idnits 2.17.1 draft-durand-v6ops-assisted-tunneling-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 589 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 82 has weird spacing: '...figured do no...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '3053' is mentioned on line 462, but not defined == Missing Reference: '2222' is mentioned on line 459, but not defined == Missing Reference: '2831' is mentioned on line 456, but not defined -- Looks like a reference, but probably isn't: 'ISP' on line 465 -- Looks like a reference, but probably isn't: 'UNMANAGED' on line 470 -- Looks like a reference, but probably isn't: '3GPP' on line 474 == Unused Reference: '2119' is defined on line 451, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A.Durand 2 INTERNET-DRAFT SUN Microsystems,inc. 3 March, 29, 2004 F. Parent 4 Expires September 28, 2004 Hexago 6 Requirements for assisted tunneling 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 28, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines requirements for a tunnel set-up protocol that 38 could be used by an ISP to jumpstart its IPv6 offering to its 39 customers by providing them IPv6 connectivity without having to 40 upgrade its access network. 42 1. Goal and Scope of the Document 44 The v6ops working group has worked on requirements and scenarios for 45 IPv6 deployment by soliciting input from network operators. This work 46 has identified a need for an "assisted tunneling" mechanism. For 47 example, an ISP starting its IPv6 offering to its customers without 48 upgrading its access network to support IPv6 could use a "tunnel 49 brokering solution" [ISP, section 5.1.] a la [3053]. What has been 50 identified as missing from that RFC is a tunnel set-up protocol. 52 In an ISP network where IPv4 is dominant, some of the initial IPv6 53 deployment phases consists of getting a prefix allocation from the 54 RIR, and peering with other IPv6 ISP (or exchange points). 56 Getting IPv6 connectivity to the customers involves upgrading the 57 access network to support IPv6, which can take a long time and/or be 58 costly. A tunneled infrastructure can be used as a low cost 59 migration path [ISP, section 5.1]. 61 With such an infrastructure, the ISP can connect its customers to its 62 IPv6 network using its production IPv6 address space, thus 63 facilitating migration towards native IPv6 deployment. The IPv6 64 deployment roadmap for connecting customers becomes: 66 - assisted tunneling infrastructure to early adopters, 67 - native IPv6 to customers where economically justified, 68 - native IPv6 to all customers. 70 Note that, as the addressing space used during the transition to 71 native remains the same the customer routing, filtering, accounting 72 [ISP, section 5.] stay the same, and there is no need to maintain any 73 kind of relay. 75 "Assisted tunneling" is used in this document to described a 76 transition mechanism where the parameters to configure a bi- 77 directional tunnel between an end-node (or leaf network) and a router 78 in the core of an ISP are negotiated through a tunnel set-up 79 protocol. Although this negotiation phase can be automated, this 80 remains different from transition mechanisms like 6to4 that is fully 81 automatic or teredo/isatap which, once the IPv4 address of an initial 82 server/router is configured do not involve any further negotiation 83 phase. In particular, the 'authenticated' mode defined in section 5 84 enable access control to the IPv6 network where the other transion 85 mechanism have to rely on out of band access control. 87 This document analyze the requirements for such a tunnel set-up 88 protocol. The v6ops WG scenario and evaluation documents for 89 deploying IPv6 within common network environments are used as input 90 to this document. 92 2. Applicability 94 Assisted tunneling is applicable in different IPv6 transition 95 scenarios. The focus of this document is to define the requirements 96 to apply this mechanism in the IPv4 ISP context making the following 97 assumptions: 99 - ISP is offering IPv6 connectivity to its customers initially 100 using controlled tunneling infrastructure [ISP, 5.1 Steps in 101 Transitioning Customer Connection Networks] 103 - The customer configuration may be diverse, and not necessarily 104 predictable by the ISP. The following cases must be supported: 105 - a single node, 106 - a leaf network, 107 - using a globally routable IPv4 address, 108 - behind a NAT, 109 - using dynamic IPv4 address (internally or externally to the 110 NAT) 112 There are actually two cases where the IPv4 address of the customer 113 tunnel end point can be dynamic, and both must be supported: 115 - The device used as tunnel end point is using a dynamic IPv4 116 address provided by the ISP. 117 - The device used as tunnel end point is located behind a customer 118 owned NAT box that is also acting as a local DHCP server. In that 119 case, the device IPv4 address may change after a reboot. 121 The scenario where the ISP is providing IPv6 connectivity to non- 122 customers is out of scope of this document. 124 Althought the main focus of this document is the ISP scenario, 125 assisted tunneling is applicable in all the other scenarios: 126 unmanaged, enterprise and 3GPP. 128 In unmanaged networks, assisted tunneling is applicable in the case A 129 (a gateway which does not provide IPv6 at all) [UNMANAGED, section 3] 130 and C (a dual-stack gateway connected to an IPv4-only ISP) 131 [UNMANAGED, section 5]. 133 In 3GPP networks, assisted tunneling can be used in the context of 134 dual stack UE connecting to IPv6 nodes through a 3GPP network that 135 only supports IPv4 PDP contexts [3GPP, 3.1]. 137 3. Requirements for Simplicity 139 The tunnel set-up protocol must be simple to implement and easy to 140 deploy. In particular, it should not depend on any complex, yet to be 141 designed, protocols or infrastructure pieces. 143 This protocol is a transition mechanism, thus does not need to be 144 perfect. As a matter of fact, making it perfect would be counter 145 productive, at it would first delay its definition, then make its 146 deployment more cumbersome and, last but not least, diminish the 147 incentives to deploy native IPv6. 149 4. Requirements for the non-authenticated Mode (initial tryout) 151 Assisted tunneling can be provided in two different modes, a simple 152 mode, unauthenticated, essentially aimed at tryout, and a more 153 complete mode, authenticated, aimed at production deployment. The 154 tunnel set-up protocol must support both modes, however ISP deploying 155 it may choose to only support one mode of operation. 157 Assisted tunneling in the non-authenticated mode is defined for 158 simple "plug & play" scenarios. In this mode, the tunnel 159 establishment is triggered through the execution of a simple program, 160 without any pre-configuration or pre-registration required from the 161 end-user. 163 The tunnel established is "anonymous", the end-user does not provide 164 any authentication to the server. An ISP using the protocol in this 165 mode may be offering a free service and doesn't wish to require any 166 form of registration. This free service can also be used to offer 167 trial IPv6 service limited to the ISP customers by relying on IPv4 168 access control. 170 4.1. Address Allocation 172 This mode is used to provide IPv6 connectivity to a single host. 173 Allocation of an IPv6 address (/128) to the end-node must be 174 supported in this mode. This IPv6 address is "transient" and may 175 change, but one may implement a mechanism to provide IPv6 address 176 stability in this mode (e.g. cookie mechanism). 178 See section 6.9 for DNS considerations. 180 4.2. Service Discovery 182 In order to offer "plug & play", the non-authenticated mode needs to 183 discover the address of the server that will provide the tunnel 184 connectivity. This discovery must be automatic within an ISP network. 186 4.3. NAT Traversal 188 Tunneling through IPv4 NAT must be supported. This should be detected 189 during the set-up phase (section 6.) 191 4.4 Security Threat Analysis 193 The un-authenticated mode relies on out of band authentication. It 194 essentially offer the IPv6 service to any of its IPv4 customers. 195 This may be regarded as a feature, but deployment of the service with 196 this mode enable must be done carefully. In particular, security 197 considerations must be taken into account. 199 If ingress filtering is not in place within the access network, a 200 number of DoS attack can happen: 202 - Customer A can impersonate someone else's IPv4 address during 203 the set-up phase and redirect a tunnel to that IP address. A then 204 can, for example, start a high bandwidth multimedia flow across 205 that tunnel and saturate its victim's uplink. 207 - Customer A can impersonate a large number of IPv4 addresses and 208 request tunnel of their behalf. That would quickly saturate the 209 ISP tunnel server infrastructure. 211 If ingress filtering is in place in the core ISP backbone but not in 212 the access network, the potential victims of the above problems will 213 be limited to the ISP's own customers. 215 If specific filtering is not in place in the ISP core network, 216 another kind of attack can happen. Customers from another ISP could 217 start using its tunneling infrastructure to get free IPv6 218 connectivity, transforming effectively the ISP into a IPv6 transit 219 provider. 221 In this mode, IPv4 return routability checks in the set-up phase of 222 the tunnels seems to be a way to avoid some of these problems at the 223 price of an extra round trip. 225 5. Requirements for the Authenticated Mode 227 Assisted tunneling in authenticated mode offers the features listed 228 in the non-authenticated mode (section 4), and some extra features 229 documented in this section. 231 A particular implementation may choose to only implement a subset of 232 those features, but the protocol must be able to negotiate them all. 234 The authenticated mode is most valuable in a provider network where 235 deployment of IPv6 is done in a more controlled manner. In such 236 networks, ease of debugging, traceability, filtering and so on are 237 important features. 239 5.1. Address and Prefix Delegation 241 The authenticated mode must support delegation of a single address or 242 a whole prefix or a combination of both. The length of the IPv6 243 prefix delegated must be configurable on the server. In this mode, 244 the protocol must be able to support servers willing to offer stable 245 IPv6 prefixes to the authenticated customers. 247 See section 6.9 for DNS considerations. 249 5.2. Authentication 251 A mechanism for easy user registration should be provided. A service 252 provider should be able to use its existing authentication database. 254 The authentication mechanism supported should be compatible with 255 standardized methods that are generally deployed. Hooks may be 256 provided to facilitate integration with the ISP management 257 infrastructure (e.g. RADIUS for AAA, billing). 259 In order to assure interoperability, at least one common 260 authentication method must be supported. Other authentication MAY be 261 supported and should be negotiated between the client and server 262 (e.g., SASL [2222]). 264 note: not clear what should be the mandatory authentication method. 265 Clear text password is out. Digest-MD5 [2831] seems like a good 266 choice. 268 As in sectoin 4.4, IPv4 return routability checks could help blocking 269 many DoS attack when IPv4 ingress filtering is not performed in the 270 access network. 272 5.3. NAT Traversal 274 Tunneling through IPv4 NAT must be supported. This should be detected 275 during the set-up phase (section 6.) 277 5.4. Accounting 279 The assisted tunneling should include tools for managing and 280 monitoring the provided service. Such information can be used to plan 281 service capacity (traffic load) or billing information. 283 Some useful accounting data are (not exhaustive list): 284 - Tunnel counters (traffic in/out) 285 - User utilization (tunnel uptime) 286 - System logging (authentication failures, resource exhaustion, 287 etc.) 289 The interface used to provide such information can be through SNMP or 290 an AAA protocol (e.g., RADIUS accounting). 292 6. General Requirements 294 6.1 Scalability 296 The tunnel set-up protocol must be scalable. 298 6.2 Service discovery requirements 300 The discovery part of the tunnel set-up protocol should be as 301 automatic as possible. 303 The discovery mechanism must be able to scale for large ISP who cover 304 different geographical areas and/or have a large number of customers. 306 Customers may very well try to use this tunnel set-up protocol even 307 if their ISP is not offering the service. In this case, without any 308 previous action taken by their ISP, the discovery part of the tunnel 309 set-up protocol must be able to abort immediately and display the 310 customers a message explaining that no service is available. 312 6.3 NAT Considerations 314 The assisted tunnel established by the protocol to be designed must 315 work with the existing infrastructure, in particular it must be 316 compatible with the various customer premise equipments available 317 today. This means that, in particular, the tunnels must be able to 318 traverse one or many NAT boxes of different kinds. There is no 319 requirement for any particular NAT traversal technology. However, as 320 NAT traversal usually requires an extra layer of encapsulation, the 321 tunnel set-up protocol must be able to detect automatically the 322 presence of one or more NAT boxes in the path. 324 6.4 Keep-alive 326 When a tunnel has to cross a NAT box, the mapping established by the 327 NAT must be preserved as long as the tunnel is in use. This is 328 usually achieved by sending keep alive messages across the tunnel. 329 Also, the same keep alive messages can enable the ISP tunnel end 330 point to perform garbage collection of its resources when tunnels are 331 not in use anymore. To enable those two functionalities, the tunnel 332 set-up protocol must include the transmission of keep-alive messages. 333 A client MAY choose not to send those messages (for example on ISDN 334 type links), but should then expect that the tunnel may be 335 disconnected at any time by the ISP and be prepared to restart the 336 set-up phase. 338 6.5 Latency in Set-up Phases 340 In certain type of networks, keeping tunnels active all the time is 341 not possible or simply too expensive. In those environments, the 342 protocol must be able to set-up tunnels on demand of the IPv6 343 applications requiring external connectivity. 345 The tunnel set-up protocol must then have a low enough latency to 346 enable quasi-instant configuration. Latency is usually a function of 347 the number of packet exchanges required, so minimizing this parameter 348 is important. 350 6.6 Security 352 The tunnel set-up protocol must not introduce any new vulnerability 353 to the network. 355 6.7 Traceability 357 In production environment, traceability is an important 358 consideration. The tunnel set-up protocol must be instrumentable to 359 enable the collection of usage data that can be used, for example, 360 for capacity planning. 362 6.8 Phase Out 364 This assisted tunneling mode is only a transition mechanism to enable 365 ISP to jump start IPv6 service without requiring an immediate global 366 upgrade of access networks and instead enabling a progressive roll 367 out. Once IPv6 is available natively in the access network 368 connecting a customer, there is no reason to keep using tunnels. So 369 the tunnel-setup protocol must have a provision to enable the ISP to 370 signal the user to use native IPv6 instead. 372 6.9 DNS considerations 374 It should be possible to have the server side of the protocol 375 automatically register the allocated IPv6 address in the DNS system 376 (AAAA and PTR records) using the ISP name space. Nothing specific is 377 required in the protocol to support this. The details can be 378 implementation specific. 380 If stable prefix delegation is done, it is expected that the DNS 381 delegation of the associated reverse DNS zone will be also stable and 382 thus can be performed out of band, so there is no requirement to 383 perform this delegation at the tunnel set-up time. 385 7. Compatibility with other Transition Mechanisms 387 7.1 TSP 389 The tunnel set-up protocol is not required to be compatible with TSP 390 or any particular implementation of the tunnel broker model [3053]. 391 Although, a great deal of experience can be drawn from the operation 392 of tunnel brokers currently using the TSP protocol. 394 7.2 TEREDO 396 There is a large number of Teredo clients already deployed, the 397 tunnel set-up protocol should explore the avenue of providing a 398 compatibility mode with Teredo, at least in the 'simple' mode 399 described in section 4. However, it may turn out that supporting a 400 compatibility mode with Teredo either requires to change the Teredo 401 specifications and/or implement Teredo on the tunnel server side. In 402 that case, it might be simpler to say that the compatibility mode 403 should be manage on the client side instead of the server side, that 404 is leave it up to the client to use either one of them. 406 7.3 ISATAP 408 Similar considerations as Teredo, section 7.2, applies to Isatap. 409 However, as Isatap can not work accross NAT, it is of much less 410 interest in the framework of this document. 412 8. Security Considerations 414 The establishment of a tunnel can be compared to Mobile IP 415 technology, where traffic can be redirected to go from one place to 416 another one. So similar threats exists. In particular, when a 417 customer is asking for the set-up of a tunnel ending at IP address X, 418 the ISP should check: 419 - the customer is allowed to set-up this tunnel, i.e. he "owns" 420 the IPv6 prefix. 421 - the customer is allowed to terminate the tunnel where he said he 422 would, i.e. he "owns" the IPv4 tunnel endpoint. 424 The first check is simply an authentication issue. The second may be 425 more complex, but can be omitted if strict ingress filtering is in 426 place in the access network, i.e. the customer is effectively 427 prevented from sending packet with an IPv4 source address he does not 428 own. 430 See section 4.4 for specific security consideration in the non- 431 authenticated mode. 433 9. Author Addresses 435 Alain Durand 436 SUN Microsystems, Inc 437 17 Network circle UMPK17-202 438 Menlo Park, CA, 94025 439 USA 440 Mail: Alain.Durand@sun.com 442 Florant Parent 443 Hexago 444 2875 boul. Laurier, bureau 300 445 Sainte-Foy, QC G1V 2M2 446 Canada 447 Mail: Florent.Parent@hexago.com 449 10. Normative References 451 [2119] Bradner, S., "Key Words for Use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 11. Non Normative References 456 [2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 457 Mechanism", RFC 2831, May 2000. 459 [2222] Myers, J., "Simple Authentication and Security Layer (SASL)", 460 RFC2222, October 1997. 462 [3053] A. Durand, P. Fasano, I. Guardini, D. Lento., 463 "IPv6 Tunnel Broker", January 2001. 465 [ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 466 into ISP Networks", 467 draft-ietf-v6ops-isp-scenarios-analysis-01 (work in 468 progress), February 2004. 470 [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for 471 Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work 472 in progress), February 2004. 474 [3GPP] J. Wiljakka, "Analysis on IPv6 Transition in 3GPP Networks", 475 draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March 2004. 477 12. Full Copyright Statement 479 Intellectual Property Statement 481 The IETF takes no position regarding the validity or scope of any 482 intellectual property or other rights that might be claimed to 483 pertain to the implementation or use of the technology described in 484 this document or the extent to which any license under such rights 485 might or might not be available; neither does it represent that it 486 has made any effort to identify any such rights. Information on the 487 IETF's procedures with respect to rights in standards-track and 488 standards-related documentation can be found in BCP-11. Copies of 489 claims of rights made available for publication and any assurances of 490 licenses to be made available, or the result of an attempt made to 491 obtain a general license or permission for the use of such 492 proprietary rights by implementors or users of this specification can 493 be obtained from the IETF Secretariat. 495 The IETF invites any interested party to bring to its attention any 496 copyrights, patents or patent applications, or other proprietary 497 rights which may cover technology that may be required to practice 498 this standard. Please address the information to the IETF Executive 499 Director. 501 Full Copyright Statement 503 Copyright (C) The Internet Society (2004). All Rights Reserved. 505 This document and translations of it may be copied and furnished to 506 others, and derivative works that comment on or otherwise explain it 507 or assist in its implementation may be prepared, copied, published 508 and distributed, in whole or in part, without restriction of any 509 kind, provided that the above copyright notice and this paragraph are 510 included on all such copies and derivative works. However, this 511 document itself may not be modified in any way, such as by removing 512 the copyright notice or references to the Internet Society or other 513 Internet organizations, except as needed for the purpose of 514 developing Internet standards in which case the procedures for 515 copyrights defined in the Internet Standards process must be 516 followed, or as required to translate it into languages other than 517 English. 519 The limited permissions granted above are perpetual and will not be 520 revoked by the Internet Society or its successors or assignees. 522 This document and the information contained herein is provided on an 523 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 524 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 525 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 526 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 527 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Acknowledgment 531 Funding for the RFC Editor function is currently provided by the 532 Internet Society.