idnits 2.17.1 draft-fenner-iana-exp-2780-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 544. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 337: '...xperiments; they MUST NOT be shipped a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 286 has weird spacing: '... act chg ...' == Line 290 has weird spacing: '...FE xx x ...' == Line 417 has weird spacing: '... Draft draft...' == Line 422 has weird spacing: '...t-Draft draft...' == Line 426 has weird spacing: '... Draft draft...' -- 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 (June 14, 2006) is 6525 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipngwg-icmp-v3' ** Obsolete normative reference: RFC 1349 (ref. 'RFC0791') (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3260 (ref. 'RFC2474') -- Unexpected draft version: The latest known version of draft-bradner-iana-allocation is -04, but you're referring to -05. ** Downref: Normative reference to an Informational draft: draft-ietf-ipngwg-iana-tla (ref. 'RFC2928') ** Downref: Normative reference to an Informational draft: draft-iana-special-ipv4 (ref. 'RFC3330') ** Downref: Normative reference to an Informational draft: draft-huston-ipv6-documentation-prefix (ref. 'RFC3849') == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-10 Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Fenner 3 Internet-Draft AT&T Labs - Research 4 Expires: December 16, 2006 June 14, 2006 6 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers 7 draft-fenner-iana-exp-2780-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 16, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 When experimenting with or extending protocols, it is often necessary 41 to use some sort of protocol number or constant in order to actually 42 test or experiment with the new function, even when testing in a 43 closed environment. This document reserves some ranges of numbers 44 for experimentation purposes in specific protocols where the need to 45 support experimentation has been identified, and describes the 46 numbers that have already been reserved by other documents. 48 1. Introduction 50 [RFC3692] recommends assigning option numbers for experiments and 51 testing. This document requests [[anchor2: documents --(when 52 assigned)]] such assignments for the number spaces whose IANA 53 considerations are documented in [RFC2780]. This document generally 54 follows the form of [RFC2780]. 56 When using these values, carefully consider the advice in Sections 1 57 and 1.1 of [RFC3692]. It is not appropriate to simply select one of 58 these values and hard code it into a system. 60 Note: while [RFC3692] says that it may not be necessary to allocate 61 values for UDP and TCP ports, sections 6 and 7.1 explicitly reserve 62 ports for this purpose to avoid any possible conflict. 64 2. Fields in the IPv4 header 66 The IPv4 header [RFC0791] contains the following fields that carry 67 values assigned by the IANA: Version, Type of Service, Protocol, 68 Source Address, Destination Address, and Option Type. 70 2.1. IP Version field in the IPv4 header 72 The Version field in IPv4 packets is always 4. 74 2.2. IPv4 Type of Service field 76 [RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to 77 either '0' or '1') as Experimental / Local Use, so no additional code 78 points should be needed. The ECN field [RFC3168] has no free code 79 points to assign. 81 2.3. IPv4 Protocol field 83 [RFC3692] allocates two experimental code points (253 and 254) for 84 the IPv4 Protocol field. 86 2.4. IPv4 Source and Destination addresses 88 2.4.1. IPv4 Unicast 90 No experimental IPv4 addresses are defined. For certain experiments, 91 the address ranges set aside for Private Internets in [RFC1918] may 92 be useful. It is not appropriate to use other special-purpose IPv4 93 addresses [RFC3330] for experimentation. 95 At the time of this writing, some Internet Registries have policies 96 allowing experimental assignments from number spaces that they 97 control. Depending on the experiment, the registry, and their 98 policy, this may be an appropriate path to pursue. 100 2.4.2. IPv4 Multicast 102 The globally routable group 224.0.1.20 is set aside for 103 experimentation. For certain experiments, the administratively 104 scoped multicast groups defined in [RFC2365] may be useful. This 105 document assigns a single link-local scoped group, 224.0.0.TBD, and a 106 single scope-relative group, TBD. 108 2.5. IPv4 Option Type field 110 This document assigns a single option number, with all defined values 111 of the "copy" and "class" fields, resulting in four distinct option 112 type codes. See Section 8 for the assigned values. 114 3. Fields in the IPv6 header 116 The IPv6 header [RFC2460] contains the following fields that carry 117 values assigned from IANA-managed name spaces: Version, Traffic 118 Class, Next Header, Source and Destination Address. In addition, the 119 IPv6 Hop-by-Hop Options and Destination Options extension headers 120 include an Option Type field with values assigned from an IANA- 121 managed name space. The IPv6 Routing Header contains a Type field 122 for which there is not currently an explicit IANA assignment policy. 124 3.1. IP Version field in the IPv6 header 126 The Version field in IPv6 packets is always 6. 128 3.2. IPv6 Traffic Class field 130 [RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to 131 either '0' or '1') as Experimental / Local Use, so no additional code 132 points should be needed. The ECN field [RFC3168] has no free code 133 points to assign. 135 3.3. IPv6 Next Header field 137 [RFC3692] allocates two experimental code points (253 and 254) for 138 the IPv6 Next Header field. 140 3.4. IPv6 Source and Destination Addresses 142 3.4.1. IPv6 Unicast Addresses 144 [RFC2928] defines a set of IPv6 addresses for testing and 145 experimental usage: 147 The block of Sub-TLA IDs assigned to the IANA (i.e., 2001: 148 0000::/29 - 2001:01F8::/29) is for assignment for testing and 149 experimental usage to support activities such as the 6bone, and 150 for new approaches like exchanges. 152 However, at this writing, there are no RFC3692-style experimental 153 IPv6 addresses assigned. [I-D.huston-ipv6-iana-specials] creates an 154 IANA registry which may in the future contain such assignments. For 155 certain experiments, Unique Local Addresses [RFC4193] may be useful. 156 It is not appropriate to use addresses in the documentation prefix 157 [RFC3849] for experimentation. 159 At the time of this writing, some Internet Registries have policies 160 allowing experimental assignments from number spaces that they 161 control. Depending on the experiment, the registry, and their 162 policy, this may be an appropriate path to pursue. 164 3.4.2. IPv6 Multicast Addresses 166 The group FF0X::114 is set aside for experimentation at all scope 167 levels. Smaller scopes may be particularly useful for 168 experimentation, since they are defined not to leak out of a given 169 defined boundary which can be set to be the boundary of the 170 experiment. For certain experiments, other multicast addresses with 171 the T (non-permanently-assigned or "transient" address) bit [RFC4291] 172 set may be useful. 174 3.5. IPv6 Hop-by-Hop and Destination Option Fields 176 This document assigns a single option type, with all possible values 177 of the "act" and "chg" fields, resulting in eight distinct option 178 type codes. See Section 8 for the assigned values. 180 3.6. IPv6 Routing Header Routing Type 182 This document assigns two values for the Routing Type field in the 183 IPv6 Routing Header, TBDY and TBDZ. 185 4. Fields in the IPv4 ICMP header 186 This document assigns two ICMPv4 type numbers, TBD3 and TBD4. ICMPv4 187 code values are allocated per-type, so it's not feasible to assign 188 experimental values in this document. 190 5. Fields in the IPv6 ICMP header 192 [I-D.ietf-ipngwg-icmp-v3] includes experimental ICMPv6 type values 193 for Informational (200, 201) and Error (100, 101) message types. 194 ICMPv6 code values are allocated per-type, so it's not feasible to 195 assign experimental values in this document. 197 5.1. IPv6 Neighbor Discovery Fields 199 The IPv6 Neighbor Discovery header [RFC2461] contains the following 200 fields that carry values assigned from IANA-managed name spaces: 201 Type, Code and Option Type. 203 5.1.1. IPv6 Neighbor Discovery Type 205 The Neighbor Discovery Type field is the same as the ICMPv6 Type 206 field. See Section 5 for those code points. 208 5.1.2. IPv6 Neighbor Discovery Code 210 The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no 211 experimental code points are necessary. 213 5.1.3. IPv6 Neighbor Discovery Option Type 215 This document assigns two IPv6 Neighbor Discovery Option Types, TBD1 216 and TBD2. 218 6. Fields in the UDP header 220 Two system ports, TBD5 and TBD6, have been reserved for 221 experimentation for UDP and TCP. 223 7. Fields in the TCP header 225 7.1. TCP Source and Destination Port fields 227 Two system ports, TBD5 and TBD6, have been reserved for 228 experimentation for UDP and TCP. 230 7.2. Reserved Bits in TCP Header 232 There are not enough reserved bits to allocate any for 233 experimentation. 235 7.3. TCP Option Kind field 237 Two TCP options, TBD7 and TBD8, have been reserved for 238 experimentation with TCP Options. 240 8. IANA Considerations 242 The new assignments are summarized below. 244 IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local 245 Network Control Block section) (Section 2.4.2) 247 Group Address Name 248 ------------- ---------------------------- 249 224.0.0.TBD RFC3692-style Experiment (*) 251 IPv4 Multicast Addresses (multicast-addresses relative addresses 252 section) (Section 2.4.2) 254 Relative Description 255 -------- ---------------------------- 256 TBD RFC3692-style Experiment (*) 258 IPv4 Option Numbers (ipv4-parameters initial section) (Section 2.5) 260 Copy Class Number Value 261 ---- ----- ------ ------- 262 0 0 ? ??_30_ 263 0 2 ? ??_94_ 264 1 0 ? ??_158_ 265 1 2 ? ??_222_ 267 [all '?' are the same, suggest ? = 11110; '??' calculated from other 268 values] 269 IPv6 Option Types (ipv6-parameters section 5.b.) (Section 3.5) 271 HEX act chg rest 272 ------------ --- --- ----- 273 0x??_[0x1e]_ 00 0 ????? 274 0x??_[0x3e]_ 00 1 ????? 275 0x??_[0x5e]_ 01 0 ????? 276 0x??_[0x7e]_ 01 1 ????? 277 0x??_[0x9e]_ 10 0 ????? 278 0x??_[0xbe]_ 10 1 ????? 279 0x??_[0xde]_ 11 0 ????? 280 0x??_[0xfe]_ 11 1 ????? 282 [suggest ????? = 11110] 284 Could be represented in registry as: 285 b BINARY 286 HEX act chg rest 287 --- --- --- ----- 288 ... 289 1E,3E,5E,7E, [x = don't care] 290 9E,BE,DE,FE xx x ????? RFC3692-style Experiment (*) [ref-to-this-doc] 292 IPv6 Neighbor Discovery Option Formats (icmpv6-parameters) 293 (Section 5.1.3) 295 Type Description 296 ---- ------------------------------ 297 TBD1 RFC3692-style Experiment 1 (*) 298 TBD2 RFC3692-style Experiment 2 (*) 300 IPv6 Routing Header Routing Types (ipv6-parameters section 5.c.) 301 (Section 3.6) 303 +------+--------------------------------+ 304 | Type | Description | 305 +------+--------------------------------+ 306 | TBDY | RFC3692-style Experiment 1 (*) | 307 | TBDZ | RFC3692-style Experiment 2 (*) | 308 +------+--------------------------------+ 310 ICMPv4 Type Numbers (icmp-parameters) (Section 4) 312 Type Name 313 ---- ------------------------------ 314 TBD3 RFC3692-style Experiment 1 (*) 315 TBD4 RFC3692-style Experiment 2 (*) 317 System Port Numbers (port-numbers) (Sections 6 and 7.1) 319 Keyword Decimal Description 320 ------- -------- ------------------------------ 321 exp1 TBD5/udp RFC3692-style Experiment 1 (*) 322 exp1 TBD5/tcp RFC3692-style Experiment 1 (*) 323 exp2 TBD6/udp RFC3692-style Experiment 2 (*) 324 exp2 TBD6/tcp RFC3692-style Experiment 2 (*) 326 TCP Option Numbers (tcp-parameters) ( Section 7.3) 328 Kind Length Meaning 329 ---- ------ ------------------------------ 330 TBD7 N RFC3692-style Experiment 1 (*) 331 TBD8 N RFC3692-style Experiment 2 (*) 333 Each of these registrations should be accompanied by the following 334 footnote: 336 * It is only appropriate to use these values in explicitly- 337 configured experiments; they MUST NOT be shipped as defaults in 338 implementations. See RFC 3692 for details. 340 9. Security Considerations 342 Security analyzers such as firewalls and network intrusion detection 343 monitors often rely on unambiguous interpretations of the fields 344 described in this memo. As new values for the fields are assigned, 345 existing security analyzers that do not understand the new values may 346 fail, resulting in either loss of connectivity if the analyzer 347 declines to forward the unrecognized traffic, or loss of security if 348 it does forward the traffic and the new values are used as part of an 349 attack. Assigning known values for experiments can allow such 350 analyzers to take a known action for explicitly experimental traffic. 352 Because the experimental IPv4 options defined in Section 2.5 are not 353 included in the IPsec AH [RFC4302] calculations, it is not possible 354 for one to authenticate their use. Experimenters ought to keep this 355 in mind when designing their experiments. Users of the experimental 356 IPv6 options defined in Section 3.5 can choose whether or not the 357 option is included in the AH calculations by choosing the value of 358 the "chg" field. 360 When experimental code points are deployed within an administratively 361 self-contained network domain, the network administrators should 362 ensure that each code point is used consistently to avoid 363 interference between experiments. When experimental code points are 364 used in traffic that crosses multiple administrative domains, the 365 experimenters should assume that there is a risk of the same code 366 points being used simultaneously by other experiments and thus that 367 there is a possibility that the experiments will interfere. 368 Particular attention should be given to security threats that such 369 interference might create. 371 10. References 373 10.1. Normative References 375 [I-D.ietf-ipngwg-icmp-v3] 376 Conta, A., "Internet Control Message Protocol (ICMPv6) for 377 the Internet Protocol Version 6 (IPv6) Specification", 378 draft-ietf-ipngwg-icmp-v3-07 (work in progress), I-D 379 Status iesg, IETF Datatracker State RFC Ed Queue, Intended 380 Status Draft Standard, Responsible AD Margaret Wasserman, 381 RFC-Editor Queue State RFC-EDITOR, July 2005. 383 [RFC0791] Postel, J., "Internet Protocol", RFC 791, STD 5, Updated 384 by RFC1349, Current Status STANDARD, September 1981. 386 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, 387 G., and E. Lear, "Address Allocation for Private 388 Internets", RFC 1918, BCP 5, Current Status BEST CURRENT 389 PRACTICE, February 1996. 391 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", 392 RFC 2365, BCP 23, Current Status BEST CURRENT PRACTICE, 393 July 1998. 395 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 396 (IPv6) Specification", RFC 2460, Current Status DRAFT 397 STANDARD, December 1998. 399 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 400 Discovery for IP Version 6 (IPv6)", RFC 2461, Updated 401 by RFC4311, Current Status DRAFT STANDARD, December 1998. 403 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 404 "Definition of the Differentiated Services Field (DS 405 Field) in the IPv4 and IPv6 Headers", RFC 2474, Updated 406 by RFC3168, Updated by RFC3260, Current Status PROPOSED 407 STANDARD, December 1998. 409 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 410 Values In the Internet Protocol and Related Headers", 411 RFC 2780, BCP 37, Was Internet-Draft 412 draft-bradner-iana-allocation-05, Current Status BEST 413 CURRENT PRACTICE, March 2000. 415 [RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial 416 IPv6 Sub-TLA ID Assignments", RFC 2928, Was Internet- 417 Draft draft-ietf-ipngwg-iana-tla-03, Current 418 Status INFORMATIONAL, September 2000. 420 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 421 of Explicit Congestion Notification (ECN) to IP", 422 RFC 3168, Was Internet-Draft draft-ietf-tsvwg-ecn-04, 423 Current Status PROPOSED STANDARD, September 2001. 425 [RFC3330] "Special-Use IPv4 Addresses", RFC 3330, Was Internet- 426 Draft draft-iana-special-ipv4-05, Current 427 Status INFORMATIONAL, September 2002. 429 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 430 Considered Useful", RFC 3692, BCP 82, Was Internet-Draft 431 draft-narten-iana-experimental-allocations-05, Current 432 Status BEST CURRENT PRACTICE, January 2004. 434 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 435 Reserved for Documentation", RFC 3849, Was Internet-Draft 436 draft-huston-ipv6-documentation-prefix-03, Current 437 Status INFORMATIONAL, July 2004. 439 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 440 Addresses", RFC 4193, Was Internet-Draft 441 draft-ietf-ipv6-unique-local-addr-09, Current 442 Status PROPOSED STANDARD, October 2005. 444 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 4291, Was Internet-Draft 446 draft-ietf-ipv6-addr-arch-v4-04, Current Status DRAFT 447 STANDARD, February 2006. 449 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Was 450 Internet-Draft draft-ietf-ipsec-rfc2402bis-10, Current 451 Status PROPOSED STANDARD, December 2005. 453 10.2. Informative References 455 [I-D.huston-ipv6-iana-specials] 456 Huston, G., "Administration of the IANA Special Purpose 457 Address Block", draft-huston-ipv6-iana-specials-01 (work 458 in progress), I-D Status iesg, IETF Datatracker State AD 459 Evaluation, Intended Status Informational, Responsible 460 AD David Kessens, December 2005. 462 Appendix A. Change History 464 (To be removed before publication) 466 A.1. Changes from -01 468 o Added refs to 3849 and 3330 for things not to use in unicast 469 addresses. 471 o Updated ULA ref to be 4193. 473 o Changed multiple "TBD1+TBD2" to TBD1 through TBD8 475 o Added IPv6 multicast addresses with T bit. 477 o Added footnote to be included in all IANA registrations. 479 o Added link-local and scope-relative v4 multicast addresses 481 A.2. Changes from -02 483 o Added IPsec AH discussion in security considerations 485 o Added mention of the IPv6 special use unicast address block. 487 o Added IPv6 Routing Header TBDY and TBDZ 489 o Point out that even though RFC3692 gives UDP/TCP ports as an 490 example where reserving values isn't necessary, we do anyway since 491 it allows avoiding conflicts. 493 A.3. Changes from -03 495 o Moved mention of reserving UDP/TCP ports to introduction, to avoid 496 inconsistency of mentioning it in Section 6 and not Section 7.1. 498 A.4. Changes from -04 500 o Mention that registries are possible places to get unicast 501 addresses. 503 o Fixed title of Informative References section. 505 o Fixed some speling errurs. 507 o Changed titles of sections 2.1 and 3.1. 509 o Moved Section 5.1 to a more sensible place under Section 5. 511 Author's Address 513 Bill Fenner 514 AT&T Labs - Research 515 75 Willow Rd 516 Menlo Park, CA 94025 517 USA 519 Phone: +1 650 330-7893 520 Email: fenner@research.att.com 522 Intellectual Property Statement 524 The IETF takes no position regarding the validity or scope of any 525 Intellectual Property Rights or other rights that might be claimed to 526 pertain to the implementation or use of the technology described in 527 this document or the extent to which any license under such rights 528 might or might not be available; nor does it represent that it has 529 made any independent effort to identify any such rights. Information 530 on the procedures with respect to rights in RFC documents can be 531 found in BCP 78 and BCP 79. 533 Copies of IPR disclosures made to the IETF Secretariat and any 534 assurances of licenses to be made available, or the result of an 535 attempt made to obtain a general license or permission for the use of 536 such proprietary rights by implementers or users of this 537 specification can be obtained from the IETF on-line IPR repository at 538 http://www.ietf.org/ipr. 540 The IETF invites any interested party to bring to its attention any 541 copyrights, patents or patent applications, or other proprietary 542 rights that may cover technology that may be required to implement 543 this standard. Please address the information to the IETF at 544 ietf-ipr@ietf.org. 546 Disclaimer of Validity 548 This document and the information contained herein are provided on an 549 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 550 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 551 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 552 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 553 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 554 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 556 Copyright Statement 558 Copyright (C) The Internet Society (2006). This document is subject 559 to the rights, licenses and restrictions contained in BCP 78, and 560 except as set forth therein, the authors retain all their rights. 562 Acknowledgment 564 Funding for the RFC Editor function is currently provided by the 565 Internet Society.