idnits 2.17.1 draft-vogt-dna-relocation-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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 155: '...e sent, the node SHOULD delay joining ...' RFC 2119 keyword, line 323: '...ly, mobile nodes SHOULD retransmit mul...' RFC 2119 keyword, line 324: '... ODAD. Each NS SHOULD be preceded by...' 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 (July 18, 2005) is 6828 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 (-11) exists of draft-ietf-ipv6-2461bis-03 == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-05 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-01 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 3775 (ref. '7') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational draft: draft-ietf-magma-snoop (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Vogt 3 Internet-Draft R. Bless 4 Expires: January 19, 2006 M. Doll 5 Universitaet Karlsruhe (TH) 6 G. Daley 7 Monash University 8 July 18, 2005 10 Analysis of IPv6 Relocation Delays 11 draft-vogt-dna-relocation-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 19, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 As mobile nodes move to new links, they need to resume their 45 communications in a timely fashion. To communicate, IPv6 nodes need 46 to complete router discovery, address auto-configuration, and other 47 tasks. Unfortunately, this depends on prior completion of the 48 Multicast Listener Discovery (MLD) protocol, introducing a mandatory 49 delay of up to one second. This document discusses where this can be 50 problematic and proposes solutions that can alleviate the problem. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1 Situation A . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2 Situation B . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3 Situation C . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.4 Situation D . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.5 Situation E . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1 Eliminating the Delay for MLD Reports . . . . . . . . . . 7 64 4.2 Using Optimistic Addresses Before the Initial NS . . . . . 8 65 4.3 Increasing Robustness . . . . . . . . . . . . . . . . . . 8 66 5. Brief Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 70 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . 14 73 1. Introduction 75 Mobile nodes require fast router discovery and auto-configuration of 76 global IPv6 addresses. New mechanisms defined in [1], [3], and [4] 77 attend to this. 79 IPv6 Neighbor Discovery [1] accelerates router discovery in that it 80 allows mobile nodes to forego the recommended backoff for the first 81 Router Solicitation (RS) after interface (re-) initialization. 82 Optimistic Duplicate Address Detection (ODAD) [3] allows early use of 83 new IPv6 addresses once an initial Neighbor Solicitation (NS) has 84 been sent. Nodes who support the Tentative Source Link-Layer Address 85 Option (TSLLAO) [4] can save additional address-resolution round 86 trips during router discovery and address auto-configuration. 88 Still, mobile nodes must send a MLD Report [5][6] at some stage 89 during router discovery or address auto-configuration. MLD Reports 90 are subject to a random backoff between 0 and 91 MAX_RTR_SOLICITATION_DELAY (1 second) time RFC 2462bis [2]. There is 92 currently no acceleration for this, defeating the benefits of the 93 afore-mentioned optimizations in many situations. 95 This document identifies such situations and suggests two approaches 96 to improve them: relaxing the delay for MLD Reports under certain 97 conditions or permitting use of optimistic addresses prior to the 98 initial NS. The document is considered a basis for further mailing 99 list discussion. It is supposed to aid the revision process of 100 existing DNA Working Group documents rather than to evolve itself 101 towards a separate document. 103 2. History 105 This problem was first raised and discussed on the IPv6 mailing list 106 [9]. The outcome was to not incorporate a delay relaxation for the 107 MLD Report into RFC 2461bis and RFC 2462bis, as it was unclear then 108 whether this could negatively impact other on-link nodes (both mobile 109 and stationary). Instead, the consensus was to discuss this in 110 greater detail in the DNA Working Group. 112 The problem appeared again in a similar context on the DNA mailing 113 list [10]. 115 3. Problem Statement 117 This section identifies five situations, A through E, in which IPv6 118 relocation is substantially delayed in spite of optimizations defined 119 by RFC 2461bis, ODAD, and TSLLAO. 121 In all situations, after changing links, the mobile node avoids using 122 its configured global unicast addresses during router discovery, 123 since it does not know before reception of a Router Advertisement 124 (RA) whether or not it has changed IPv6 attachment. Also, in order 125 to avoid Neighbor Cache pollution of on-link neighbors, the mobile 126 node must handle its configured link-local unicast addresses as if 127 those where tentative. 129 It is also assumed that the mobile node implements ODAD. 130 Nonetheless, the identified issues are essentially the same when the 131 mobile node uses non-optimized RFC 2462bis. 133 3.1 Situation A 135 Routers on the new IP link support the TSLLAO for RSs. The mobile 136 node solicits a unicast RA by sending an RS with an TSLLAO from the 137 unspecified address. 139 The TSLLAO allows the router to unicast the RA without performing 140 address resolution. What follows is the message exchange from the 141 mobile node's perspective: 143 1. MN sends an RS from the unspecified address with an TSLLAO. 144 2. MN receives an IPv6-multicast RA by link-layer unicast. 145 3. MN sends an MLD Report for an optimistic address. 146 4. MN sends an NS for the optimistic address, initiating ODAD. 148 The RS (step 1) may be sent immediately, even though this is the 149 first message transmitted after (re-) enabling the interface [1]. 151 From a standard's perspective, it is debatable whether or not the MLD 152 Report must be delayed. RFC 2462bis says in section 5.4.2: 154 Even if the Neighbor Solicitation is not going to be the first 155 message to be sent, the node SHOULD delay joining the solicited- 156 node multicast address by a random delay between 0 and 157 MAX_RTR_SOLICITATION_DELAY if the address being checked is 158 configured by a router advertisement message sent to a multicast 159 address. 161 The RA (step 2) is an IPv6 multicast, yet a link-layer unicast. 162 Since there is only a single recipient in this case, omitting the 163 delay for the MLD Report would be feasible. But the mobile node must 164 inspect the link-layer destination address in order to determine 165 whether the RA was a multicast or a unicast. This may not always be 166 possible. 168 3.2 Situation B 170 Routers on the new IP link support the TSLLAO for RSs. The mobile 171 node solicits a unicast RA by sending an RS with an TSLLAO from an 172 optimistic address. Overall, it sends and receives the following 173 messages in sequence: 175 1. MN sends an MLD Report for an optimistic address. 176 2. MN sends an NS for the optimistic address, initiating ODAD. 177 3. MN sends an RS with an TSLLAO from the optimistic address. 178 4. MN receives a unicast RA. 180 The MLD Report (step 1) is delayed for up to 1 second 181 (MAX_RTR_SOLICITATION_DELAY) because it is the first message 182 transmitted after (re-) enabling the interface [2]. 184 3.3 Situation C 186 Routers on the new IP link do not support the TSLLAO for RSs. The 187 mobile node solicits an RA. Routers unicast solicited RAs. 189 Soliciting a unicast RA requires the mobile node to send an RS from 190 an optimistic address (without a SLLAO). This is the complete 191 message exchange: 193 1. MN sends an MLD Report for an optimistic address. 194 2. MN sends an NS for the optimistic address, initiating ODAD. 195 3. MN sends an RS from the optimistic address. 196 4. MN receives an NS for the optimistic address from the router. 197 5. MN sends a Neighbor Advertisement (NA) for the optimistic address 198 to the router. 199 6. MN receives a unicast RA. 201 The MLD Report (step 1) is delayed for up to 1 second 202 (MAX_RTR_SOLICITATION_DELAY) because it is the first message 203 transmitted after (re-) enabling the interface [2]. 205 3.4 Situation D 207 Routers on the new IP link do not support the TSLLAO for RSs, but do 208 send unsolicited multicast RAs every 30ms to 70ms according to rules 209 in [7]. The mobile node sends and receives the following messages in 210 sequence: 212 1. MN receives a multicast RA. 213 2. MN sends an MLD Report for an optimistic address. 215 3. MN sends an initial NS for the optimistic address (ODAD). 217 The MLD Report (step 2) is delayed for two reasons. First, it is the 218 first message transmitted after (re-) enabling the interface. This 219 calls for a delay of up to 1 second (MAX_RTR_SOLICITATION_DELAY) [2]. 220 Second, the MLD Report is sent in response to a multicast RA. This 221 also calls for a delay of up to 1 seconds 222 (MAX_RTR_SOLICITATION_DELAY) [2]. 224 3.5 Situation E 226 Routers on the new IP link do not support the TSLLAO for RSs. The 227 mobile node solicits a multicast RA. 229 The mobile node can send the RS from the unspecified address, 230 eliminating the requirement to initiate ODAD at this point. Overall, 231 it sends an receives the following messages: 233 1. MN sends an RS from the unspecified address. 234 2. MN receives a multicast RA. 235 3. MN sends an MLD Report for an optimistic address. 236 4. MN sends an NS for the optimistic address, initiating ODAD. 238 The RS (step 1) may be sent immediately, even though this is the 239 first message transmitted after (re-) enabling the interface [1]. 241 The multicast RA (step 2) is delayed for up to 3 seconds (maximum of 242 MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS) [1]. 244 In addition, the MLD Report (step 3) is delayed for up to 1 second 245 (MAX_RTR_SOLICITATION_DELAY) because it is sent in response to a 246 multicast RA [2]. 248 4. Possible Solutions 250 The following approaches can be used to eliminate the high IPv6 251 relocation delays identified in Section 3. 253 4.1 Eliminating the Delay for MLD Reports 255 The random backoff for MLD Reports is "RECOMMENDED" in RFC 2461bis 256 and RFC 2462bis to resolve contention amongst multiple neighbors when 257 booting up simultaneously. It has little benefit when applied by a 258 mobile node after IPv6 relocation. 260 It hence seems feasible to eliminate the backoff for MLD Reports 261 after IPv6 relocation. In particular, both of the following two 262 conditions would have to be met: 264 o The mobile node has received a trigger from its local link layer 265 indicating that an interface, which was previously operational, 266 has gone down and come up again. 267 o The MLD Report is either the first message transmitted on the new 268 link or it is sent in response to a unicast RA indicating IPv6 269 relocation. 271 4.2 Using Optimistic Addresses Before the Initial NS 273 ODAD allows (limited) use of optimistic addresses after an initial NS 274 has been sent. This NS must be preceeded by a MLD Report for the 275 corresponding solicited-nodes multicast address. The random backoff 276 for the MLD Report foils the benefits of ODAD. 278 Fortunately, it appears feasible to allow (limited) use of an 279 optimistic address even before the initial NS is sent. The delay for 280 the MLD Report can so be moved to a non-critical phase. 282 Note that mobile nodes would still have to send a MLD Report prior to 283 sending a RS from an optimistic address in situation C: Since the RS 284 does not include a SLLAO, the router will have to invoke address 285 resolution for the optimistic address. Sending the MLD Report 286 ensures that the mobile node can receive the NS in the presence of 287 snooping switches. Note that RFC 2461bis currently does not require 288 transmission of a MLD Report prior to the RS in case of interface 289 (re-) initialization. 291 4.3 Increasing Robustness 293 The optimum desynchonization delays for signaling messages such as 294 the MLD Report are highly application- and environment-specific. RFC 295 2461bis and RFC 2462bis are tailored towards stationary nodes, so the 296 delays of up to MAX_RTR_SOLICITATION_DELAY (1 second) are acceptable 297 and make sense. However, for mobile nodes, such delays will badly 298 impact real-time applications like VoIP. It may be possible in rare 299 deployment scenarios to hard-code application- and environment- 300 specific behavior into the nodes. But this approach is infeasible in 301 general, simply because the applications and environments are unknown 302 a priori. 304 One solution to this problem is to differentiate between messages for 305 which loss is recoverable and messages for which it is not. E.g., 306 loss of an RS can be detected by the mobile node by lack of a 307 corresponding RA. In this (unlikely) case, the mobile node loses 308 some time, but will eventually retransmit the RS. On the other hand, 309 loss of a MLD Report or NS sent during ODAD cannot be detected, 310 because there is no expected response. This might lead to an address 311 duplicate, which is currently not recoverable. 313 In this sense, a mobile node should retransmit an MLD Report and RS 314 after an appropriate time period if it fails to receive a 315 corresponding RA. For the purpose of ODAD, the mobile node should 316 retransmit MLD Reports and NSs in background mode two, three, or more 317 times. An optimistic address would then be considered unique only 318 after none of these transmissions resulted in a response. The mobile 319 node may use plenty of desynchronization delay without negatively 320 affecting applications because all transmission occur in background 321 mode. 323 Specifically, mobile nodes SHOULD retransmit multiple NSs during 324 ODAD. Each NS SHOULD be preceded by a retransmitted MLD Report. 325 Thus, robustness to loss of (undelayed) MLD Report can be increased. 327 5. Brief Analysis 329 The conditions defined in Section 4.1 should be conservative enough 330 to limit the proposed optimization to non-critical situations. In 331 particular, the random backoff for MLD Reports should be retained for 332 responses to multicast RAs as well as when the node boots up. This 333 assumes that a reliable indication for these conditions can be 334 implemented. 336 Generally, collisions of MLD and IPv6 Neighbor Discovery messages are 337 more likely to occur in a mobile environment than in a stationary 338 because mobile nodes use these messages for movement detection and 339 IPv6 relocation. Delaying the MLD Report does not mitigate this, 340 however. 342 Retransmitted MLD Reports and RSs, as described in Section 4.3, may 343 repair router-discovery failure in situation C due to a collided 344 (undelayed) MLD Report. Similarly, retransmitting MLD Reports and 345 NSs, during ODAD, is likely to resolve collisions and ensure correct 346 operation of ODAD in situations A through E. 348 ODAD may still fail when neighbors located at different sides of a 349 snooping switch simultaneously attempt to auto-configure the same 350 IPv6 address. If one of the nodes' MLD Report collides, but its NS 351 does not, that node will not receive the competing node's NS. The 352 result is that the former "wins" this race condition and the latter 353 "loses" it. 355 More serious is a situation in which both MLD Reports get lost. The 356 MLD state will eventually be repaired by the retransmitted MLD Report 357 of both the mobile node and the neighbor. But there will be two 358 nodes on the link using the same address. The IPv6 protocol suite 359 currently does not recover from configured duplicate addresses. 361 Transmission of MLD Reports can lead to undesired signaling overhead. 362 Furthermore, with respect to router discovery and address auto- 363 configuration, MLD Reports have a benefit only in the presence of 364 snooping switches [8]. The crux is that a mobile node usually does 365 not know a new link's topology at attachment time, so it seems that 366 omission of MLD Reports would become feasible only with appropriate 367 support from the link layer. 369 6. Security Considerations 371 The optimizations proposed in this document affect desynchronization 372 delays and retransmission policies applied by mobile nodes. 373 Malicious nodes can always choose their own delays and policies, of 374 course. As a consequence, the optimizations proposed in this 375 document do not imply security concerns in addition to those which 376 already exist in the standard IPv6 protocol suite [1][2], in ODAD 377 [3], or in TSLLAO [4]. 379 7. References 381 [1] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 382 draft-ietf-ipv6-2461bis-03 (work in progress), May 2005. 384 [2] Thomson, S., "IPv6 Stateless Address Autoconfiguration", 385 draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. 387 [3] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 388 draft-ietf-ipv6-optimistic-dad-05 (work in progress), 389 February 2005. 391 [4] Daley, G., "Tentative Source Link-Layer Address Options for 392 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in 393 progress), February 2005. 395 [5] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 396 Discovery (MLD) for IPv6", RFC 2710, October 1999. 398 [6] Rolland, R., Luis, L., , S., Deering, S., Fenner, W., Kouvelas, 399 I., and B. Haberman, "Multicast Listener Discovery Version 2 400 (MLDv2) for IPv6", RFC 3810, June 2004. 402 [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 403 IPv6", RFC 3775, June 2004. 405 [8] Christensen, M., Kimball, K., and F. Solensky, "Considerations 406 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 407 (work in progress), February 2005. 409 [9] "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6 410 mailing list, May 27, 2005, . 413 [10] "DAD and MLD Interaction", Discussion on the DNA mailing 414 list, June 13, 2005, . 417 Authors' Addresses 419 Christian Vogt 420 Institute of Telematics 421 Universitaet Karlsruhe (TH) 422 P.O. Box 6980 423 76128 Karlsruhe 424 Germany 426 Email: chvogt@tm.uka.de 427 URI: http://www.tm.uka.de/~chvogt/ 429 Roland Bless 430 Institute of Telematics 431 Universitaet Karlsruhe (TH) 432 P.O. Box 6980 433 76128 Karlsruhe 434 Germany 436 Email: bless@tm.uka.de 437 URI: http://www.tm.uka.de/~bless/ 439 Mark Doll 440 Institute of Telematics 441 Universitaet Karlsruhe (TH) 442 P.O. Box 6980 443 76128 Karlsruhe 444 Germany 446 Email: doll@tm.uka.de 447 URI: http://www.tm.uka.de/~doll/ 449 Gregory Daley 450 Centre for Telecommunications and Information Engineering 451 Department of Electrical and Computer Systems Engineering 452 Monash University 453 Clayton, Victoria 3800 454 Australia 456 Email: reg.daley@eng.monash.edu.au 458 Appendix A. Acknowledgments 460 Credits go to Gregory Daley for a valuable discussion on interactions 461 between MLD and router discovery plus address auto-configuration. 462 Thanks also to Jari Arkko, who thoroughly reviewed version 00 of this 463 draft. Last, but not least, the authors appreciate the contributions 464 of folks to the initial thread on the IPv6 mailing list [9]. 466 Intellectual Property Statement 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; nor does it represent that it has 473 made any independent effort to identify any such rights. Information 474 on the procedures with respect to rights in RFC documents can be 475 found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use of 480 such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository at 482 http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 this standard. Please address the information to the IETF at 488 ietf-ipr@ietf.org. 490 Disclaimer of Validity 492 This document and the information contained herein are provided on an 493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 495 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 496 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 497 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Copyright Statement 502 Copyright (C) The Internet Society (2005). This document is subject 503 to the rights, licenses and restrictions contained in BCP 78, and 504 except as set forth therein, the authors retain all their rights. 506 Acknowledgment 508 Funding for the RFC Editor function is currently provided by the 509 Internet Society.