idnits 2.17.1 draft-daniel-ipv6-ra-mo-flags-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 532. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (October 23, 2004) is 7096 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) == Missing Reference: 'DHCPv6' is mentioned on line 81, but not defined == Missing Reference: 'ADDRCONF' is mentioned on line 93, but not defined == Missing Reference: 'DHCPv6-lite' is mentioned on line 89, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-00 == Outdated reference: A later version (-08) exists of draft-ietf-ipv6-rfc2462bis-06 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Park, Ed. 3 Internet-Draft Samsung Electronics 4 Expires: April 23, 2005 S. Madanapalli 5 Samsung ISO 6 T. Jinmei 7 Toshiba 8 October 23, 2004 10 Considerations on M and O Flags of IPv6 Router Advertisement 11 draft-daniel-ipv6-ra-mo-flags-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 23, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document clarifies the processing and behaviour of a host for 47 the M and O flags of IPv6 Router Advertisement and proposes a 48 solution for invoking the DHCPv6 service based on administrator 49 policy in conjunction with new host variables for the M and O flags. 51 1. Introduction 53 To configure a host with network information such as an IP address, 54 DNS server addresses and other configuration information, several 55 mechanisms are proposed in the IETF. In particular, IPv6 stateless 56 address autoconfiguration [RFC2462] and Dynamic Host Configuration 57 Protocol [RFC3315][RFC3736] will be widely used for configuring the 58 network information. 60 This document proposes two conceptual variables, called DHCPv6 Policy 61 variables corresponding to the M and O flags of Router Advertisement. 62 The values of these policy variables in conjuction with the values of 63 the flags of Router Advertisement decide the host behaviour to invoke 64 DHCPv6 services. These policy variables are controlled by the 65 administrator under a certain level of requirement. 67 2. Background 69 This section explains why this document appears in the IETF. 71 Currently, IPv6 WG is trying to make both [RFC2461] and [RFC2462] 72 mature for the Draft Standard but the detailed consideration of the M 73 and O flags of IPv6 Router Advertisement remains beyond scope of the 74 basic documents as described in [I-D.ietf-ipv6-rfc2462bis]. 76 [I-D.ietf-ipv6-2461bis] says: 78 o M : 80 1-bit "Managed address configuration" flag. When set, it 81 indicates that Dynamic Host Configuration Protocol [DHCPv6] is 82 available for address configuration in addition to any addresses 83 autoconfigured using stateless address autoconfiguration. The use 84 of this flag is further described in [ADDRCONF]. 86 o O : 88 1-bit "Other stateful configuration" flag. When set, it indicates 89 that [DHCPv6-lite] is available for autoconfiguration of other 90 (non-address) information. Examples of such information are DNS- 91 related information or information on other servers within the 92 network. The use of this flag for add is further described in 93 [ADDRCONF]. 95 [Note: "for add" in the last sentence is probably a misspelling.] 97 [I-D.ietf-ipv6-rfc2462bis] says: 99 o The details of how a host may use the M flag, including any use of 100 the "on" and "off" transitions for this flag, to control the use 101 of the stateful protocol for address assignment will be described 102 in a separate document. Similarly, the details of how a host may 103 use the O flag, including any use of the "on" and "off" 104 transitions for this flag, to control the use of the stateful 105 protocol for getting other configuration information will be 106 described in a separate document. 108 In particular, both "ManagedFlag" and "OtherConfigFlag" which were 109 implementation-internal variables were removed during the 110 [I-D.ietf-ipv6-rfc2462bis] work based on the WG consensus with 111 ambiguous operational experiences, and thus new variables (or similar 112 approaches) are required to treat the M and O flags of IPv6 Router 113 Advertisement on the host. 115 3. Terminology 117 o Host Configuration Behaviour : 119 A host can use DHCPv6 for address autoconfiguration as well as 120 other configuration information via 121 Solicit/Advertise/Request/Reply message exchanges or Solicit/Reply 122 message exchanges (if rapid commit is enabled) as described in 123 [RFC3315]. In this document, this term is used for host 124 configuration including address and other configuration 125 information in conjunction with the M flag. 127 o Information Configuration Behaviour : 129 A host can use DHCPv6 to obtain configuration information 130 parameters excluding addresses. For this operation, 131 Information-request and Reply messages are used, also as described 132 in [RFC3315]. In this document, this term is used for other 133 configuration information excluding addresses in conjunction with 134 the O flag. 136 [RFC3736] gives guidelines for implementing the parts of [RFC3315] 137 required for the configuration information, for clients, servers 138 and relay agents, although [RFC3736] has no additional impact on 139 relay agents. Also, [RFC3736] does not describe procedures or a 140 distinct protocol. It is intended to describe that part of the 141 protocol that a server or a client must implement if all it 142 intends to support is the configuration information. 144 4. Requirements 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 5. IPv6 Host Variables 152 This document newly introduces two host variables to indicate whether 153 or not configuration information (including addresses) can be 154 configured using DHCPv6. The implicit concept of these variables 155 defined in this document is the same as that of "ManagedFlag" and 156 "OtherConfigFlag", which were described in [RFC2462] and then removed 157 from [I-D.ietf-ipv6-rfc2462bis]. We deliberately use different 158 variable names in this document to avoid confusion with the removed 159 names. 161 A host maintains the following variables on a per-interface basis: 163 o M-Flag : 165 Copied from the M flag field of the most recently received Router 166 Advertisement message. This variable indicates whether or not 167 address can be configured using Host Configuration Behaviour. It 168 starts out in a FALSE state. On receipt of a valid Router 169 Advertisement, a host copies the value of the advertisement's M 170 flag into M-Flag. 172 Default: FALSE 174 o O-Flag : 176 Copied from the O flag field of the most recently received Router 177 Advertisement message. This variable indicates whether or not 178 configuration information (excluding addresses) can be obtained 179 using Information Configuration Behaviour. It starts out in a 180 FALSE state. On receipt of a valid Router Advertisement, a host 181 copies the value of the advertisement's O flag into O-Flag. 183 Default: FALSE 185 6. DHCPv6 Policy Variables 187 This document introduces two administrator policy variables regarding 188 DHCPv6, M-Policy and O-Policy, corresponding to Host Configuration 189 Behaviour and Information Configuration Behaviour. These policy 190 variables will be used by the administrator for controlling the 191 invocation of DHCPv6. 193 6.1 Dependency Between the Configuraton Behaviours 195 Prior to introducing specific policies, we note an important 196 dependency between the two Configuraton Behaviours. If we invoke 197 Host Configuration Behaviour for address autoconfiguration (along 198 with other configuration information), we basically should not invoke 199 Information Configuration Behaviour since the former can provide 200 other configuration information as well. 202 For simplicity, however, we will describe the policies and the 203 corresponding variables for the M and O flags separately. Host's 204 behaviour, with taking into account of the dependency, will be 205 described in Section 7. 207 6.2 M-Policy 209 This policy variable takes three values as described below. 211 o Policy 1 : 213 The host should invoke Host Configuration Behaviour for address 214 autoconfiguration (along with other configuration information) 215 regardless of the content of received Router Advertisement 216 messages or the existence of Router Advertisement messages. 218 o Policy 2 : 220 The host should invoke Host Configuration Behaviour for address 221 autoconfiguration (along with other configuration information) if 222 and only if it sees a Router Advertisement changing the M-Flag 223 from FALSE to TRUE. 225 o Policy 3 : 227 The host should not invoke Host Configuration Behaviour for 228 address autoconfiguration (along with other configuration 229 information) regardless of the content of received Router 230 Advertisement messages or the existence of Router Advertisement 231 messages. 233 6.3 O-Policy 235 This policy variable takes three values as described below. 237 o Policy 1 : 239 The host should invoke Information Configuration Behaviour for 240 getting other configuration information regardless of the content 241 of received Router Advertisement messages or the existence of 242 Router Advertisement messages. 244 o Policy 2 : 246 The host should invoke Information Configuration Behaviour for 247 getting other configuration information if and only if it sees a 248 Router Advertisement changing the O-Flag from FALSE to TRUE. 250 o Policy 3 : 252 The host should not invoke Information Configuration Behaviour for 253 getting other configuration information regardless of the content 254 of received Router Advertisement messages or the existence of 255 Router Advertisement messages. 257 7. Host Behaviour 259 The M and O flags indicate whether Host Configuration/Information 260 Configuration Behaviours are available, but typically they themselves 261 should not be used as triggers to invoke DHCPv6 services. However, 262 these flags in conjunction with the policy configured may trigger 263 DHCPv6 services for automatic configuration of the IPv6 address and 264 the other information. 266 The followings are specific host's behaviour based on the policy 267 variables and the change of the host state variables. 269 If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour 270 for address and other configuration information, regardless of the 271 change of the state variables. The host SHOULD NOT invoke 272 Information Configuration Behaviour regardless of O-Policy. Note, 273 however, that if the available DHCPv6 servers only provide the 274 service for the Information Configuration Behaviour, the host will 275 even not be able to configure other configuration parameters than 276 addresses. Thus, it is generally inadvisable to set M-Policy to 1, 277 unless there is a particular reason to do so. 279 If M-Policy is 2, the host SHOULD first wait for initial Router 280 Advertisements. If those advertisements make M-Flag change from 281 FALSE to TRUE, the host SHOULD invoke Host Configuration Behaviour. 282 In this case, the host SHOULD NOT invoke Information Configuration 283 Behaviour regardless of O-Policy. Otherwise, if O-Policy is 1 or the 284 initial advertisements make O-Flag change from FALSE to TRUE with 285 O-Policy being 2, the host SHOULD invoke Information Configuration 286 Behaviour. Even after initial advertisements, the host SHOULD invoke 287 Host Configuration Behaviour whenever M-Flag changes from FALSE to 288 TRUE, unless it has already started the behaviour. If the host has 289 invoked Information Configuration Behaviour by the time it invokes 290 Host Configuration Behaviour, the host SHOULD NOT stop the running 291 Information Configuration Behaviour. 293 If M-Policy is 3, the host SHOULD NOT invoke Host Configuration 294 Behaviour, regardless of the change of the state variables. In this 295 case, if O-Policy is 1, the host SHOULD immediately invoke 296 Information Configuration Behaviour. Otherwise, when O-Flag changes 297 from FALSE to TRUE with O-Policy being 2, the host SHOULD invoke 298 Information Configuration Behaviour, unless it has already started 299 the behaviour. 301 8. Other Issues on State Transition of M-Flag and O-Flag 303 As long as a host resides in the same single network, the behaviour 304 of the host SHOULD NOT be changed with the change of M-Flag or O-Flag 305 from TRUE to FALSE. The host is not expected to store M-Flag and 306 O-Flag state in non-volatile memory. When a host is rebooting (the 307 state of variables starts with FALSE), the host SHOULD update these 308 variables depending on the information received in Router 309 Advertisement messages. Also, the host SHOULD update these variables 310 depending on the information received in Router Advertisement 311 messages, when it moves to a different network and receives a new 312 Router Advertisement including different prefix information. 314 9. Router Advertisement Unavailability 316 It is possible that the host does not see any Router Advertisements. 317 Originally, [RFC2462] requested that the host in this case must 318 invoke the stateful configuration protocol (i.e., [RFC3315] in 319 today's interpretation). In addition, 320 [I-D.ietf-ipv6-node-requirements] says that in the absence of a 321 router, the IPv6 nodes that use DHCP for address assignment MUST 322 initiate DHCP to obtain IPv6 addresses and other configuration 323 information. 325 Based on these prior documents, this document introduces the 326 following rule: if no Router Advertisement appears, a host SHOULD 327 initiate Host Configuration Behaviour using [RFC3315] to get both 328 address and configuration information as if the node receives a 329 Router Advertisement with the M flag being ON and the O flag being 330 OFF. This rule is almost as the same as what the prior documents 331 specified, except that the host can still choose not to initiate Host 332 Configuration Behaviour if its M-policy is 3. 334 10. Conclusion 336 To clarify the meaning of the M and O flags of IPv6 Router 337 Advertisement, this document has proposed DHCPv6 Policy variables on 338 the host in conjunction with host state variables corresponding to 339 the M and O flags of Router Advertisement for invoking the DHCPv6 340 Services. The Policy variables are controlled by the administrator 341 under a certain level of requirement. 343 Generally, both Host Configuration/Information Configuration 344 Behaviours and IPv6 stateless address autoconfiguration may be used 345 simultaneously. On the other hand, if we invoke Host Configuration 346 Behaviour for address autoconfiguration, we should basically not 347 invoke Information Configuration Behaviour since the former service 348 can provide other configuration information also. 350 [RFC3736] is just a subset of the full DHCPv6 service. Thus, a host 351 implementing [RFC3315] can do both or either Host Configuration 352 Behaviour for configuring the IPv6 address and Information 353 Configuration Behaviour for the other information. A host 354 implementing only [RFC3736] can only do Information Configuration 355 Behaviour. 357 11. An Open Issue: Default Policy Values 359 Once we agree on the basic concept described in this document, we 360 will then have to decide the appropriate default values of the policy 361 variables. 363 The followings are some initial considerations on the default values 364 at the moment. If the node implements Host Configuration Behaviour 365 using [RFC3315], the default value of M-Policy should be 2. If the 366 node does not implement Host Configuration Behaviour using [RFC3315], 367 the default (and only) value of M-policy should be 3. Assuming 368 Information Configuration Behaviour only using [RFC3736] will be 369 implemented much wider than the full set of [RFC3315] in terms of 370 other configuration information, the default value of O-Policy should 371 be either 1 or 2. Value 1 is presumably better since this service 372 can be crucial for the node (i.e., there may be no alternative to get 373 the other configuration information.) 375 12. Security Considerations 377 The concepts in this document do not significantly alter the security 378 considerations for DHCPv6 and Neighbor Discovery Protocol. However, 379 the use of the proposed policies with variables could expedite denial 380 of service attacks by allowing a mischievous host to trigger invalid 381 DHCP exchanges with the M or O flag being ON in a malicious Router 382 Advertisement and with illegitimate DHCPv6 servers. Authenticated 383 DHCPv6 and/or [I-D.ietf-send-ndopt] (SEcure Neighbor Discovery, SEND) 384 can be used to protect the attack. 386 Even though the threat is only effective from an on-link attacker, it 387 can be significant without a strong security mechanism like SEND, 388 since the attack takes place in the process of autoconfiguration, and 389 it may be difficult for the user to detect the attack. Thus, it is 390 generally advisable to log the change of M-Flag or O-Flag from FALSE 391 to TRUE. In addition, it might be useful to log an event that 392 information provided through DHCPv6 is different form the information 393 of the same type that the host previously received through DHCPv6. 395 13. IANA Considerations 397 This document has no consideration for IANA. 399 14. Acknowledgements 401 The approach of this document was from the RFC2461/RFC2462, so the 402 authors would appreciate the authors of these RFCs and the editors of 403 RFC2461bis/RFC2462bis. Also, many thanks go to IPv6 Working Group 404 members for their valuable discussion on this thread in the mailing 405 list. Especially to: Greg Daley, Pekka Savola, Ralph Droms, and Stig 406 Venaas. Thanks to Bernie Volz of Cisco for his lots of valuable work 407 on this document. Special thanks to Radakrishnan and OLN Rao of 408 Samsung India Software Operations for their inputs from 409 implementation perspective. 411 Alain Durand of Sun Microsystems indicated an attack changing the M 412 and O flags with a rogue DHCPv6 server and kindly introduced a log 413 message as an effective method to detect a suspicious operation. 415 15. Appendix A: Handling of M and O flags from multiple routers 417 This document does not take a hard stance on what happens when a host 418 has multiple routers and inconsistent information (different M and O 419 flags configuration) is learned from different routers. The basic 420 documents [RFC2461]/[RFC2462] already described "Configuration 421 Consistency" and a host will simply handle inconsistent M and O flags 422 of Router Advertisement in the same manner. 424 If the host frequently receives inconsistent M and O flags of Router 425 Advertisement (e.g., in a mobile environment for supporting fast 426 movement detection), it may need complex consideration on an 427 erroneous case. However, this case is not closely related to this 428 document; rather, it is a general issue on the inconsistent Router 429 Advertisement parameters from multiple routers. In fact, other 430 configuration parameters such as the MTU size and the hop limit are 431 also possible to be inconsistent in different Router Advertisements. 433 In the end, it is administrator's responsibility to ensure the 434 consistency among Router Advertisement parameters from multiple 435 routers in the same single link as described in Section 5.6 of 436 [RFC2462]. The authors thus remain "Handling of M and O flags from 437 multiple routers" out of scope of this document. 439 16. References 441 16.1 Normative References 443 [I-D.ietf-ipv6-2461bis] 444 "Neighbor Discovery for IP version 6 (IPv6)", 445 draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. 447 [I-D.ietf-ipv6-rfc2462bis] 448 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 449 draft-ietf-ipv6-rfc2462bis-06 (work in progress), 450 September 2004. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 456 Discovery for IP Version 6 (IPv6)", RFC 2461, December 457 1998. 459 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 460 Autoconfiguration", RFC 2462, December 1998. 462 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 463 M. Carney, "Dynamic Host Configuration Protocol for IPv6 464 (DHCPv6)", RFC 3315, July 2003. 466 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 467 (DHCP) Service for IPv6", RFC 3736, April 2004. 469 16.2 Informative References 471 [I-D.ietf-ipv6-node-requirements] 472 Loughney, J., "IPv6 Node Requirements", 473 draft-ietf-ipv6-node-requirements-11 (work in progress), 474 August 2004. 476 [I-D.ietf-send-ndopt] 477 Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 478 Nikander, "SEcure Neighbor Discovery (SEND)", 479 draft-ietf-send-ndopt-06 (work in progress), July 2004. 481 Authors' Addresses 483 Soohong Daniel Park, Ed. 484 Samsung Electronics 485 416 Maetan-3dong, Yeongtong-gu 486 Suwon-si, Gyeonggi-do 442-742 487 KOREA 489 Phone: +82 31 200 4508 490 EMail: soohong.park@samsung.com 492 Syam Madanapalli 493 Samsung India Software Operation 494 J.P. Techno Park, 3/1 495 Millers Road, Bangalore 560-052 496 INDIA 498 Phone: +91 80 51197777 499 EMail: syam@samsung.com 501 Tatuya Jinmei 502 Toshiba Corporation 503 1 Komukai Toshiba-cho, Saiwai-ku 504 Kawasaki-shi, Kanagawa 212-8582 505 JAPAN 507 Phone: +81 44 549 2230 508 EMail: jinmei@isl.rdc.toshiba.co.jp 510 Intellectual Property Statement 512 The IETF takes no position regarding the validity or scope of any 513 Intellectual Property Rights or other rights that might be claimed to 514 pertain to the implementation or use of the technology described in 515 this document or the extent to which any license under such rights 516 might or might not be available; nor does it represent that it has 517 made any independent effort to identify any such rights. Information 518 on the procedures with respect to rights in RFC documents can be 519 found in BCP 78 and BCP 79. 521 Copies of IPR disclosures made to the IETF Secretariat and any 522 assurances of licenses to be made available, or the result of an 523 attempt made to obtain a general license or permission for the use of 524 such proprietary rights by implementers or users of this 525 specification can be obtained from the IETF on-line IPR repository at 526 http://www.ietf.org/ipr. 528 The IETF invites any interested party to bring to its attention any 529 copyrights, patents or patent applications, or other proprietary 530 rights that may cover technology that may be required to implement 531 this standard. Please address the information to the IETF at 532 ietf-ipr@ietf.org. 534 Disclaimer of Validity 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Copyright Statement 546 Copyright (C) The Internet Society (2004). This document is subject 547 to the rights, licenses and restrictions contained in BCP 78, and 548 except as set forth therein, the authors retain all their rights. 550 Acknowledgment 552 Funding for the RFC Editor function is currently provided by the 553 Internet Society.