idnits 2.17.1 draft-parent-v6tc-protocol-exploration-00.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 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 605. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 (December 16, 2004) is 7071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 555, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-01 == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-ndproxy-00 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Parent 3 Internet-Draft Hexago 4 Expires: June 16, 2005 P. Savola 5 CSC/FUNET 6 A. Durand 7 SUN Microsystems,inc. 8 December 16, 2004 10 v6tc Protocol Exploration 11 draft-parent-v6tc-protocol-exploration-00.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 June 16, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document aims to provide a rough sketch on different approaches 47 to meet the zeroconf/assisted tunneling requirements for a simple 48 IPv6-in-IPv4 tunnel set-up mechanism. 50 Table of Contents 52 1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1 Implicit Tunnel Setup . . . . . . . . . . . . . . . . . . 4 55 2.1.1 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1.2 Router Advertisement . . . . . . . . . . . . . . . . . 6 57 2.2 Negotiated Tunnel Setup . . . . . . . . . . . . . . . . . 8 58 2.2.1 Tunnel Setup Messages . . . . . . . . . . . . . . . . 9 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 63 5.2 Informative References . . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 65 Intellectual Property and Copyright Statements . . . . . . . . 15 67 1. Goals 69 Meet assisted tunneling and zero-conf tunneling requirement 70 documents. 72 o Simple mode 74 o Ipv6 endpoint 76 o v6v4 tunneling 78 o Nat traversal 80 o User authentication 82 o IPv6 prefix 84 TBD. 86 2. Approaches 88 A Reusing existing standardized protocols as far as possible: 89 DHCPv6, Router Advertisements: these will establish the tunnel 90 implicitly. 92 B Define a tunnel setup protocol to exchange the tunnel information. 94 DHCPv6 and RA are not defined to establish configured tunnels, but 95 instead to assign addresses/prefixes and other related information on 96 the link after one has been established. 98 Therefore, there are two possibly separate problems that need to be 99 addressed: 101 1. Setting up an IPv4 tunnel over which IPv6 packets can be sent; 102 this link may or may not have more than a link-local address. 104 2. Configuring information related to the tunnel, e.g., global 105 addresses, default routes, etc. 107 Additionally, one may want to configure other parameters (such as 108 recursive DNS server addresses, SIP server addresses, etc.) unrelated 109 to obtaining simple IPv6 connectivity, but that is considered a 110 non-problem for this work. 112 As the main issue in v6tc is finding a means to establish the link 113 (problem #1), we assume that the tunnel link must be established as 114 part of the v6tc solution. 116 Obviously, DHCPv6 and RA can be used for problem #2 when a separate 117 protocol (e.g., explicit tunnel setup as described in Section 2.2) 118 has been used for #1, but it is debatable whether this is useful. 119 This is not discussed at this point. 121 2.1 Implicit Tunnel Setup 123 Existing mechanisms such as DHCPv6 and RA can be used to assign an 124 address or use a prefix (problem #2), but are not suitable *as-is* to 125 establish a configured tunnel (problem #1). With a small change, 126 this shortcoming can be fixed. 128 With the implicit tunnel creation, the first DHCPv6 solicit/RS 129 message sent by the client is received by the server, and triggers 130 the creation of the tunnel link, on top of which a reply is sent 131 back. 133 The messaging uses link-local addresses automatically assigned for 134 tunnel links. DAD can be disabled as long as the generation of the 135 link-local address is unique enough (e.g., derives the address from 136 the IPv4 address, as is typical for v6-over-v4 implementations). 138 The DHCPv6 and RA approaches are described in more length below, in 139 Section 2.1.1 and Section 2.1.2. The following generic 140 issues/considerations apply to both DHCPv6 and RA approaches: 142 o Cannot negotiate tunnel encapsulation type (always over UDP) 144 o NAT detection is no longer necessary since UDP is always used. 145 There can be no keepalive negotiation (for the benefit of both 146 firewalls and NATs); it is assumed that keepalives are always sent 147 by the host except when disabled in the host. 149 o ISPs will likely not use authentication for their own users, but 150 instead rely on IP-address based filtering. 152 o Implementation is likely a process which listens at the UDP port 153 and directs packets relating to existing tunnels to those tunnel 154 interfaces, and demultiplexes he incoming initial packets by 155 creating new interfaces based on need, and when created, injects 156 the initial DHCPv6/RS messages on that interface, so they'll end 157 up in the local unmodified DHCPv6 server process or RA process. 159 2.1.1 DHCPv6 161 The steps are as follows: 163 1. Client configures IPv6/UDP/IPv4 interface towards tunnel server. 164 (The address has been discovered using the discovery mechanism, 165 e.g., DNS.) 167 2. Client sends DHCP solicit over tunnel using the rapid commit 168 option ([RFC3315] section 22.14). 170 3. Tunnel server listening on UDP port receives message and 171 configures tunnel interface link (based on the IPv4 source 172 address). 174 4. DHCPv6 solicit message is received by DHCPv6 server through the 175 tunnel link that was just created. 177 5. DHCPv6 advertise IPv6 address to client. 179 client server 180 1.Configure | | 181 tunnel o| | 182 | 2.DHCP solicit | 183 | (rapid commit) | 184 DHCP/IPv6/UDP/IPv4 |------------------------->| 185 | | 186 | |o 3.configure tunnel 187 | | 4.message to DHCPv6 188 | 5.DHCP advertise | server 189 |<------------------------ | 191 Figure 1: DHCPv6 in simple mode 193 If the client uses authentication, DHCP delayed authentication is 194 used [RFC3118]. This requires the client and server to share a known 195 secret. 197 This differs from the above in that Rapid Commit option cannot be 198 used at step 2, above, and Advertise option (at step 5) carries the 199 authentication and requires a couple of additional steps: 201 o Client sends Request with auth options. At this point, the server 202 is able to validate the authenticity of the user. If that fails, 203 the request is dropped and the tunnel may be removed. 205 o Server sends Reply + auth options. 207 client server 208 1.Configure | | 209 tunnel o| | 210 | 2.DHCP solicit | 211 DHCP/IPv6/UDP/IPv4 |------------------------->| 212 | | 213 | |o 3.configure tunnel 214 | | 4.message to DHCPv6 215 | 5.DHCP advertise | server 216 |<------------------------ | 217 | DHCP request | 218 |------------------------->|o client identity 219 | DHCP reply | verified here. 220 |<------------------------ | 222 Figure 2: DHCPv6 in authenticated mode 224 DHCP delayed authentication [RFC3118] is used to provide a user 225 authentication based on shared secrets. The secrets are not sent in 226 clear. 228 Prefix delegation may be done using IPv6 prefix options [RFC3633]. 229 In the non-authenticated case, prefix delegation can be accomplished 230 in one round-trip using the rapid commit option. 232 Notes/Issues 234 o Might be an issue about using DHCPv6 for address assignment. What 235 are the host requirements? 237 2.1.2 Router Advertisement 239 ICMPv6 Neighbor Discovery [RFC2461] Router Advertisements are very 240 similar to DHCPv6, with a few notable differences: 242 o Authentication where needed can be done using SEND 243 [I-D.ietf-send-ndopt]. 245 o Prefix delegation is not supported, but multiple nodes can use the 246 same prefix if using bridging or ND-proxy [I-D.ietf-ipv6-ndproxy]. 248 o Requires no DHCPv6 implementation (for address assignment, at 249 least) on hosts. 251 The steps are as follows: 253 1. Client configures IPv6/UDP/IPv4 interface towards tunnel server. 254 (The address has been discovered using the discovery mechanism, 255 e.g., DNS.) 257 2. Client sends Router Solicitation over tunnel. 259 3. Tunnel server listening on UDP port receives message and 260 configures tunnel interface link (based on the IPv4 source 261 address) 263 4. The RA/RS handling process receives the RS message from the new 264 link that was just set up. 266 5. Route Advertisement message is sent in response through the 267 tunnel link. 269 client server 270 1.Configure | | 271 tunnel o| | 272 | 2.ND/Router Solicitation | 273 RS/IPv6/UDP/IPv4 |------------------------->| 274 | | 275 | |o 3.configure tunnel 276 | | 4.message to RA 277 | 5. Router Advertisement | process 278 |<------------------------ | 280 Figure 3: RA in simple mode 282 If SEND is used for authentication, Router Solicitation additionally 283 includes the CGA, RSA Signature, Nonce, and Timestamp options. The 284 server has the user's public key in file, and checks the CGA address 285 against that. The fact that the client has been able to sign the ND 286 message with the private key is sufficient for the server to 287 ascertain user's identity. 289 In a similar fashion, the server uses CGA in its replies, allowing 290 the client to ensure no one is able to thwart the signalling. The 291 Certification Path Discovery and Certificates are not required as the 292 link is point-to-point. 294 The use of SEND incurs no additional roundtrips. 296 Notes: 298 o If the client needs to configure any other IPv6 parameters than a 299 global address, running DHCPv6(-lite) or the like may be 300 necessary. 302 2.2 Negotiated Tunnel Setup 304 An alternative approach is to define a new protocol to exchange the 305 tunnel parameters explicitly. The tunnel setup protocol is done over 306 UDP and NAT detection is done to determine if IPv6-over-IPv4 307 tunneling or IPv6 over UDP tunnel will be used. 309 The characteristics of this protocol are similar to TSP 310 ([I-D.blanchet-v6ops-tunnelbroker-tsp]), with simplified signaling. 312 o Tunnel signaling is transported over UDP/IPv4. 314 o Tunnel parameters are explicitly exchanged 316 o NAT detection/traversal 318 o Tunnel is explicitly configured from tunnel parameters exchanged 319 after signaling 321 o Simple mode supported (no authentication, one round trip); note 322 that getting to one roundtrip requires that the protocol is also 323 used for assigning the IPv6 address or prefix. 325 o Prefix delegation 327 The steps are as follows: 329 1. Client sends tunnel request over UDP/IPv4 331 2. Tunnel server listening on UDP port receives message and 332 determines if client behind NAT (based on IPv4 header information 333 and client IPv4 address in message) 335 3. Server sends tunnel information to client 337 4. Client and server configure tunnel endpoint. 339 client server 340 | 1.Tunnel request | 341 UDP/IPv4 |----------------------------->| 342 | | 2.NAT detection 343 | 3.Tunnel reply | 344 |<---------------------------- | 345 | Tunnel established | 4.configure tunnel 346 |==============================| 348 Figure 4: Tunnel setup protocol in simple mode 350 2.2.1 Tunnel Setup Messages 352 The tunnel request from the client must contain: 354 o Client IPv4 address (used for NAT detection) 356 o Tunnel encapsulation mode requested 358 The tunnel request from the client may contain (optional parameters): 360 o Prefix delegation request 362 o Authentication information 364 o Keepalive information 366 A possible protocol message structure is to use a fixed message 367 header followed by one or more TLV. This header is used in every 368 packets sent during the tunnel signaling. Other information is added 369 as TLV. 371 0 1 2 3 372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Source Port | Destination Port | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Length | Checksum | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | 0xF |M|KA |0| Encapsulation | Type | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 5: Tunnel setup protocol UDP header 383 The first 8 bytes is the standard UDP header. 385 0xF Marker. Used to differentiate a signaling packet from 386 an IPv6 datagram. 388 M One bit mode flag. Set to 0 for no authentication. 389 Set to 1 if authentication is requested. 391 KA Two bits keepalive flags. Set to 10 for no keepalive. 392 Set to 01 if keepalive requested. Set to 11 if don't 393 care (server reply will decide on what to do). 395 Encapsulation Indicates the type of encapsulation requested. Set to 396 41 for IPv6-over-IPv4 tunnels, ? for IPv6 over UDP. 397 May need to define new value here to define "IPv6 over 398 foo" (let server decide after NAT detection) 400 Type Message type (request, response) 402 2.2.1.1 Client IPv4 address 404 A client request uses the tunnel setup header, plus an extra TLV 405 containing the client IPv4 address. Including the IPv4 address 406 inside the payload can be used by the server to detect if the client 407 is behind a NAT. 409 Should address obfuscation be used? According to Teredo spec, it is. 410 [I-D.ietf-ipsec-nat-t-ike] uses a HASH of the address (and port). 411 The server can compute the HASH and validate if it corresponds to 412 what the client sees. If not, an address translation occurred. 414 0 1 2 3 415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | IPv4 address | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 6: Client IPv4 address TLV 424 2.2.1.1.1 Authentication information (optional) 426 If the M bit is set to 1, client is requesting authentication. A TLV 427 representing the identity of the client is sent. The server will 428 need to sent a challenge. 430 TLV details to be worked out. 432 2.2.1.1.2 Prefix delegation request (optional) 434 If a prefix delegation TLV is included in the request, it indicates 435 to the server that the client is requesting a prefix. 437 TLV details to be worked out. 439 0 1 2 3 440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Length | Prefix length | 0 | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 7: Prefix delegation request TLV 447 2.2.1.2 Server response 449 Message type is X (response) 451 In simple mode (no prefix delegation, no auth), the server will 452 provide the following information in its response 454 o IPv4 server endpoint (IPv6 in IPv4 tunnel) 456 o IPv6 address of client 457 o IPv6 address of server 459 o Encapsulation type 461 Keepalive TLV is sent by server if requested by client. TLV holds 462 the keepalive time interval to be used by the client. 464 If authentication is requested, the server will send a challenge to 465 the client. The authentication can be based on HTTP authentication 466 (RFC2617) or something like DHCP delayed authentication (RFC3118). 467 This needs to be further defined. Likely to add one round trip 468 (challenge-response). 470 If a prefix delegation is requested by the client, the server 471 response includes a TLV specifying the delegated prefix. 473 Some notes 475 o When keepalive is requested, should the client supply a keepalive 476 time interval that will be used? This can be useful from the 477 server point of view to decide when a tunnel is inactive 479 o The server could only return its IPv4 address to the client and 480 use RA to configure the client (IPv6 address, default route). 481 Doing so would have the advantage of using an existing mechanism 482 at the cost of an extra packet sent from the server to the client. 484 o DAD disabled by default on the tunnel link. 486 o Some authentication mechanism may depend on transport layer to 487 reliably deliver packets. Since UDP is used, may need to handle 488 this in protocol ([I-D.blanchet-v6ops-tunnelbroker-tsp]) 490 3. IANA Considerations 492 None at this point. 494 4. Security Considerations 496 Creating tunnel state based on the first UDP packet is can open the 497 server to a DoS attack with spoofed source addresses. There are a 498 couple of ways to mitigate this: 500 o Use ingress filtering towards your customers and at your own 501 borders, and provide the service to your own customers only. The 502 threat is eliminated. 504 o As above, but apply rate-limiting or other IP-address based 505 controls to those who desire to use the service from outside 506 networks. 508 o Require authentication from the outside users. 510 5. References 512 5.1 Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 518 Discovery for IP Version 6 (IPv6)", RFC 2461, December 519 1998. 521 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 522 Messages", RFC 3118, June 2001. 524 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 525 M. Carney, "Dynamic Host Configuration Protocol for IPv6 526 (DHCPv6)", RFC 3315, July 2003. 528 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 529 Host Configuration Protocol (DHCP) version 6", RFC 3633, 530 December 2003. 532 5.2 Informative References 534 [I-D.blanchet-v6ops-tunnelbroker-tsp] 535 Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the 536 Tunnel Setup Protocol(TSP)", 537 draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in 538 progress), June 2004. 540 [I-D.ietf-ipsec-nat-t-ike] 541 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 542 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 543 2004. 545 [I-D.ietf-ipv6-ndproxy] 546 Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND 547 Proxy)", draft-ietf-ipv6-ndproxy-00 (work in progress), 548 December 2004. 550 [I-D.ietf-send-ndopt] 551 Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 552 Nikander, "SEcure Neighbor Discovery (SEND)", 553 draft-ietf-send-ndopt-06 (work in progress), July 2004. 555 [RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 556 Tunnel Broker", RFC 3053, January 2001. 558 Authors' Addresses 560 Florent Parent 561 Hexago 562 2875 boul. Laurier, suite 300 563 Sainte-Foy, QC G1V 2M2 564 Canada 566 EMail: Florent.Parent@hexago.com 568 Pekka Savola 569 CSC - Scientific Computing Ltd. 570 Espoo 571 Finland 573 EMail: psavola@funet.fi 575 Alain Durand 576 SUN Microsystems,inc. 577 17 Network circle UMPK17-202 578 Menlo Park, CA 94025 579 USA 581 EMail: Alain.Durand@sun.com 583 Intellectual Property Statement 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org. 607 Disclaimer of Validity 609 This document and the information contained herein are provided on an 610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 612 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 613 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 614 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 Copyright Statement 619 Copyright (C) The Internet Society (2004). This document is subject 620 to the rights, licenses and restrictions contained in BCP 78, and 621 except as set forth therein, the authors retain all their rights. 623 Acknowledgment 625 Funding for the RFC Editor function is currently provided by the 626 Internet Society.