idnits 2.17.1 draft-ietf-v6ops-addr-select-req-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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 622. ** 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 issues found here. 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 (Nov 2006) is 6369 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: 'I-D.arifumi-ipv6-policy-dist' is defined on line 512, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-addr-select-ps-00 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-addr-select-ps (ref. 'I-D.ietf-v6ops-addr-select-ps') ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-09) exists of draft-fujisaki-dhc-addr-select-opt-02 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-06 == Outdated reference: A later version (-04) exists of draft-ietf-shim6-locator-pair-selection-01 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Standards Track NTT 5 Expires: May 5, 2007 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 Nov 2006 10 Requirements for distributing RFC3484 address selection policy 11 draft-ietf-v6ops-addr-select-req-00.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 May 5, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 RFC3484 defines source and destination address selection algorithms 45 that are commonly deployed in current popular OSs. Meanwhile, there 46 is a possibility to provide multiple addresses in one physical 47 network. In such a multi-prefix environment, end-hosts could 48 encounter some troubles in the communication because of default use 49 of the RFC3484 mechanism. 51 Therefore, extending various rules beyond the default use of the 52 RFC3484 mechanism should be considered. We propose a concept of 53 distribution of address selection policy to an end-host as a solution 54 to these possible problems. 56 In this document, we describe detailed requirements of address 57 selection policy distribution. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 63 2. Policy distribution model and terminology . . . . . . . . . . 4 64 3. Requirements of Policy distribution . . . . . . . . . . . . . 5 65 3.1. Contents of Policy Table . . . . . . . . . . . . . . . . . 5 66 3.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Redistribution of changed Policy Table . . . . . . . . . . 5 68 3.4. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.5. Generating Policy Table per CPE/Node . . . . . . . . . . . 6 70 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Solutions for RFC3484 policy distribution . . . . . . . . . . 6 72 4.1. Policy distribution with router advertisement (RA) 73 message option . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Policy distribution in DHCPv6 . . . . . . . . . . . . . . 7 75 4.3. Using other protocols . . . . . . . . . . . . . . . . . . 7 76 4.4. Defining a new protocol . . . . . . . . . . . . . . . . . 8 77 4.5. Converting routing information to policy table . . . . . . 8 78 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5.1. Routing System Assistance for Address Selection by 80 Fred Baker . . . . . . . . . . . . . . . . . . . . . . . . 8 81 5.2. 3484-update . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.3. shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.4. policy distribution mechanism . . . . . . . . . . . . . . 10 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 90 Intellectual Property and Copyright Statements . . . . . . . . . . 14 92 1. Introduction 94 One physical network can have multiple logical networks. In that 95 case, an end-host has multiple IP addresses. In the IPv4-IPv6 dual 96 stack environment or in a site connected to both ULA [RFC4193] and 97 global scope networks, an end-host has multiple IP addresses. These 98 are examples of the networks that we focus on in this document. In 99 such an environment, an end-host will encounter some communication 100 trouble documented in PS. [I-D.ietf-v6ops-addr-select-ps] 102 RFC 3484 [RFC3484] defines both source and destination address 103 selection algorithms. RFC 3484 defines a default address table, and 104 enables adding other entries to this table. Flexible address 105 selection can be carried out. 107 In addition, the distribution of an address policy table is an 108 important matter. RFC 3484 describes all the algorithms for setting 109 the address policy table, but it makes no mention of 110 autoconfiguration. 112 To make a smooth connection with the appropriate source and 113 destination address selection inside a multi-prefix environment, 114 nodes must be informed about routing policies of their upstream 115 networks and possible source address selection policies. Then, those 116 nodes must put those policies into individual policy tables. 118 On the other hand, the RFC3484 mechanism is commonly deployed. 119 However, manual configuration of the policy table is not a feasible 120 idea and some automatic mechanism is needed. 122 Therefore, we propose a concept of distribution of address selection 123 policy from a network to an end-host to cooperate with the RFC3484 124 mechanism as a solution to these possible problems. 126 In this document, requirements for distribution of the address 127 selection policy are described for promotional use of the RFC3484 128 mechanism. Our goal is to carry our autoconfiguration with 129 distribution mechanism for utilization of RFC3484 more effectively. 131 1.1. Scope of this document 133 Revising address selection rules defined in RFC 3484 is out of our 134 scope. 136 The routing information from an upstream network is necessary, but in 137 this document, we are focused on how to select source and destination 138 addresses at the RFC3484 address policy table of the end-host. 140 In addition, there must be some practical ways or considerations 141 other than the RFC3484 policy table to solve the address selection 142 problem, such as utilization of some routing protocols or operational 143 technique with a specific route but these discussions are out of our 144 scope. However, we select some examples of other mechanisms in 145 Section 5 only for comparison. 147 2. Policy distribution model and terminology 149 The distribution model: 151 Fig. 1: (basic model) 152 Policies transferred from the Policy Broker to the Node over an access 153 network. 154 +----+ +-------------+ 155 |Node|<----------/policies/----------|Policy Broker| 156 +----+ +-------------+ 158 Fig. 2: (extended model) 159 +----+ +--------------+ +-------------+ 160 |Node|<---/policies/---|PolicyEnforcer|<---|Policy Broker| 161 +----+ +--------------+ +-------------+ 163 Essentials (or Principles): 165 The distribution of Policy, which means that the address selection 166 policy of RFC3484 is sent to nodes, has the following functions. 168 * Policy Broker, which means a Policy originator in xSP, for 169 example, a dhcp server, originates its policy and sends it to a 170 Node using some prefix-assignment Protocols. 172 * A Node receives a Policy as a client. Then the client puts those 173 policies into its own Policy Table, which means the address 174 selection table defined in RFC3484. 176 * Policy Broker should make the Policy so that it can be easily 177 embedded into Nodes. The Policy message format should be defined 178 based on the algorithm specified in RFC3484. 180 * There might be a situation in which a Policy Broker and Node are 181 disconnected, and no direct message is exchanged. In this case, 182 there is a middle box defined as a Policy Enforcer, for example, 183 CPE illustrated in Fig. 2, and it relays the policy to the Node. 184 Requirements should be considered to include the policy-relay 185 case. 187 Terminology: 189 Node: end-host, end-terminal 190 CPE: Customer premises equipment 191 PE: Provider Edge device 192 NAS: Network Access Server 194 Policy: address selection policy for RFC3484 rule set 195 Policy Enforcer: optionally attached equipment to relay policy 196 Policy Broker/Server: Policy Originator in xSP(mandate) 197 Prefix Delegation Protocol: Protocols to carry prefix information data 198 address selection table: address selection table defined in RFC3484 199 Policy Table: address selection table defined in RFC3484 201 3. Requirements of Policy distribution 203 The purpose of the Policy distribution mechanism is to distribute a 204 Policy Table to Nodes and configure the Policy Table on the Nodes 205 automatically. The use of a distributed Policy Table on Nodes for 206 other purposes (e.g, configuring routing Table on the Nodes) is out 207 of the scope of this document. 209 3.1. Contents of Policy Table 211 A Policy Table is a set of Policies described in RFC 3484. Each 212 Policy consists of four elements: prefix value, precedence value, 213 label value, and zone index value. The Policy distribution mechanism 214 should be able to distribute a Policy Table that has one or more 215 Policies to Nodes. 217 3.2. Timing 219 The Policy Table should be distributed to Nodes by a Policy broker at 220 any time when Nodes send a request for the Policy. 222 3.3. Redistribution of changed Policy Table 224 When a Policy broker has any change in a Policy Table that is 225 distributed to Nodes, the Policy broker should redistribute the 226 latest Policy Table to Nodes. 228 3.4. Sections 230 The Policy distribution mechanism should support being performed in 231 two kinds of sections: from PE to CPE and from CPE to Node. Policy 232 distribution mechanisms provided in each section may or many not be 233 the same. 235 3.5. Generating Policy Table per CPE/Node 237 The Policy distribution mechanism should allow for generating an 238 appropriate Policy Table per Node. For example, in some cases, each 239 Node may have a different set of assigned prefixes. In such a case, 240 the appropriate Policy Table for each Node may also be different, and 241 a Policy broker may be needed to generate the Policy Table according 242 to the identity of the Node. 244 3.6. Security 246 The Policy distribution mechanism should provide for reliable, secure 247 distribution of the Policy distribution from a Policy broker to 248 Nodes. 250 4. Solutions for RFC3484 policy distribution 252 As described in section 4.1, the address selection policy table 253 consists of four elements: prefix value, precedence, label, and zone- 254 index. The policy distribution mechanism will deliver lists of these 255 elements. 257 4.1. Policy distribution with router advertisement (RA) message option 259 The RA message can be used to deliver a policy table by adding a new 260 ND option. Existing ND transport mechanisms (i.e., advertisements 261 and solicitations) are used. Advantages and disadvantages are almost 262 the same as those described in [DNS configuration RFC, RA section]. 264 In addition, an advantage and disadvantages of distributing a policy 265 table are as follows. 267 Advantages: 268 - The RA message is used to deliver IPv6 address prefixes. 269 Therefore, delivering policies for selecting addresses with the 270 address attached to the host would be natural. 272 Disadvantages: 273 - The RA message is limited in size, and the RA may not be 274 sufficient to deliver full policies. The same compression 275 techniques, which were adopted in RFC4191 [RFC4191] can be used to 276 increase the number of policies delivered by RA messages. 278 - Currently, RA messages are not used between a PE and CPE. Other 279 protocols may be necessary to deliver a policy table. 281 - Configuring a policy table in each router that advertises RA 282 messages with an address prefix is necessary, so if a site has a 283 lot of routers, there will be a higher management cost. 285 - Delivering a specific policy table to one node is impossible 286 because RA messages are multicast. 288 4.2. Policy distribution in DHCPv6 290 By defining a new DHCPv6 option like 291 [I-D.fujisaki-dhc-addr-select-opt], a policy table can be delivered. 292 The advantages and disadvantages are almost the same as those 293 described in [DNS configuration RFC, DHCPv6 section]. 295 In addition, there are the following advantages and disadvantages. 297 Advantages: 298 - Currently, DHCPv6 prefix delegation is mainly used between a PE 299 and CPE. Delivering a policy table with prefixes is possible. 301 - A DHCPv6 server can deliver a host-specific policy table. 303 - By using a DHCPv6 relay mechanism, managing a policy table from a 304 central server is possible. 306 Disadvantages: 307 - The DHCPv6 message size is limited to the maximum UDP transmission 308 size, so delivering complex policies by DHCPv6 may be impossible. 310 4.3. Using other protocols 312 Using other protocols (i.e., http and ftp) to deliver the policy 313 table is possible. 315 Advantages: 316 - No new transport mechanisms are necessary. 318 Disadvantages: 319 - Other service discovery mechanisms will be necessary. 321 - The procedure to distribute information should be defined (e.g., 322 when to distribute and where the information is stored). 324 - Existing protocols may not have a mechanism to inform clients 325 about policy changes. 327 4.4. Defining a new protocol 329 Defining a new protocol to deliver a policy table will have the 330 following advantages and disadvantages. 332 Advantages: 333 - Defining a protocol suitable for policy distribution may be 334 possible. 336 Disadvantages: 337 - In addition to the disadvantages of 4.3, a new transport mechanism 338 needs to be defined. 340 4.5. Converting routing information to policy table 342 In an environment in which routing information and network links are 343 separated (e.g., between PE and CPE), converting routing information 344 to a policy table is possible. However, when intermediate routers 345 and nodes receive next-hop information, that is aggregated as a 346 default route or neighbor router, and cannot generate policy table [a 347 policy table cannot be generated]. 349 Advantages: 350 - No new distribution mechanism is necessary. 352 Disadvantages: 353 - This mechanism can be used only in a limited environment. 355 5. Discussion 357 Other than this policy distribution mechanism, a few mechanisms are 358 proposed. This section quickly reviews each proposal including a 359 policy distribution mechanism. 361 5.1. Routing System Assistance for Address Selection by Fred Baker 363 Fred Baker proposed to us about this mechanism. A host asks the DMZ 364 routers or the local router which is the best pair of source and 365 destination addresses when the host has a set of addresses A and 366 destination host has a set of addresses B. And then, the host uses 367 the policy provided by the server/routing system as a guide in 368 applying the response. He also proposed a mechanism that utilizes 369 ICMP error message to change the source address of the existing 370 session. This point resembles 5.2 3484-update mechanism, so the 371 following evaluation is based only on the first part of his proposal. 373 Advantages: 374 - A host can choose the best address pair that reflects the dynamic 375 changing routing status. 377 - The destination address selection can be handled in this 378 mechanisim as well as source address selection. 380 Disadvantages: 381 - A host can choose the best address pair that reflects the dynamic 383 - A host has to consult the routing system every time it starts a 384 connection if the host doesn't have address selection information 385 for the destination host or the information lifetime is expired. 386 This could be a possible scalability problem. 388 - A host has to wait until the response is received from the routing 389 system. 391 - The existing host/router OS implementation has to be changed a 392 lot. In the existing TCP/IP protocol stack implementation, 393 destination address selection is mainly the role of the 394 application and not that of the kernel unlike source address 395 selection. Therefore, implementing this model without causing any 396 affects on applications is not so easy. 398 5.2. 3484-update 400 M. Bagnulo proposed a new method of address selection in his draft. 401 [I-D.bagnulo-rfc3484-update] When the host notices that a network 402 failure occurs or packets are dropped somewhere in the network by for 403 example, an ingress filter, the host changes the source address of 404 the connection to another source address. The host stores a cache of 405 address selection information so that the host can select an 406 appropriate source address for new connections. 408 Advantages: 409 - A host can choose the best address that reflects the dynamic 410 changing routing status. 412 Disadvantages: 414 - A host has to learn address selection information per destination 415 host. The number of cache entries can be too big. 417 - The existing host/router OS implementation has to be changed a 418 lot. In particular, changing the source address of the existing 419 connection is not so easy and has a big impact on the existing 420 TCP/IP protocol stack implementation. 422 - There is not so much experience with this kind of address 423 selection cache mechanism. 425 - The host tries every address one-by-one, so the user has to wait 426 for a long time before the appropriate address pair is found. 428 5.3. shim6 430 shim6 is designed for site-multihoming. This mechanism introduces a 431 new method of address selection for session initiation and session 432 survivability, which is documented in 433 [I-D.ietf-shim6-locator-pair-selection] and 434 [I-D.ietf-shim6-failure-detection]. 436 The shim6 host detects connection failures and changes the source 437 address during the session. 439 Advantages: 440 - The shim6 host performs address selection that reflects network 441 failures in the source and destination end-to-end link. Moreover, 442 network failure avoidance can be achieved by end hosts themselves. 444 Disadvantages: 445 - A host has to learn address selection information per destination 446 host. The number of cache entry can be too big. 448 - The existing host/router OS implementation has to be changed 449 significantly. 451 - The host tries every address one-by-one, so the user has to wait 452 for a long time before the appropriate address pair is found. 454 5.4. policy distribution mechanism 456 This mechanism takes advantages of RFC 3484 Policy Table that is 457 widely deployed already. By distributing policies for Policy Table, 458 you can auto-configure a host's address selection policy. 460 Advantages: 462 - A host can receive and understand address selection information 463 before the host starts a connection. Therefore, the amount of 464 traffic and connection overhead time can be minimized. 465 - A host does not need any other address-selection-related 466 information once that host receives the address selection policy 467 set. This can also reduce the amount of traffic. 468 - The existing OS implementation does not need to be changed 469 significantly on the OS that implements the RFC 3484 policy table. 470 Only the delivery mechanism to the table has to be prepared. 471 - Destination address selection can also be controlled by this 472 mechanism. 474 Disadvantages: 475 - No other address selection rule that is beyond the RFC 3484 476 policy table framework can be implemented. 477 - The OS implementation has to be changed, and the policy 478 distribution server, such as a gateway router, has to be prepared. 479 - When DHCP or RA is used for transport mechanism of policy table, 480 frequently changing policy cannot be delivered to hosts quickly 481 because of the nature of these protocols. 483 6. Security Considerations 485 Address false-selection can lead to serious security problem, such as 486 session hijack. However, it should be noted that address selection 487 is eventually up to end-hosts. We have no means to enforce one 488 specific address selection policy to every end-host. So, a network 489 administrator has to take countermeasures for unexpected address 490 selection. 492 7. IANA Considerations 494 This document has no actions for IANA. 496 8. References 498 8.1. Normative References 500 [I-D.ietf-v6ops-addr-select-ps] 501 Matsumoto, A., "Problem Statement of Default Address 502 Selection in Multi-prefix Environment: Operational Issues 503 of RFC3484 Default Rules", 504 draft-ietf-v6ops-addr-select-ps-00 (work in progress), 505 November 2006. 507 [RFC3484] Draves, R., "Default Address Selection for Internet 508 Protocol version 6 (IPv6)", RFC 3484, February 2003. 510 8.2. Informative References 512 [I-D.arifumi-ipv6-policy-dist] 513 Matsumoto, A., "Practical Usages of Address Selection 514 Policy Distribution", draft-arifumi-ipv6-policy-dist-01 515 (work in progress), June 2006. 517 [I-D.bagnulo-rfc3484-update] 518 Bagnulo, M., "Updating RFC 3484 for multihoming support", 519 draft-bagnulo-rfc3484-update-00 (work in progress), 520 June 2006. 522 [I-D.fujisaki-dhc-addr-select-opt] 523 Fujisaki, T., "Distributing Default Address Selection 524 Policy using DHCPv6", 525 draft-fujisaki-dhc-addr-select-opt-02 (work in progress), 526 June 2006. 528 [I-D.ietf-shim6-failure-detection] 529 Arkko, J. and I. Beijnum, "Failure Detection and Locator 530 Pair Exploration Protocol for IPv6 Multihoming", 531 draft-ietf-shim6-failure-detection-06 (work in progress), 532 September 2006. 534 [I-D.ietf-shim6-locator-pair-selection] 535 Bagnulo, M., "Default Locator-pair selection algorithm for 536 the SHIM6 protocol", 537 draft-ietf-shim6-locator-pair-selection-01 (work in 538 progress), October 2006. 540 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 541 More-Specific Routes", RFC 4191, November 2005. 543 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 544 Addresses", RFC 4193, October 2005. 546 Authors' Addresses 548 Arifumi Matsumoto 549 NTT PF Lab 550 Midori-Cho 3-9-11 551 Musashino-shi, Tokyo 180-8585 552 Japan 554 Phone: +81 422 59 3334 555 Email: arifumi@nttv6.net 557 Tomohiro Fujisaki 558 NTT PF Lab 559 Midori-Cho 3-9-11 560 Musashino-shi, Tokyo 180-8585 561 Japan 563 Phone: +81 422 59 7351 564 Email: fujisaki@syce.net 566 Ruri Hiromi 567 Intec Netcore, Inc. 568 Shinsuna 1-3-3 569 Koto-ku, Tokyo 136-0075 570 Japan 572 Phone: +81 3 5665 5069 573 Email: hiromi@inetcore.com 575 Ken-ichi Kanayama 576 Intec Netcore, Inc. 577 Shinsuna 1-3-3 578 Koto-ku, Tokyo 136-0075 579 Japan 581 Phone: +81 3 5665 5069 582 Email: kanayama@inetcore.com 584 Full Copyright Statement 586 Copyright (C) The Internet Society (2006). 588 This document is subject to the rights, licenses and restrictions 589 contained in BCP 78, and except as set forth therein, the authors 590 retain all their rights. 592 This document and the information contained herein are provided on an 593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 595 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 596 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 597 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 600 Intellectual Property 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; nor does it represent that it has 607 made any independent effort to identify any such rights. Information 608 on the procedures with respect to rights in RFC documents can be 609 found in BCP 78 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the use of 614 such proprietary rights by implementers or users of this 615 specification can be obtained from the IETF on-line IPR repository at 616 http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to implement 621 this standard. Please address the information to the IETF at 622 ietf-ipr@ietf.org. 624 Acknowledgment 626 Funding for the RFC Editor function is provided by the IETF 627 Administrative Support Activity (IASA).