idnits 2.17.1 draft-ietf-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 629 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. == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The registered mode: - MUST be supported by the protocol - RECOMMENDED to be implemented on clients and servers/brokers - implementation SHOULD turn it off by default - implementation MUST allow it to be turned on - MUST support single address assignment - MUST support stable IPv6 address - MUST support prefix delegation, SHOULD be able to turn off The registered part of the protocol SHOULD not be too different from the non registered one, so as to minimize code difference between the two modes -- 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) == Unused Reference: '2119' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'ISP' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'UNMANAGED' is defined on line 480, but no explicit reference was found in the text == Unused Reference: '3GPP' is defined on line 484, but no explicit reference was found in the text == Unused Reference: '2831' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'ISATAP' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'TEREDO' is defined on line 500, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3053' == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-isp-scenarios-analysis-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-isp-scenarios-analysis (ref. 'ISP') == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-unmaneval-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-unmaneval (ref. 'UNMANAGED') == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-09 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-analysis (ref. '3GPP') -- Obsolete informational reference (is this intentional?): RFC 2831 (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-21 == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-01 == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-00 Summary: 7 errors (**), 0 flaws (~~), 19 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 June, 24, 2004 F. Parent 4 Expires December 23, 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, getting IPv6 connectivity to the customers 53 involves upgrading the access network to support IPv6, which can take 54 a long time and/or be costly. A tunneled infrastructure can be used 55 as a low cost migration path [ISP, section 5.1]. 57 With such an infrastructure, the ISP can connect its customers to its 58 IPv6 network using its production IPv6 address space, thus 59 facilitating migration towards native IPv6 deployment. The IPv6 60 deployment roadmap for connecting customers becomes: 62 - assisted tunneling infrastructure to early adopters, 63 - native IPv6 to customers where economically justified, 64 - native IPv6 to all customers. 66 Note that, as the addressing space used during the transition to 67 native remains the same the customer routing, filtering, accounting 68 [ISP, section 5.] stay the same, and there is no need to maintain any 69 kind of relay. 71 "Assisted tunneling" is used in this document to described a 72 transition mechanism where the parameters to configure a bi- 73 directional tunnel between an end-node (or leaf network) and a router 74 in the core of an ISP are exchanged through a tunnel set-up protocol. 75 Although this exchange can be automated, this remains different from 76 transition mechanisms like 6to4 that is fully automatic. Teredo and 77 ISATAP, on the other hand, practically require receiving information 78 about the available prefix or address from the server/router, 79 comparable to the most simple form of assisted tunneling. 81 In particular, the 'registered' mode defined in section 4 enables 82 explicit access control to the tunneled IPv6 connectivity, where the 83 other transion mechanisms have to rely on other kinds of control 84 (e.g., access control based on the IPv4 address). 86 This document analyze the requirements for such a tunnel set-up 87 protocol. The v6ops WG scenario and evaluation documents for 88 deploying IPv6 within common network environments are used as input 89 to this document. 91 2. Applicability 93 Assisted tunneling is applicable in different IPv6 transition 94 scenarios. The focus of this document is to define the requirements 95 to apply this mechanism in the IPv4 ISP context making the following 96 assumptions: 98 - ISP is offering IPv6 connectivity to its customers initially 99 using controlled tunneling infrastructure [ISP, 5.1 Steps in 100 Transitioning Customer Connection Networks] 102 - The customer configuration may be diverse, and not necessarily 103 predictable by the ISP. The protocol must be able to adapt to the 104 following cases, for example by choosing the most optimal tunnel 105 encapsulation depending on the presence of a NAT. 106 - a single node, 107 - a leaf network, 108 - using a globally routable IPv4 address, 109 - behind a NAT (customer or ISP owned), 110 - using dynamic IPv4 address (internally or externally to the 111 NAT) 113 There are actually two cases where the IPv4 address of the customer 114 tunnel end point can be dynamic, and both must be supported: 116 - The device used as tunnel end point is using a dynamic IPv4 117 address provided by the ISP. 118 - The device used as tunnel end point is located behind a customer 119 owned NAT box that is also acting as a local DHCP server. In that 120 case, the device IPv4 address may change after a reboot. 122 Althought the main focus of this document is the ISP scenario, 123 assisted tunneling is applicable in all the other scenarios: 124 unmanaged, enterprise and 3GPP. 126 In unmanaged networks, assisted tunneling is applicable in the case A 127 (a gateway which does not provide IPv6 at all) [UNMANAGED, section 3] 128 and C (a dual-stack gateway connected to an IPv4-only ISP) 129 [UNMANAGED, section 5]. 131 In 3GPP networks, assisted tunneling can be used in the context of 132 dual stack UE connecting to IPv6 nodes through a 3GPP network that 133 only supports IPv4 PDP contexts [3GPP, 3.1]. 135 3. Requirements for Simplicity 137 The tunnel set-up protocol must be simple to implement and easy to 138 deploy. In particular, it should not depend on any complex, yet to be 139 designed, protocols or infrastructure pieces. 141 This protocol is a transition mechanism, thus does not need to be 142 perfect. As a matter of fact, making it perfect would be counter 143 productive, at it would first delay its definition, then make its 144 deployment more cumbersome and, last but not least, diminish the 145 incentives to deploy native IPv6. 147 4. Protocol Requirements 149 Assisted tunneling can be provided in two different modes. "Non- 150 registered" mode is a simple mode with no user registration, 151 essentially deployed in a controlled and "authenticated" environment 152 where the service is made available to all the IPv4 customers.. The 153 "registered" mode is aimed at production deployment which requires 154 the user to be authenticated. This mode can be used to offer the 155 tunneling service to roaming users or restrict the service to 156 specific (authenticated) users. The tunnel set-up protocol must 157 support both modes, however ISP deploying it may choose to only 158 support one mode of operation. 160 Assisted tunneling in the non-registered mode is defined for simple 161 "plug & play" scenarios. In this mode, the tunnel establishment is 162 triggered through the execution of a simple program, without any pre- 163 configuration or pre-registration required from the end-user. 165 The tunnel established is "anonymous" in a sense as the end-user does 166 not register explicitly to the server. An ISP using the protocol in 167 this mode may be offering a free service and doesn't wish to require 168 any form of registration. This free service can also be used to offer 169 trial IPv6 service limited to the ISP customers by relying on IPv4 170 access control. 172 The registered mode offers some extra features documented in latter 173 sections. This mode is most valuable in a provider network where 174 deployment of IPv6 is done in a more controlled manner or when the 175 provider cannot rely on IPv4 related authentication (e.g. roaming 176 customers). In such networks, ease of debugging, traceability, 177 filtering and so on are important features. 179 4.1. Address and Prefix Delegation 181 Assignment of an IPv6 address (/128) to the end-node must be 182 supported in both modes. 184 In non-registered mode, the IPv6 address is "transient" and may 185 change, but the protocol SHOULD offer a mechanism to provide IPv6 186 address stability in this mode (e.g. cookie mechanism). The 187 implementation of this mechanism MUST allow this feature to be turned 188 off. In registered mode, the protocol MUST be able to support 189 servers willing to offer stable IPv6 prefixes to the authenticated 190 customers. 192 The registered mode MUST support delegation of a single address or a 193 whole prefix. The length of the IPv6 prefix delegated MUST be 194 configurable on the server. The non-registered mode MAY support 195 prefix delegation. 197 See section 5.9 for DNS considerations. 199 4.2 Registration 201 The registration of credentials is external to the protocol. A 202 service provider SHOULD be able to use its existing authentication 203 database. If necessary, an implementation may provide hooks to 204 facilitate integration with the ISP management infrastructure (e.g. 205 RADIUS for AAA, billing). 207 The protocol MAY send information about registration procedure when a 208 non-registered client requests registered mode (ex: URL to provider 209 registration web page). 211 4.3. Authentication 213 The authentication mechanism supported should be compatible with 214 standardized methods that are generally deployed. In order to assure 215 interoperability, at least one common authentication method MUST be 216 supported. Other authentication MAY be supported and should be 217 negotiated between the client and server (e.g., SASL [2222]). 219 4.4. Service Discovery 221 In order to offer "plug & play", the implementation SHOULD allow a 222 mechanism to discover the address of the server that will provide the 223 tunnel connectivity. This discovery should be automatic within an ISP 224 network. 226 4.5. NAT Traversal 228 Tunneling through IPv4 NAT MUST be supported. The protocol should 229 detect if an IPv4 NAT is in the path during the set-up phase (section 230 5.3). If a NAT is present, an extra level of encapsulation is 231 necessary to tunnel IPv6 across the NAT. If no NAT is detected, 232 IPv6-over-IPv4 tunneling (IP protocol 41) is enough. 234 4.6. Firewall Traversal 236 Even if no NAT is in the tunnel path, there may be a firewall which 237 prohibits IP protocol 41. In such case, the tunnel encapsulation 238 selection based on NAT detection (section 5.3) will select a tunnel 239 that will not work. 240 The implementation MUST allow a user to explicitly specify the 241 desired tunnel encapsulation, regardless of the NAT detection 242 process. 244 4.7. Accounting 246 The assisted tunneling should include tools for managing and 247 monitoring the provided service. Such information can be used to plan 248 service capacity (traffic load) or billing information. 250 Some useful accounting data are (not exhaustive list): 251 - Tunnel counters (traffic in/out) 252 - User utilization (tunnel uptime) 253 - System logging (authentication failures, resource exhaustion, 254 etc.) 256 The interface used to provide such information can be through SNMP or 257 an AAA protocol (e.g., RADIUS accounting). 259 4.8. Security Threat Analysis 261 The non registered mode does not require explicit authentication of 262 the user. Access control may be performed using e.g., IPv4 address. 263 The mode essentially offer the IPv6 service to any of its IPv4 264 customers. Deployment of the service with this mode must be done 265 carefully. In particular, security considerations must be taken into 266 account. 268 Non registered service should be limited to the provider network, 269 where access of the service can be controlled based on the IPv4 270 address of the users (filtering). If specific filtering is not in 271 place in the ISP core network, anyone on the Internet could start 272 using its tunneling infrastructure to get free IPv6 connectivity, 273 transforming effectively the ISP into a IPv6 transit provider. 275 If IPv4 address spoofing is possible within the access network, a 276 number of DoS attack can happen. For example, customer A can 277 impersonate someone else's IPv4 address during the set-up phase and 278 redirect a tunnel to that IP address. A then can, for example, start 279 a high bandwidth multimedia flow across that tunnel and saturate its 280 victim's up-link. 282 But even with filtering in place, the non registered mode is 283 vulnerable to denial of service attacks: a customer A behind a NAT 284 can use a large number of (private) IPv4 addresses and request 285 multiple tunnels.That would quickly saturate the ISP tunnel server 286 infrastructure. In order to minimize such attacks, IPv4 return 287 routability checks could help blocking many DoS attack. Also, the 288 server implementation should offer a way to throttle and limit the 289 number of tunnel established to the same (non-private) IPv4 address. 291 In registered mode, the protocol must make sure that the tunnel is 292 established to the legitimate and authenticated destination, again to 293 avoid having someone establish a tunnel to a potential victim. IPv4 294 return routability checks could help block possible DoS attacks. 296 5. General Requirements 298 5.1 Scalability 300 The tunnel set-up protocol must be scalable. Typically, this protocol 301 should be deployable in broadband ISP. 303 5.2 Service discovery requirements 305 The discovery part of the tunnel set-up protocol should be as 306 automatic as possible. 308 The discovery mechanism must be able to scale for large ISP who cover 309 different geographical areas and/or have a large number of customers. 311 Customers may very well try to use this tunnel set-up protocol even 312 if their ISP is not offering the service. In this case, without any 313 previous action taken by their ISP, the discovery part of the tunnel 314 set-up protocol must be able to abort immediately and display the 315 customers a message explaining that no service is available. 317 5.3 NAT Considerations 319 The assisted tunnel established by the protocol to be designed must 320 work with the existing infrastructure, in particular it must be 321 compatible with the various customer premise equipments available 322 today. This means that, in particular, the tunnels must be able to 323 traverse one or many NAT boxes of different kinds. There is no 324 requirement for any particular NAT traversal technology. However, as 325 NAT traversal usually requires an extra layer of encapsulation, the 326 tunnel set-up protocol SHOULD be able to detect automatically the 327 presence of one or more NAT boxes in the path. 328 The implementation MUST provide an option to to turn on extra 329 encapsulation manually. In order to assure interoperability, at 330 least one common tunnel encapsulation type MUST be supported. 332 5.4 Keep-alive 334 When a tunnel has to cross a NAT box, the mapping established by the 335 NAT must be preserved as long as the tunnel is in use. This is 336 usually achieved by sending keep alive messages across the tunnel. 337 Also, the same keep alive messages can enable the ISP tunnel end 338 point to perform garbage collection of its resources when tunnels are 339 not in use anymore. To enable those two functionalities, the tunnel 340 set-up protocol must include the transmission of keep-alive messages. 341 A client MAY choose not to send those messages (for example on ISDN 342 type links), but should then expect that the tunnel may be 343 disconnected at any time by the ISP and be prepared to restart the 344 set-up phase. 346 5.5 Latency in Set-up Phases 348 In certain type of networks, keeping tunnels active all the time is 349 not possible (e.g., limited number of tunnels on server) or simply 350 too expensive (e.g., wireless environments where periodic 351 transmission is expensive). In those environments, the protocol must 352 be able to set-up tunnels on demand of the IPv6 applications 353 requiring external connectivity. 355 The tunnel set-up protocol must then have a low enough latency to 356 enable quasi-instant configuration. Latency is usually a function of 357 the number of packet exchanges required, so minimizing this parameter 358 is important. 360 5.6 Security 362 The tunnel set-up protocol must not introduce any new vulnerability 363 to the network. 365 5.7 Traceability 367 In production environment, traceability is an important 368 consideration. The tunnel set-up protocol must be instrumentable to 369 enable the collection of usage data that can be used, for example, 370 for capacity planning. 372 5.8 Phase Out 374 This assisted tunneling mode is only a transition mechanism to enable 375 ISP to jump start IPv6 service without requiring an immediate global 376 upgrade of access networks and instead enabling a progressive roll 377 out. Once IPv6 is available natively in the access network 378 connecting a customer, there is no reason to keep using tunnels. So 379 the implementation SHOULD have a provision to enable the ISP to 380 signal the user to use native IPv6 instead. 382 5.9 Extensibility 384 The protocol MUST be extensible to support tunnel encapsulation other 385 than IPv6 over IPv4 and IPv6 over transport over IPv4. In particular, 386 encapsulation of IPv4 over IPv6 or IPv6 over IPv6 could be defined. 388 5.10 DNS considerations 390 It should be possible to have the server side of the protocol 391 automatically register the assigned IPv6 address in the DNS system 392 (AAAA and PTR records) using the ISP name space. Nothing specific is 393 required in the protocol to support this. The details can be 394 implementation specific. 396 If stable prefix delegation is done, it is expected that the DNS 397 delegation of the associated reverse DNS zone will be also stable and 398 thus can be performed out of band, so there is no requirement to 399 perform this delegation at the tunnel set-up time. 401 6. Compatibility with other Transition Mechanisms 403 6.1 TSP 405 The tunnel set-up protocol is not required to be compatible with TSP 406 [TSP] or any particular implementation of the tunnel broker model 407 [3053]. Although, a great deal of experience can be drawn from the 408 operation of tunnel brokers currently using the TSP protocol. 410 6.2 TEREDO 412 There is a large number of Teredo clients already deployed, the 413 tunnel set-up protocol should explore the avenue of providing a 414 compatibility mode with Teredo, at least in the 'simple' mode 415 described in section 4. However, it may turn out that supporting a 416 compatibility mode with Teredo either requires to change the Teredo 417 specifications and/or implement Teredo on the tunnel server side. In 418 that case, it might be simpler to say that the compatibility mode 419 should be manage on the client side instead of the server side, that 420 is leave it up to the client to use either one of them. 422 6.3 ISATAP 424 Similar considerations as Teredo, section 6.2, applies to Isatap. 425 However, as Isatap can not work accross NAT, it is of much less 426 interest in the framework of this document. 428 7. Security Considerations 430 The establishment of a tunnel can be compared to Mobile IP 431 technology, where traffic can be redirected to go from one place to 432 another one. So similar threats exists. In particular, when a 433 customer is asking for the set-up of a tunnel ending at IP address X, 434 the ISP should check: 435 - the customer is allowed to set-up this tunnel, i.e. he "owns" 436 the IPv6 prefix. 437 - the customer is allowed to terminate the tunnel where he said he 438 would, i.e. he "owns" the IPv4 tunnel endpoint. 440 The first check is simply an authentication issue. The second may be 441 more complex, but can be omitted if strict ingress filtering is in 442 place in the access network, i.e. the customer is effectively 443 prevented from sending packet with an IPv4 source address he does not 444 own. 446 See section 4.4 for specific security consideration in the non- 447 authenticated mode. 449 8. Acknowlegements 451 9. Author Addresses 453 Alain Durand 454 SUN Microsystems, Inc 455 17 Network circle UMPK17-202 456 Menlo Park, CA, 94025 457 USA 458 Mail: Alain.Durand@sun.com 460 Florent Parent 461 Hexago 462 2875 boul. Laurier, bureau 300 463 Sainte-Foy, QC G1V 2M2 464 Canada 465 Mail: Florent.Parent@hexago.com 467 10. Normative References 469 [2119] Bradner, S., "Key Words for Use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [3053] A. Durand, P. Fasano, I. Guardini, D. Lento., 473 "IPv6 Tunnel Broker", January 2001. 475 [ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 476 into ISP Networks", 477 draft-ietf-v6ops-isp-scenarios-analysis-01 (work in 478 progress), February 2004. 480 [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for 481 Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work 482 in progress), February 2004. 484 [3GPP] J. Wiljakka, "Analysis on IPv6 Transition in 3GPP Networks", 485 draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March 2004. 487 11. Informative References 489 [2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 490 Mechanism", RFC 2831, May 2000. 492 [2222] Myers, J., "Simple Authentication and Security Layer (SASL)", 493 RFC2222, October 1997. 495 [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, 496 "Intra-Site Automatic Tunnel Addressing Protocol 497 (ISATAP)", draft-ietf-ngtrans-isatap-21 (work in 498 progress), April 2004. 500 [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 501 NATs", draft-huitema-v6ops-teredo-01 (work in progress), 502 February 2004. 504 [TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup 505 Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 506 (work in progress), February 2004. 508 Appendix 1. Summary of the Protocol Requirements 510 The non registered mode: 511 - MUST be supported by the protocol to be designed 512 - RECOMMENDED to be implemented on client and servers/brokers 513 - implementation SHOULD turn it on be default 514 - implementation MUST allow it to be turned off 515 - MUST support single address assignment 516 - SHOULD support stable IPv6 address 517 - MAY support prefix delegation 519 The registered mode: 520 - MUST be supported by the protocol 521 - RECOMMENDED to be implemented on clients and servers/brokers 522 - implementation SHOULD turn it off by default 523 - implementation MUST allow it to be turned on 524 - MUST support single address assignment 525 - MUST support stable IPv6 address 526 - MUST support prefix delegation, SHOULD be able to turn off 527 The registered part of the protocol SHOULD not be too different from 528 the non registered one, so as to minimize code difference between the 529 two modes 531 12. Full Copyright Statement 533 Intellectual Property Statement 535 The IETF takes no position regarding the validity or scope of any 536 intellectual property or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; neither does it represent that it 540 has made any effort to identify any such rights. Information on the 541 IETF's procedures with respect to rights in standards-track and 542 standards-related documentation can be found in BCP-11. Copies of 543 claims of rights made available for publication and any assurances of 544 licenses to be made available, or the result of an attempt made to 545 obtain a general license or permission for the use of such 546 proprietary rights by implementors or users of this specification can 547 be obtained from the IETF Secretariat. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights which may cover technology that may be required to practice 552 this standard. Please address the information to the IETF Executive 553 Director. 555 Full Copyright Statement 557 Copyright (C) The Internet Society (2004). All Rights Reserved. 559 This document and translations of it may be copied and furnished to 560 others, and derivative works that comment on or otherwise explain it 561 or assist in its implementation may be prepared, copied, published 562 and distributed, in whole or in part, without restriction of any 563 kind, provided that the above copyright notice and this paragraph are 564 included on all such copies and derivative works. However, this 565 document itself may not be modified in any way, such as by removing 566 the copyright notice or references to the Internet Society or other 567 Internet organizations, except as needed for the purpose of 568 developing Internet standards in which case the procedures for 569 copyrights defined in the Internet Standards process must be 570 followed, or as required to translate it into languages other than 571 English. 573 The limited permissions granted above are perpetual and will not be 574 revoked by the Internet Society or its successors or assignees. 576 This document and the information contained herein is provided on an 577 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 578 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 579 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 580 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 581 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 583 Acknowledgment 585 Funding for the RFC Editor function is currently provided by the 586 Internet Society.