idnits 2.17.1 draft-ietf-v6ops-assisted-tunneling-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 598. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 8) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (Oct 2004) is 7104 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) == Unused Reference: 'RFC2119' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'I-D.huitema-v6ops-teredo' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ngtrans-isatap' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC2831' is defined on line 526, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ent-analysis-00 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ent-analysis (ref. 'I-D.ietf-v6ops-ent-analysis') ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-isp-scenarios-analysis (ref. 'I-D.ietf-v6ops-isp-scenarios-analysis') ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Downref: Normative reference to an Informational RFC: RFC 3904 == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-01 == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-02 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-22 == Outdated reference: A later version (-03) exists of draft-palet-v6ops-tun-auto-disc-01 == Outdated reference: A later version (-03) exists of draft-tschofenig-v6ops-secure-tunnels-01 -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2831 (Obsoleted by RFC 6331) Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Parent 2 Internet-Draft Hexago 3 Expires: April 1, 2005 A. Durand 4 SUN Microsystems,inc. 5 A. Baudot 6 France Telecom R&D 7 Oct 2004 9 Goals for Registered Assisted Tunneling 10 draft-ietf-v6ops-assisted-tunneling-requirements-01 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 1, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document defines requirements for a tunnel set-up protocol that 46 could be used by an ISP to jumpstart its IPv6 offering to its 47 customers by providing them IPv6 connectivity through tunneling. 49 Table of Contents 51 1. Goal and Scope of the Document . . . . . . . . . . . . . . . . 3 52 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Requirements for Simplicity . . . . . . . . . . . . . . . . . 5 54 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 55 4.1 Address and Prefix Delegation . . . . . . . . . . . . . . 6 56 4.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 6 58 4.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 59 4.5 Service Discovery . . . . . . . . . . . . . . . . . . . . 7 60 4.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7 61 4.7 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 7 62 4.8 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. General Requirements . . . . . . . . . . . . . . . . . . . . . 8 64 5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2 NAT Considerations . . . . . . . . . . . . . . . . . . . . 8 66 5.3 Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.5 Traceability . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.6 Phase Out . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.7 Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Compatibility with other Transition Mechanisms . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 76 9.2 Informative References . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 78 A. Changes from version 00 . . . . . . . . . . . . . . . . . . . 12 79 Intellectual Property and Copyright Statements . . . . . . . . 14 81 1. Goal and Scope of the Document 83 The v6ops working group has worked on requirements and scenarios for 84 IPv6 deployment by soliciting input from network operators. This 85 work has identified a need for an "assisted tunneling" mechanism. 86 For example, an ISP starting its IPv6 offering to its customers 87 without upgrading its access network to support IPv6 could use a 88 "tunnel brokering solution" (section 5.1 89 [I-D.ietf-v6ops-isp-scenarios-analysis]) a la [RFC3053]. What has 90 been identified as missing from that document is a tunnel set-up 91 protocol. 93 In an ISP network, getting IPv6 connectivity to the customers 94 involves upgrading the access network to support IPv6, which can take 95 a long time and/or be costly. A tunneled infrastructure can be used 96 as a low cost migration path (section 5.1 97 [I-D.ietf-v6ops-isp-scenarios-analysis]). 99 With such an infrastructure, the ISP can connect its customers to its 100 IPv6 network using its production IPv6 address space, thus 101 facilitating migration towards native IPv6 deployment. The IPv6 102 deployment roadmap for connecting customers may become: 104 o assisted tunneling infrastructure to early adopters, 106 o native IPv6 to customers where economically justified, 108 o native IPv6 to all customers. 110 Contrary to automatic tunneling mechanism where the IPv4 address is 111 embedded inside the IPv6 address, no special format are imposed on 112 the IPv6 address used in assisted tunneling. Prefix delegation is 113 also possible. As the addressing space used during the transition to 114 native remains the same, the customer routing, filtering, accounting 115 stay the same, and there is no need to maintain any kind of relay. 117 "Assisted tunneling" is used in this document to describe a 118 transition mechanism where the parameters to configure a 119 bi-directional tunnel between an end-node (or leaf network) and a 120 router in the core of an ISP are exchanged through a tunnel set-up 121 protocol. Although this exchange can be automated, this remains 122 different from transition mechanisms like 6to4, Teredo or ISATAP. In 123 particular, assisted tunneling enables explicit access control to the 124 tunneled IPv6 connectivity, where the other transion mechanisms have 125 to rely on other kinds of control (e.g., access control based on the 126 IPv4 address). Also, assisted tunneling protocol negotiate the 127 tunnel parameters and does not depend on having the IPv4 address 128 inside the IPv6 address, for example. 130 This document analyzes the requirements for such a tunnel set-up 131 protocol. The v6ops WG scenario and evaluation documents for 132 deploying IPv6 within common network environments are used as input 133 to this document. 135 2. Applicability 137 Assisted tunneling is applicable in different IPv6 transition 138 scenarios. The focus of this document is to define the requirements 139 to apply this mechanism in the IPv4 ISP context making the following 140 assumptions: 142 o ISP is offering IPv6 connectivity to its customers initially using 143 controlled tunneling infrastructure 144 [I-D.ietf-v6ops-isp-scenarios-analysis], section 5.1 "Steps in 145 Transitioning Customer Connection Networks" 147 o Provider network where deployment of IPv6 is done in a more 148 controlled manner or when the provider cannot rely on IPv4 related 149 authentication (e.g. roaming customers, users not connected to 150 ISP access network). In such networks, ease of debugging, 151 traceability, filtering and so on are important features. 153 o The customer configuration may be diverse, and not necessarily 154 predictable by the ISP. The protocol must be able to adapt to the 155 following cases, for example by choosing the most optimal tunnel 156 encapsulation depending on the presence of a NAT. 158 * a single node, 160 * a leaf network, 162 * using a globally routable IPv4 address, 164 * behind a NAT (customer or ISP owned), 166 * using dynamic IPv4 address (internally or externally to the 167 NAT) 169 There are actually two cases where the IPv4 address of the customer 170 tunnel end point can be dynamic, and both must be supported: 172 o The device used as tunnel end point is using a dynamic IPv4 173 address provided by the ISP. 175 o The device used as tunnel end point is located behind a customer 176 owned NAT box that is also acting as a local DHCP server. In that 177 case, the device IPv4 address may change after a reboot. 179 Althought the main focus of this document is the ISP scenario, 180 assisted tunneling is applicable in other scenarios: 182 In unmanaged networks [RFC3904], assisted tunneling is applicable in 183 the case A where a gateway does not provide IPv6 at all (section 3), 184 and case C where a dual-stack gateway is connected to an IPv4-only 185 ISP (section 5). 187 In the enterprise scenario [I-D.ietf-v6ops-ent-analysis], assisted 188 tunneling can be used to support remote users connecting to the 189 enterprise network (section 7.5.2). 191 3. Requirements for Simplicity 193 The tunnel set-up protocol must be simple to implement and easy to 194 deploy. In particular, it should not depend on any complex, yet to 195 be designed, protocols or infrastructure pieces. 197 This protocol is a transition mechanism, thus does not need to be 198 perfect. As a matter of fact, making it perfect would be counter 199 productive, at it would first delay its definition, then make its 200 deployment more cumbersome and, last but not least, diminish the 201 incentives to deploy native IPv6. 203 4. Protocol Requirements 205 Assisted tunneling is aimed at production deployment which requires 206 the user to be authenticated (such as using a shared secret mechanism 207 Section 4.3). This can be to offer the tunneling service to roaming 208 users (users that are not directly connected to the ISP access 209 network), and/or restrict the service to specific users. 211 From a user point of view, an initial registration process may be 212 required before using the service. If the service provider uses an 213 existing authentication database (Section 4.2), this step may not be 214 needed. 216 From an ISP point of view, this makes a clear link between a tunnel 217 and a user (account). It provides some means to : 219 o meet requirements such as tracing (section 5.4 220 [I-D.ietf-v6ops-isp-scenarios-analysis]) 222 o control service provision to valid and/or identified or even 223 selected users (section 5.2 224 [I-D.ietf-v6ops-isp-scenarios-analysis]) 226 o less prone to denial of service attacks: Since every tunnel 227 request are authenticated, it is more difficult to request 228 multiple tunnels to saturate the service. 230 o stay in touch with users 232 4.1 Address and Prefix Delegation 234 The protocol must support delegation of an IPv6 prefix. The length 235 of the IPv6 prefix delegated must be configurable on the server. The 236 protocol must be able to offer stable IPv6 prefixes to the 237 authenticated customers. 239 Assignment of an IPv6 address (/64) to the end-node must be 240 supported. 242 Since no special address format is imposed, the ISP's address space 243 can be used in the delegation (section 5.1 244 [I-D.ietf-v6ops-isp-scenarios-analysis]) 246 4.2 Registration 248 The registration of credentials is external to the protocol. The 249 user may require registration prior to using this service (through 250 some web based service or other means). Or service provider may use 251 an existing authentication database to pre-register its users. 253 In order to allow a service provider to use its existing 254 authentication database, an implementation may provide hooks to 255 facilitate integration with the ISP management infrastructure (e.g. 256 RADIUS for AAA, billing) ([I-D.ietf-v6ops-isp-scenarios-analysis], 257 section 5.2). 259 The protocol may send information about registration procedure when a 260 non-registered client requests registered mode (ex: URL to provider 261 registration web page). 263 4.3 Authentication 265 Authentication can be used to control user has access to the IPv6 266 services (section 5.2 [I-D.ietf-v6ops-isp-scenarios-analysis]) 268 The authentication mechanism supported should be compatible with 269 standardized methods that are generally deployed. In order to assure 270 interoperability, at least one common authentication method must be 271 supported. Other authentication may be supported and should be 272 negotiated between the client and server (e.g., SASL [RFC2222]). 274 4.4 Confidentiality 276 Assisted tunneling can be used across networks which are not under 277 the service provider control (e.g., roaming users). The tunnel 278 set-up protocol should allow protection of the authentication data 279 Section 4.3. This can be achieve by selecting an authentication 280 mechanism that protects the credentials (e.g., digest-md5). 282 Protecting the tunneled data (IPv6 in this case) should be possible. 283 A possible usage scenario is when an enterprise's users is working 284 off-site and tunneling to the enterprise network (7.5.2 285 [I-D.ietf-v6ops-ent-analysis]). Mechanisms do exist to make this 286 possible, such as using IPsec over IPv6 [RFC2401]. 287 [I-D.tschofenig-v6ops-secure-tunnels] may be applicable here but is 288 not analysed further. 290 4.5 Service Discovery 292 In order to facilitate deployment, the implementation should allow a 293 mechanism to discover the address of the server that will provide the 294 tunnel connectivity. 296 This discovery should be automatic when the protocol is used within 297 an ISP network. There is no service discovery requirements when used 298 outside the provider network (roaming users, 3rd party ISP). 300 Tunnel end-point discovery mechanism work 301 ([I-D.palet-v6ops-tun-auto-disc] may be applicable here. 303 4.6 NAT Traversal 305 Tunneling through IPv4 NAT must be supported. The protocol should 306 detect if an IPv4 NAT is in the path during the set-up phase (Section 307 5.2). If a NAT is present, an extra level of encapsulation is 308 necessary to tunnel IPv6 across the NAT. If no NAT is detected, 309 IPv6-over-IPv4 tunneling (IP protocol 41) is usually enough (see also 310 Section 4.7). 312 NAT traversal is identified as a requirement in ISP scenarios 313 (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) and unmanaged 314 scanarios (section 7, Recommendation 1 [RFC3904]) 316 4.7 Firewall Traversal 318 Even if no NAT is in the tunnel path, there may be a firewall which 319 prohibits IP protocol 41. In such case, the tunnel encapsulation 320 selection based on NAT detection (Section 5.2) will select a tunnel 321 that will not work. 323 In some cases, when the firewall is managed by the ISP or customer, 324 it can be configured to allow IP protocol 41. In such cases this may 325 not be an issue (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) 327 But in order to be functional in any situation (e.g., firewall 328 lacking feature), the assisted tunneling implementation must allow a 329 user to explicitly specify the desired tunnel encapsulation, 330 regardless of the NAT detection process. 332 4.8 Accounting 334 The assisted tunneling should include tools for managing and 335 monitoring the provided service. Such information can be used to 336 plan service capacity (traffic load) or billing information. 338 Some useful accounting data are (not exhaustive list): 340 o Tunnel counters (traffic in/out) 342 o User utilization (tunnel uptime) 344 o System logging (authentication failures, resource exhaustion, 345 etc.) 347 The interface used to provide such information can be through SNMP or 348 an AAA protocol (e.g., RADIUS accounting). 350 5. General Requirements 352 5.1 Scalability 354 The tunnel set-up protocol must be scalable. Typically, this 355 protocol should be deployable in an ISP or enterprise network. 357 A scalability requirement which is not related to the protocol itself 358 is to be able to deploy multiple servers inside the ISP network. To 359 do so, the server implementation would possibly need some load 360 balancing feature and an IPv6 IGP. 362 5.2 NAT Considerations 364 The assisted tunnel established by the protocol to be designed must 365 work with the existing infrastructure, in particular it must be 366 compatible with the various customer premise equipments available 367 today. This means that, in particular, the tunnels must be able to 368 traverse one or many NAT boxes of different kinds. There is no 369 requirement for any particular NAT traversal technology. However, as 370 NAT traversal usually requires an extra layer of encapsulation, the 371 tunnel set-up protocol should be able to detect automatically the 372 presence of one or more NAT boxes in the path. 374 The implementation� must provide an option to turn on extra 375 encapsulation manually. In order to assure interoperability, at 376 least one common tunnel encapsulation type must be supported. 378 5.3 Keep-alive 380 When a tunnel has to cross a NAT box, the mapping established by the 381 NAT must be preserved as long as the tunnel is in use. This is 382 usually achieved by sending keep alive messages across the tunnel. 383 Also, the same keep alive messages can enable the ISP tunnel end 384 point to perform garbage collection of its resources when tunnels are 385 not in use anymore. To enable those two functionalities, the tunnel 386 set-up protocol must include the transmission of keep-alive messages. 387 A client may choose not to send those messages (for example on ISDN 388 type links). In this case, the client should be able to handle a 389 tunnel disconnect event and be able to restart the set-up phase to 390 re-establish the tunnel. 392 5.4 Security 394 The tunnel set-up protocol must not introduce any new vulnerability 395 to the network. See security considerations in Section 7. 397 5.5 Traceability 399 In some production environment, traceability is an important 400 consideration ([I-D.ietf-v6ops-isp-scenarios-analysis], section 5.4). 401 The tunnel set-up protocol must be instrumentable to enable the 402 collection of usage data that can be used, for example, for capacity 403 planning. 405 5.6 Phase Out 407 This assisted tunneling mode is only a transition mechanism to enable 408 ISP to jump start IPv6 service without requiring an immediate global 409 upgrade of access networks and instead enabling a progressive roll 410 out. Once IPv6 is available natively in the access network 411 connecting a customer, there is no reason to keep using tunnels. So 412 the implementation should have a provision to enable the ISP to 413 signal the user to use native IPv6 instead. 415 5.7 Extensibility 417 The protocol must be extensible to support tunnel encapsulation other 418 than IPv6 over IPv4 and IPv6 over transport over IPv4. In 419 particular, encapsulation of IPv4 over IPv6 (section 7 420 [I-D.ietf-v6ops-isp-scenarios-analysis], section 7 [RFC3904], section 421 6 [I-D.ietf-v6ops-ent-analysis]) or IPv6 over IPv6 could be defined. 423 6. Compatibility with other Transition Mechanisms 425 The tunnel set-up protocol is not required to be compatible with any 426 existing transition mechanism. Although, a great deal of experience 427 can be drawn from the operation of tunnel brokers currently using the 428 TSP protocol [I-D.blanchet-v6ops-tunnelbroker-tsp]. 430 7. Security Considerations 432 The establishment of a tunnel can be compared to Mobile IP 433 technology, where traffic can be redirected to go from one place to 434 another one. So similar threats exists. In particular, when a 435 customer is asking for the set-up of a tunnel ending at IP address X, 436 the ISP should check: 438 o the customer is allowed to set-up this tunnel, i.e. he "owns" the 439 IPv6 prefix. 441 o the customer is allowed to terminate the tunnel where he said he 442 would, i.e. he "owns" the IPv4 tunnel endpoint. 444 The first check is an authentication issue. The second may be more 445 complex. The protocol must make sure that the tunnel is established 446 to the legitimate and authenticated destination. IPv4 return 447 routability checks could help this validation. Also, when the user 448 is within the ISP access network, strict ingress filtering can help 449 prevent IPv4 address spoofing. 451 8. Acknowlegements 453 This draft has greatly benefited from substantial inputs by Pekka 454 Savola. 456 The following people provided feedback on this work (in no particular 457 order): Carl Williams, Brian Carpenter, Christian Huitema, Jordi 458 Palet, Jeroen Massar, Erik Nordmark, Soohong Daniel Park, Suresh 459 Satapati, Fred Tremplin, Karim El-Malki, Tim Chown, Gert Doering, 460 Soliman Hesham. 462 Thanks to Mark Prior and Bernard Tuy for providing input from an ISP 463 perspective to validate many requirements. 465 9. References 467 9.1 Normative References 469 [I-D.ietf-v6ops-ent-analysis] 470 Bound, J., "IPv6 Enterprise Network Analysis", 471 draft-ietf-v6ops-ent-analysis-00 (work in progress), 472 September 2004. 474 [I-D.ietf-v6ops-isp-scenarios-analysis] 475 Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola, 476 "Scenarios and Analysis for Introducing IPv6 into ISP 477 Networks", draft-ietf-v6ops-isp-scenarios-analysis-03 478 (work in progress), June 2004. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 484 Tunnel Broker", RFC 3053, January 2001. 486 [RFC3904] Huitema, C., Austein, R., Satapati, S. and R. van der Pol, 487 "Evaluation of IPv6 Transition Mechanisms for Unmanaged 488 Networks", RFC 3904, September 2004. 490 9.2 Informative References 492 [I-D.blanchet-v6ops-tunnelbroker-tsp] 493 Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the 494 Tunnel Setup Protocol(TSP)", 495 draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in 496 progress), June 2004. 498 [I-D.huitema-v6ops-teredo] 499 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 500 NATs", draft-huitema-v6ops-teredo-02 (work in progress), 501 June 2004. 503 [I-D.ietf-ngtrans-isatap] 504 Templin, F., Gleeson, T., Talwar, M. and D. Thaler, 505 "Intra-Site Automatic Tunnel Addressing Protocol 506 (ISATAP)", draft-ietf-ngtrans-isatap-22 (work in 507 progress), May 2004. 509 [I-D.palet-v6ops-tun-auto-disc] 510 Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery 511 for Tunneling Mechanisms", 512 draft-palet-v6ops-tun-auto-disc-01 (work in progress), 513 June 2004. 515 [I-D.tschofenig-v6ops-secure-tunnels] 516 Tschofenig, H., "Using IPsec to Secure IPv6-over-IPv4 517 Tunnels", draft-tschofenig-v6ops-secure-tunnels-01 (work 518 in progress), July 2004. 520 [RFC2222] Myers, J., "Simple Authentication and Security Layer 521 (SASL)", RFC 2222, October 1997. 523 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 524 Internet Protocol", RFC 2401, November 1998. 526 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 527 SASL Mechanism", RFC 2831, May 2000. 529 Authors' Addresses 531 Florent Parent 532 Hexago 533 2875 boul. Laurier, suite 300 534 Sainte-Foy, QC G1V 2M2 535 Canada 537 EMail: Florent.Parent@hexago.com 539 Alain Durand 540 SUN Microsystems,inc. 541 17 Network circle UMPK17-202 542 Menlo Park, CA 94025 543 USA 545 EMail: Alain.Durand@sun.com 547 Alain Baudot 548 France Telecom R&D 549 42, rue des coutures 550 14066 Caen, 551 France 553 EMail: alain.baudot@rd.francetelecom.com 555 Appendix A. Changes from version 00 556 o Non-registered mode removed (now covered in generic zero-conf 557 tunneling draft). Text throughout the document changed to reflect 558 this. 560 o 562 o Renamed title from "requirements" to "goals" 564 o Changed imperatives to lowercase 566 o /128 endpoints replaced by /64 568 o Removed DNS considerations 570 o Added many references to other v6ops scenario documents 572 o Removed the appendix on protocol requirements summary 574 o Removed references to 3GPP scenario 576 Intellectual Property Statement 578 The IETF takes no position regarding the validity or scope of any 579 Intellectual Property Rights or other rights that might be claimed to 580 pertain to the implementation or use of the technology described in 581 this document or the extent to which any license under such rights 582 might or might not be available; nor does it represent that it has 583 made any independent effort to identify any such rights. Information 584 on the procedures with respect to rights in RFC documents can be 585 found in BCP 78 and BCP 79. 587 Copies of IPR disclosures made to the IETF Secretariat and any 588 assurances of licenses to be made available, or the result of an 589 attempt made to obtain a general license or permission for the use of 590 such proprietary rights by implementers or users of this 591 specification can be obtained from the IETF on-line IPR repository at 592 http://www.ietf.org/ipr. 594 The IETF invites any interested party to bring to its attention any 595 copyrights, patents or patent applications, or other proprietary 596 rights that may cover technology that may be required to implement 597 this standard. Please address the information to the IETF at 598 ietf-ipr@ietf.org. 600 Disclaimer of Validity 602 This document and the information contained herein are provided on an 603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 605 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 606 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 607 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Copyright Statement 612 Copyright (C) The Internet Society (2004). This document is subject 613 to the rights, licenses and restrictions contained in BCP 78, and 614 except as set forth therein, the authors retain all their rights. 616 Acknowledgment 618 Funding for the RFC Editor function is currently provided by the 619 Internet Society.