idnits 2.17.1 draft-ietf-v6ops-addr-select-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. 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 IETF Trust 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 (Feb 2007) is 6280 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) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-09) exists of draft-fujisaki-dhc-addr-select-opt-03 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-07 == Outdated reference: A later version (-04) exists of draft-ietf-shim6-locator-pair-selection-01 Summary: 2 errors (**), 0 flaws (~~), 4 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: August 5, 2007 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 Feb 2007 10 Requirements for the address selection mechanisms 11 draft-ietf-v6ops-addr-select-req-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 5, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 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. Some mechanism for the address selection 50 problems are proposed including RFC3484 policy table distribution and 51 RFC3484-update. This document describes the requirements for these 52 address selection mechanisms. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 58 2. Requirements of Address Selection . . . . . . . . . . . . . . 3 59 2.1. Contents of Policy Table . . . . . . . . . . . . . . . . . 3 60 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Redistribution of changed Policy Table . . . . . . . . . . 4 62 2.4. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.5. Generating Policy Table per CPE/Node . . . . . . . . . . . 4 64 2.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Possible Solutions for Address Selection Problem . . . . . . . 4 66 3.1. Routing System Assistance for Address Selection by 67 Fred Baker . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. 3484-update . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4. policy distribution mechanism . . . . . . . . . . . . . . 6 71 4. Discussion at 67th IETF . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Solutions for RFC3484 policy distribution . . . . . . 9 75 A.1. Policy distribution with router advertisement (RA) 76 message option . . . . . . . . . . . . . . . . . . . . . . 10 77 A.2. Policy distribution in DHCPv6 . . . . . . . . . . . . . . 10 78 A.3. Using other protocols . . . . . . . . . . . . . . . . . . 11 79 A.4. Defining a new protocol . . . . . . . . . . . . . . . . . 11 80 A.5. Converting routing information to policy table . . . . . . 11 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 Intellectual Property and Copyright Statements . . . . . . . . . . 14 87 1. Introduction 89 One physical network can have multiple logical networks. In that 90 case, an end-host has multiple IP addresses. In the IPv4-IPv6 dual 91 stack environment or in a site connected to both ULA [RFC4193] and 92 global scope networks, an end-host has multiple IP addresses. These 93 are examples of the networks that we focus on in this document. In 94 such an environment, an end-host will encounter some communication 95 trouble documented in PS. [I-D.arifumi-v6ops-addr-select-ps] 97 RFC 3484 [RFC3484] defines both source and destination address 98 selection algorithms. RFC 3484 defines a default address table, and 99 enables adding other entries to this table. Flexible address 100 selection can be carried out. 102 In addition, the distribution of an address policy table is an 103 important matter. RFC 3484 describes all the algorithms for setting 104 the address policy table, but it makes no mention of 105 autoconfiguration. 107 To make a smooth connection with the appropriate source and 108 destination address selection inside a multi-prefix environment, 109 nodes must be informed about routing policies of their upstream 110 networks and possible source address selection policies. Then, those 111 nodes must put those policies into individual policy tables. 113 On the other hand, the RFC3484 mechanism is commonly deployed. 114 However, manual configuration of the policy table is not a feasible 115 idea and some automatic mechanism is needed. 117 In this document, requirements for distribution of the address 118 selection policy are described for promotional use of the RFC3484 119 mechanism. 121 1.1. Scope of this document 123 The routing information from an upstream network is necessary, but in 124 this document, we are focused on how to select source and destination 125 addresses at the RFC3484 address policy table of the end-host. 127 2. Requirements of Address Selection 129 2.1. Contents of Policy Table 131 A Policy Table is a set of Policies described in RFC 3484. Each 132 Policy consists of four elements: prefix value, precedence value, 133 label value, and zone index value. The Policy distribution mechanism 134 should be able to distribute a Policy Table that has one or more 135 Policies to Nodes. 137 2.2. Timing 139 The Policy Table should be distributed to Nodes by a Policy broker at 140 any time when Nodes send a request for the Policy. 142 2.3. Redistribution of changed Policy Table 144 When a Policy broker has any change in a Policy Table that is 145 distributed to Nodes, the Policy broker should redistribute the 146 latest Policy Table to Nodes. 148 2.4. Sections 150 The Policy distribution mechanism should support being performed in 151 two kinds of sections: from PE to CPE and from CPE to Node. Policy 152 distribution mechanisms provided in each section may or many not be 153 the same. 155 2.5. Generating Policy Table per CPE/Node 157 The Policy distribution mechanism should allow for generating an 158 appropriate Policy Table per Node. For example, in some cases, each 159 Node may have a different set of assigned prefixes. In such a case, 160 the appropriate Policy Table for each Node may also be different, and 161 a Policy broker may be needed to generate the Policy Table according 162 to the identity of the Node. 164 2.6. Security 166 The Policy distribution mechanism should provide for reliable, secure 167 distribution of the Policy distribution from a Policy broker to 168 Nodes. 170 3. Possible Solutions for Address Selection Problem 172 A few mechanisms for address selection problems are proposed. This 173 section quickly reviews each proposal including a policy distribution 174 mechanism. 176 3.1. Routing System Assistance for Address Selection by Fred Baker 178 Fred Baker proposed to us about this mechanism. A host asks the DMZ 179 routers or the local router which is the best pair of source and 180 destination addresses when the host has a set of addresses A and 181 destination host has a set of addresses B. And then, the host uses 182 the policy provided by the server/routing system as a guide in 183 applying the response. He also proposed a mechanism that utilizes 184 ICMP error message to change the source address of the existing 185 session. This point resembles 5.2 3484-update mechanism, so the 186 following evaluation is based only on the first part of his proposal. 188 Advantages: 189 - A host can choose the best address pair that reflects the dynamic 190 changing routing status. 192 - The destination address selection can be handled in this 193 mechanisim as well as source address selection. 195 Disadvantages: 196 - A host can choose the best address pair that reflects the dynamic 198 - A host has to consult the routing system every time it starts a 199 connection if the host doesn't have address selection information 200 for the destination host or the information lifetime is expired. 201 This could be a possible scalability problem. 203 - A host has to wait until the response is received from the routing 204 system. 206 - The existing host/router OS implementation has to be changed a 207 lot. In the existing TCP/IP protocol stack implementation, 208 destination address selection is mainly the role of the 209 application and not that of the kernel unlike source address 210 selection. Therefore, implementing this model without causing any 211 affects on applications is not so easy. 213 3.2. 3484-update 215 M. Bagnulo proposed a new method of address selection in his draft. 216 [I-D.bagnulo-rfc3484-update] When the host notices that a network 217 failure occurs or packets are dropped somewhere in the network by for 218 example, an ingress filter, the host changes the source address of 219 the connection to another source address. The host stores a cache of 220 address selection information so that the host can select an 221 appropriate source address for new connections. 223 Advantages: 224 - A host can choose the best address that reflects the dynamic 225 changing routing status. 227 Disadvantages: 229 - A host has to learn address selection information per destination 230 host. The number of cache entries can be too big. 232 - The existing host/router OS implementation has to be changed a 233 lot. In particular, changing the source address of the existing 234 connection is not so easy and has a big impact on the existing 235 TCP/IP protocol stack implementation. 237 - There is not so much experience with this kind of address 238 selection cache mechanism. 240 - The host tries every address one-by-one, so the user has to wait 241 for a long time before the appropriate address pair is found. 243 3.3. shim6 245 shim6 is designed for site-multihoming. This mechanism introduces a 246 new method of address selection for session initiation and session 247 survivability, which is documented in 248 [I-D.ietf-shim6-locator-pair-selection] and 249 [I-D.ietf-shim6-failure-detection]. 251 The shim6 host detects connection failures and changes the source 252 address during the session. 254 Advantages: 255 - The shim6 host performs address selection that reflects network 256 failures in the source and destination end-to-end link. Moreover, 257 network failure avoidance can be achieved by end hosts themselves. 259 Disadvantages: 260 - A host has to learn address selection information per destination 261 host. The number of cache entry can be too big. 263 - The existing host/router OS implementation has to be changed 264 significantly. 266 - The host tries every address one-by-one, so the user has to wait 267 for a long time before the appropriate address pair is found. 269 3.4. policy distribution mechanism 271 This mechanism takes advantages of RFC 3484 Policy Table that is 272 widely deployed already. By distributing policies for Policy Table, 273 you can auto-configure a host's address selection policy. 275 Advantages: 277 - A host can receive and understand address selection information 278 before the host starts a connection. Therefore, the amount of 279 traffic and connection overhead time can be minimized. 281 - A host does not need any other address-selection-related 282 information once that host receives the address selection policy 283 set. This can also reduce the amount of traffic. 285 - The existing OS implementation does not need to be changed 286 significantly on the OS that implements the RFC 3484 policy table. 287 Only the delivery mechanism to the table has to be prepared. 289 - Destination address selection can also be controlled by this 290 mechanism. 292 Disadvantages: 293 - No other address selection rule that is beyond the RFC 3484 policy 294 table framework can be implemented. 296 - The OS implementation has to be changed, and the policy 297 distribution server, such as a gateway router, has to be prepared. 299 - When DHCP or RA is used for transport mechanism of policy table, 300 frequently changing policy cannot be delivered to hosts quickly 301 because of the nature of these protocols. 303 4. Discussion at 67th IETF 305 Here listed some points that was raised at San Diego and comments 306 below. These points are classified into 3 classes from the aspect of 307 RFC3484. It seems to be better to settle the basis for this 308 discussion. That is, we can assume RFC3484 as it is now, we should 309 modify RFC3484 or we should start from nothing. 311 1) Issues that don't need RFC3484 modification"> 313 - The ability to deliver specific set of policies to a specific host 315 This issue is already in the requiremnt draft. 317 2) Issues that may need slight RFC3484 change. 319 - The address type dependent preference. 321 There was a thread "address selection and DHCPv6" by James Carlson 322 at IPv6 ML about address type dependent preference, such as 323 DHCPv6, RA, manual and also privacy extension(RFC3041) address. 324 http://www1.ietf.org/mail-archive/web/ipv6/current/msg06910.html 326 It is hard to define default preferences for these address types, 327 because it depends on the usage of these addresses, but not on 328 address types themselves. It is the policy table where you can 329 control host's address selection behavior. At this time, however, 330 I cannot say policy table is the perfect way to fulfill this 331 requirement. 333 For example, You can set priority on 3041 address by putting a 334 line in policy table specifying 3041 address by 128-bit prefixlen 335 and continuing to update policy table according to 3041 address 336 changes. But, this is surely troublesome for users and 337 implementers. 339 One idea is to update RFC3484 policy table definition so that it 340 can handle alias addresses like privacy, DHCPv6 generated, RA 341 generated, manually generated (and even Home Address ?) 343 To prefer privacy address by default, and to prefer RA-generated 344 address for site internal, the policy table will look like this. 346 Prefix Pref Label 347 2001:db8:1234::(PRIVACY)/128 30 2 348 ::/0 10 2 349 2001:db8:1234::(RA):/128 30 1 350 2001:db8::/48 20 1 352 3) Issues that need big RFC 3484 change. 353 - Multiple Interfaces Issues 355 Dave Thaler gave us comments that multiple-interface hosts may 356 face policy collision and distribution of dst address selection 357 policy and src address selection policy should be separated. 358 Also, per-interface policy table was proposed. 360 After all, this is a policy collision problem. To make a host 361 have one policy table per network interface doesn't solve policy 362 collision issue. Source address selection is performed after 363 output interface is selected, but destination address selection is 364 before output interface selection. In this case, destination 365 address selection uses all the policy tables a host has, so here 366 collision can happen. 368 Separating destination address selection and source address 369 selection will have a big change on RFC3484 policy table 370 definition. Though it may be a good idea to avoid source address 371 selection policy collision. 373 - application specific address selection should be considered. 374 Also, XML was proposed for the right format to describe those 375 policies. 377 This issue is so much application dependent. Even if policy table 378 supports application specific policies, the application doesn't 379 necessarily follow the policy table. It seems to me a better idea 380 to use address selection APIs or application specific 381 configuration file for it. 383 5. Security Considerations 385 Address false-selection can lead to serious security problem, such as 386 session hijack. However, it should be noted that address selection 387 is eventually up to end-hosts. We have no means to enforce one 388 specific address selection policy to every end-host. So, a network 389 administrator has to take countermeasures for unexpected address 390 selection. 392 6. IANA Considerations 394 This document has no actions for IANA. 396 Appendix A. Solutions for RFC3484 policy distribution 398 In this section, several mechanisms for distributing RFC3484 policy 399 are compared and evaluated. The reason why this section is in 400 appendix is that these discussions should be after address selection 401 mechanism selection is finished and policy distribution mechanism is 402 selected. solution. 404 As described in section 3.1, the address selection policy table 405 consists of four elements: prefix value, precedence, label, and zone- 406 index. The policy distribution mechanism will deliver lists of these 407 elements. 409 A.1. Policy distribution with router advertisement (RA) message option 411 The RA message can be used to deliver a policy table by adding a new 412 ND option. Existing ND transport mechanisms (i.e., advertisements 413 and solicitations) are used. Advantages and disadvantages are almost 414 the same as those described in [DNS configuration RFC, RA section]. 416 In addition, an advantage and disadvantages of distributing a policy 417 table are as follows. 419 Advantages: 420 - The RA message is used to deliver IPv6 address prefixes. 421 Therefore, delivering policies for selecting addresses with the 422 address attached to the host would be natural. 424 Disadvantages: 425 - The RA message is limited in size, and the RA may not be 426 sufficient to deliver full policies. The same compression 427 techniques, which were adopted in RFC4191 [RFC4191] can be used to 428 increase the number of policies delivered by RA messages. 430 - Currently, RA messages are not used between a PE and CPE. Other 431 protocols may be necessary to deliver a policy table. 433 - Configuring a policy table in each router that advertises RA 434 messages with an address prefix is necessary, so if a site has a 435 lot of routers, there will be a higher management cost. 437 - Delivering a specific policy table to one node is impossible 438 because RA messages are multicast. 440 A.2. Policy distribution in DHCPv6 442 By defining a new DHCPv6 option like 443 [I-D.fujisaki-dhc-addr-select-opt], a policy table can be delivered. 444 The advantages and disadvantages are almost the same as those 445 described in [DNS configuration RFC, DHCPv6 section]. 447 In addition, there are the following advantages and disadvantages. 449 Advantages: 450 - Currently, DHCPv6 prefix delegation is mainly used between a PE 451 and CPE. Delivering a policy table with prefixes is possible. 453 - A DHCPv6 server can deliver a host-specific policy table. 455 - By using a DHCPv6 relay mechanism, managing a policy table from a 456 central server is possible. 458 Disadvantages: 459 - The DHCPv6 message size is limited to the maximum UDP transmission 460 size, so delivering complex policies by DHCPv6 may be impossible. 462 A.3. Using other protocols 464 Using other protocols (i.e., http and ftp) to deliver the policy 465 table is possible. 467 Advantages: 468 - No new transport mechanisms are necessary. 470 Disadvantages: 471 - Other service discovery mechanisms will be necessary. 473 - The procedure to distribute information should be defined (e.g., 474 when to distribute and where the information is stored). 476 - Existing protocols may not have a mechanism to inform clients 477 about policy changes. 479 A.4. Defining a new protocol 481 Defining a new protocol to deliver a policy table will have the 482 following advantages and disadvantages. 484 Advantages: 485 - Defining a protocol suitable for policy distribution may be 486 possible. 488 Disadvantages: 489 - In addition to the disadvantages of 4.3, a new transport mechanism 490 needs to be defined. 492 A.5. Converting routing information to policy table 494 In an environment in which routing information and network links are 495 separated (e.g., between PE and CPE), converting routing information 496 to a policy table is possible. However, when intermediate routers 497 and nodes receive next-hop information, that is aggregated as a 498 default route or neighbor router, and cannot generate policy table [a 499 policy table cannot be generated]. 501 Advantages: 502 - No new distribution mechanism is necessary. 504 Disadvantages: 505 - This mechanism can be used only in a limited environment. 507 7. References 509 7.1. Normative References 511 [I-D.arifumi-v6ops-addr-select-ps] 512 Matsumoto, A., "Problem Statement of Default Address 513 Selection in Multi-prefix Environment: Operational Issues 514 of RFC3484 Default Rules", 515 draft-arifumi-v6ops-addr-select-ps-01 (work in progress), 516 October 2006. 518 [RFC3484] Draves, R., "Default Address Selection for Internet 519 Protocol version 6 (IPv6)", RFC 3484, February 2003. 521 7.2. Informative References 523 [I-D.bagnulo-rfc3484-update] 524 Bagnulo, M., "Updating RFC 3484 for multihoming support", 525 draft-bagnulo-rfc3484-update-00 (work in progress), 526 June 2006. 528 [I-D.fujisaki-dhc-addr-select-opt] 529 Fujisaki, T., "Distributing Default Address Selection 530 Policy using DHCPv6", 531 draft-fujisaki-dhc-addr-select-opt-03 (work in progress), 532 January 2007. 534 [I-D.ietf-shim6-failure-detection] 535 Arkko, J. and I. Beijnum, "Failure Detection and Locator 536 Pair Exploration Protocol for IPv6 Multihoming", 537 draft-ietf-shim6-failure-detection-07 (work in progress), 538 December 2006. 540 [I-D.ietf-shim6-locator-pair-selection] 541 Bagnulo, M., "Default Locator-pair selection algorithm for 542 the SHIM6 protocol", 543 draft-ietf-shim6-locator-pair-selection-01 (work in 544 progress), October 2006. 546 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 547 More-Specific Routes", RFC 4191, November 2005. 549 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 550 Addresses", RFC 4193, October 2005. 552 Authors' Addresses 554 Arifumi Matsumoto 555 NTT PF Lab 556 Midori-Cho 3-9-11 557 Musashino-shi, Tokyo 180-8585 558 Japan 560 Phone: +81 422 59 3334 561 Email: arifumi@nttv6.net 563 Tomohiro Fujisaki 564 NTT PF Lab 565 Midori-Cho 3-9-11 566 Musashino-shi, Tokyo 180-8585 567 Japan 569 Phone: +81 422 59 7351 570 Email: fujisaki@syce.net 572 Ruri Hiromi 573 Intec Netcore, Inc. 574 Shinsuna 1-3-3 575 Koto-ku, Tokyo 136-0075 576 Japan 578 Phone: +81 3 5665 5069 579 Email: hiromi@inetcore.com 581 Ken-ichi Kanayama 582 Intec Netcore, Inc. 583 Shinsuna 1-3-3 584 Koto-ku, Tokyo 136-0075 585 Japan 587 Phone: +81 3 5665 5069 588 Email: kanayama@inetcore.com 590 Full Copyright Statement 592 Copyright (C) The IETF Trust (2007). 594 This document is subject to the rights, licenses and restrictions 595 contained in BCP 78, and except as set forth therein, the authors 596 retain all their rights. 598 This document and the information contained herein are provided on an 599 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 600 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 601 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 602 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 603 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 604 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 606 Intellectual Property 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at 628 ietf-ipr@ietf.org. 630 Acknowledgment 632 Funding for the RFC Editor function is provided by the IETF 633 Administrative Support Activity (IASA).