idnits 2.17.1 draft-ietf-v6ops-addr-select-ps-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 623. 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 (October 11, 2007) is 6040 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) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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: April 13, 2008 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 October 11, 2007 10 Problem Statement of Default Address Selection in Multi-prefix 11 Environment: Operational Issues of RFC3484 Default Rules 12 draft-ietf-v6ops-addr-select-ps-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 13, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 One physical network can carry multiple logical networks. Moreover, 46 we can use multiple physical networks at the same time in a host. In 47 that environment, end hosts might have multiple IP addresses and be 48 required to use them selectively. Without an appropriate source/ 49 destination address selection mechanism, the host will experience 50 some trouble in communication. RFC 3484 defines both the source and 51 destination address selection algorithms, but the multi-prefix 52 environment considered here needs additional rules beyond those of 53 the default operation. This document describes the possible problems 54 that end hosts could encounter in an environment with multiple 55 logical networks. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Source Address Selection . . . . . . . . . . . . . . . . . 3 63 2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4 64 2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5 65 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 5 66 2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7 67 2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 7 68 2.1.6. Multicast Source Address Selection . . . . . . . . . . 8 69 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 8 70 2.2. Destination Address Selection . . . . . . . . . . . . . . 8 71 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 8 72 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 9 73 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 10 74 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Intellectual Property and Copyright Statements . . . . . . . . . . 15 84 1. Introduction 86 One physical network can carry multiple logical networks. In that 87 case, an end-host has multiple IP addresses. In the IPv4-IPv6 dual 88 stack environment or in a site connected to both a ULA [RFC4193] and 89 Global scope networks, an end-host has multiple IP addresses. These 90 are examples of networks that we focus on in this document. In such 91 an environment, an end-host will encounter some communication 92 trouble. 94 Inappropriate source address selection at the end-host causes 95 unexpected asymmetric routing, filtering by a router or discarding of 96 packets bacause there is no route to the host. 98 Considering a multi-prefix environment, destination address selection 99 is also important for correct or better communication establishment. 101 RFC 3484 [RFC3484] defines both source and destination address 102 selection algorithms. In most cases, the host will be able to 103 communicate with the targeted host using the algorithms. However, 104 there are still problematic cases such as when multiple default 105 routes are supplied. This document describes such possibilities of 106 incorrect address selection, which leads to dropping packets and 107 communication failure. 109 In addition, the provision of an address policy table is an important 110 matter. RFC 3484 describes all the algorithms for setting the 111 address policy table but address policy provisions are not mentioned. 112 RFC 3484 only defines how to configure the address policy table 113 manually. 115 1.1. Scope of this document 117 There has been a lot of discussion about "multiple addresses/ 118 prefixes" but the multi-homing techniques for achieving redundancy 119 are out of our scope. Cooperation with a mechanism like shim6 is 120 rather desirable. We focus on an end-site network environment. The 121 scope of this document is to sort out problematic cases of false 122 dropping of the address selection within a multi-prefix environment. 124 2. Problem Statement 126 2.1. Source Address Selection 127 2.1.1. Multiple Routers on Single Interface 129 ================== 130 | Internet | 131 ================== 132 | | 133 2001:db8:1000::/36 | | 2001:db8:8000::/36 134 +----+-+ +-+----+ 135 | ISP1 | | ISP2 | 136 +----+-+ +-+----+ 137 | | 138 2001:db8:1000:::/48 | | 2001:db8:8000::/48 139 +------+---+ +----+-----+ 140 | Gateway1 | | Gateway2 | 141 +--------+-+ +-+--------+ 142 | | 143 2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64 144 | | 145 -----+-+-----+------ 146 | 147 +-+----+ 2001:db8:1000:1::EUI64 148 | Host | 2001:db8:8000:1::EUI64 149 +------+ 151 [Fig. 1] 153 Generally speaking, there is no interaction between next-hop 154 determination and address selection. In this example, when a Host 155 sends a packet via Gateway1, the Host does not necessarily choose 156 address 2001:db8:1000:1::EUI64 given by Gateway1 as the source 157 address. This causes the same problem as described in the next 158 section 'Ingress Filtering Problem'. 160 2.1.2. Ingress Filtering Problem 162 ================== 163 | Internet | 164 ================== 165 | | 166 2001:db8:1000::/36 | | 2001:db8:8000::/36 167 +----+-+ +-+----+ 168 | ISP1 | | ISP2 | 169 +----+-+ +-+----+ 170 | | 171 2001:db8:1000:::/48 | | 2001:db8:8000::/48 172 ++-------++ 173 | Gateway | 174 +----+----+ 175 | 2001:db8:1000:1::/64 176 | 2001:db8:8000:1::/64 177 ------+---+---------- 178 | 179 +-+----+ 2001:db8:1000:1::EUI64 180 | Host | 2001:db8:8000:1::EUI64 181 +------+ 183 [Fig. 2] 185 When a relatively small site, which we call a "customer network", is 186 attached to two upstream ISPs, each ISP delegates a network address 187 block, which is usually /48, and a host has multiple IPv6 addresses. 189 When the source address of an outgoing packet is not the one that is 190 delegated by an upstream ISP, there is a possibility that the packet 191 will be dropped at the ISP by its Ingress Filter. Ingress 192 filtering(uRPF: unicast Reverse Path Forwarding) is becoming more 193 popular among ISPs to mitigate the damage of DoS attacks. 195 In this example, when the Gateway chooses the default route to ISP2 196 and the Host chooses 2001:db8:1000:1::EUI64 as the source address for 197 packets sent to a host (2001:db8:2000::1) somewhere on the Internet, 198 the packets may be dropped at ISP2 because of Ingress Filtering. 200 2.1.3. Half-Closed Network Problem 202 You can see a second typical source address selection problem in a 203 multihome site with global-closed mixed connectivity like in the 204 figure below. In this case, Host-A is in a multihomed network and 205 has two IPv6 addresses, one delegated from each of the upstream ISPs. 206 Note that ISP2 is a closed network and does not have connectivity to 207 the Internet. 209 +--------+ 210 | Host-C | 2001:db8:a000::1 211 +-----+--+ 212 | 213 ============== +--------+ 214 | Internet | | Host-B | 2001:db8:8000::1 215 ============== +--------+ 216 | | 217 2001:db8:1000:/36 | | 2001:db8:8000::/36 218 +----+-+ +-+---++ 219 | ISP1 | | ISP2 | (Closed Network/VPN tunnel) 220 +----+-+ +-+----+ 221 | | 222 2001:db8:1000:/48 | | 2001:db8:8000::/48 223 ++-------++ 224 | Gateway | 225 +----+----+ 226 | 2001:db8:1000:1::/64 227 | 2001:db8:8000:1::/64 228 ------+---+---------- 229 | 230 +--+-----+ 2001:db8:1000:1::EUI64 231 | Host-A | 2001:db8:8000:1::EUI64 232 +--------+ 234 [Fig. 3] 236 You do not need two physical network connections here. The 237 connection from the Gateway to ISP2 can be a logical link over ISP1 238 and the Internet. 240 When Host-A starts the connection to Host-B in ISP2, the source 241 address of a packet that has been sent will be the one delegated from 242 ISP2, that is 2001:db8:8000:1::EUI64, because of rule 8 (longest 243 matching prefix) in RFC 3484. 245 Host-C is located somewhere on the Internet and has IPv6 address 246 2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest 247 matching algorithm chooses 2001:db8:8000:1::EUI64 for the source 248 address. In this case, the packet goes through ISP1 and may be 249 filtered by ISP1's ingress filter. Even if the packet is not 250 filtered by ISP1, a return packet from Host-C cannot possibly be 251 delivered to Host-A because the return packet is destined for 2001: 252 db8:8000:1::EUI64, which is closed from the Internet. 254 The important point is that each host chooses a correct source 255 address for a given destination address as long as NAT does not exist 256 in the IPv6 world. 258 2.1.4. Combined Use of Global and ULA 260 ============ 261 | Internet | 262 ============ 263 | 264 | 265 +----+----+ 266 | ISP | 267 +----+----+ 268 | 269 2001:db8:a::/48 | 270 +----+----+ 271 | Gateway | 272 +-+-----+-+ 273 | | 2001:db8:a:100::/64 274 fd01:2:3:200:/64 | | fd01:2:3:100:/64 275 -----+--+- -+--+---- 276 | | 277 fd01:2:3:200::EUI64 | | 2001:db8:a:100::EUI64 278 +----+----+ +-+----+ fd01:2:3:100::EUI64 279 | Printer | | Host | 280 +---------+ +------+ 282 [Fig. 4] 284 As NAP [I-D.ietf-v6ops-nap] describes, using a ULA may be beneficial 285 in some scenarios. If the ULA is used for internal communication, 286 packets with ULA need to be filtered at the Gateway. 288 There is no serious problem related to address selection in this 289 case, because of the dissimilarity between the ULA and the Global 290 Unicast Address. The longest matching rule of RFC 3484 chooses the 291 correct address for both intra-site and extra-site communication. 293 In a few years, however, the longest matching rule will not be able 294 to choose the correct address anymore. That is the moment when the 295 assignment of those Global Unicast Addresses starts, where the first 296 bit is 1. In RFC 4291 [RFC4291], almost all address spaces of IPv6, 297 including those whose first bit is 1, are assigned as Global Unicast 298 Addresses. 300 2.1.5. Site Renumbering 302 RFC 4192 [RFC4192] describes a recommended procedure for renumbering 303 a network from one prefix to another. An autoconfigured address has 304 a lifetime, so by stopping advertisement of the old prefix, the 305 autoconfigured address is eventually invalidated. 307 However, invalidating the old prefix takes a long time. You cannot 308 stop routing to the old prefix as long as the old prefix is not 309 removed from the host. This can be a tough issue for ISP network 310 administrators. 312 +-----+---+ 313 | Gateway | 314 +----+----+ 315 | 2001:db8:b::/64 (new) 316 | 2001:db8:a::/64 (old) 317 ------+---+---------- 318 | 319 +--+-----+ 2001:db8:b::EUI64 (new) 320 | Host-A | 2001:db8:a::EUI64 (old) 321 +--------+ 323 [Fig. 5] 325 2.1.6. Multicast Source Address Selection 327 This case is an example of Site-local or Global prioritization. When 328 you send a multicast packet across site-borders, the source address 329 of the multicast packet must be a global scope address. The longest 330 matching algorithm, however, selects a ULA if the sending host has 331 both a ULA and a global address. 333 2.1.7. Temporary Address Selection 335 RFC 3041 [RFC3041] defines a Temporary Address. The usage of a 336 Temporary Address has both pros and cons. That is good for viewing 337 web pages or communicating with the general public, but that is bad 338 for a service that uses address-based authentication and for logging 339 purposes. 341 If you could turn the temporary address on and off, that would be 342 better. If you could switch its usage per service(destination 343 address), that would also be better. The same situation can be found 344 when using HA and CoA in a MobileIP network. 346 2.2. Destination Address Selection 348 2.2.1. IPv4 or IPv6 prioritization 350 The default policy table gives IPv6 addresses higher precedence than 351 IPv4 addresses. There seem to be many cases, however, where network 352 administrators want to control the address selection policy of end- 353 hosts the other way around. 355 +---------+ 356 | Tunnel | 357 | Service | 358 +--+---++-+ 359 | || 360 | || 361 ===========||== 362 | Internet || | 363 ===========||== 364 | || 365 192.0.2.0/24 | || 366 +----+-+ || 367 | ISP | || 368 +----+-+ || 369 | || 370 IPv4 (Native) | || IPv6 (Tunnel) 371 192.0.2.0/26 | || 372 ++-----++-+ 373 | Gateway | 374 +----+----+ 375 | 2001:db8:a:1::/64 376 | 192.0.2.0/28 377 | 378 ------+---+---------- 379 | 380 +-+----+ 2001:db8:a:1:EUI64 381 | Host | 192.0.2.2 382 +------+ 384 [Fig. 6] 386 In the figure above, a site has native IPv4 and tunneled-IPv6 387 connectivity. Therefore, the administrator may want to set a higher 388 priority for using IPv4 than using IPv6 because the quality of the 389 tunnel network seems to be worse than that of the native transport. 391 2.2.2. ULA and IPv4 dual-stack environment 393 This is a special form of IPv4 and IPv6 prioritization. When an 394 enterprise has IPv4 Internet connectivity but does not yet have IPv6 395 Internet connectivity, and the enterprise wants to provide site-local 396 IPv6 connectivity, a ULA is the best choice for site-local IPv6 397 connectivity. Each employee host will have both an IPv4 global or 398 private address and a ULA. Here, when this host tries to connect to 399 Host-C that has registered both A and AAAA records in the DNS, the 400 host will choose AAAA as the destination address and the ULA for the 401 source address. This will clearly result in a connection failure. 403 +--------+ 404 | Host-C | AAAA = 2001:db8::80 405 +-----+--+ A = 192.0.2.1 406 | 407 ============ 408 | Internet | 409 ============ 410 | no IPv6 connectivity 411 +----+----+ 412 | Gateway | 413 +----+----+ 414 | 415 | fd01:2:3::/48 (ULA) 416 | 192.0.2.128/25 417 ++--------+ 418 | Router | 419 +----+----+ 420 | fd01:2:3:4::/64 (ULA) 421 | 192.0.2.240/28 422 ------+---+---------- 423 | 424 +-+----+ fd01:2:3:4::100 (ULA) 425 | Host | 192.0.2.245 426 +------+ 428 [Fig. 7] 430 2.2.3. ULA or Global Prioritization 432 Differentiating services by the client's source address is very 433 common. IP-address-based authentication is an typical example of 434 this. Another typical example is a web service that has pages for 435 the public and internal pages for employees or involved parties. Yet 436 another example is DNS zone splitting. 438 However, a ULA and IPv6 global address both have global scope, and 439 RFC3484 default rules do not specify which address should be given 440 priority. This point makes IPv6 implementation of address-based 441 service differentiation a bit harder. 443 +------+ 444 | Host | 445 +-+--|-+ 446 | | 447 ===========|== 448 | Internet | | 449 ===========|== 450 | | 451 | | 452 +----+-+ +-->+------+ 453 | ISP +------+ DNS | 2001:db8:a::80 454 +----+-+ +-->+------+ fc12:3456:789a::80 455 | | 456 2001:db8:a::/48 | | 457 fc12:3456:789a::/48 | | 458 +----+----|+ 459 | Gateway || 460 +---+-----|+ 461 | | 2001:db8:a:100::/64 462 | | fc12:3456:789a:100::/64 463 --+-+---|----- 464 | | 465 +-+---|+ 2001:db8:a:100::EUI64 466 | Host | fc12:3456:789a:100::EUI64 467 +------+ 469 [Fig. 7] 471 3. Conclusion 473 We have covered problems related to destination or source address 474 selection. These problems have their roots in the situation where 475 end-hosts have multiple IP addresses. In this situation, every end- 476 host must choose an appropriate destination and source address, which 477 cannot be achieved only by routers. 479 It should be noted that end-hosts must be informed about routing 480 policies of their upstream networks for appropriate address 481 selection. A site administrator must consider every possible address 482 false-selection problem and take countermeasures beforehand. 484 4. Security Considerations 486 When an intermediate router performs policy routing (e.g. source 487 address based routing), inappropriate address selection causes 488 unexpected routing. For example, in the network described in 2.1.3, 489 when Host-A uses a default address selection policy and chooses an 490 inappropriate address, a packet sent to VPN can be delivered to a 491 location via the Internet. This issue can lead to packet 492 eavesdropping or session hijack. 494 As documented in the security consideration section in RFC 3484, 495 address selection algorithms expose a potential privacy concern. 496 When a malicious host can make a target host perform address 497 selection, the malicious host can know multiple addresses attached to 498 the target host. In a case like 2.1.4, if an attacker can make Host 499 to send a multicast packet and the Host performs the default address 500 selection algorithm, the attacker may be able to determine the ULAs 501 attached to the Host. 503 These security risks have roots in inappropriate address selection. 504 Therefore, if a countermeasure is taken, and hosts always select an 505 appropriate address that is suitable to a site's network structure 506 and routing, these risks can be avoided. 508 5. IANA Considerations 510 This document has no actions for IANA. 512 6. References 514 6.1. Normative References 516 [RFC3484] Draves, R., "Default Address Selection for Internet 517 Protocol version 6 (IPv6)", RFC 3484, February 2003. 519 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 520 Addresses", RFC 4193, October 2005. 522 6.2. Informative References 524 [I-D.ietf-v6ops-nap] 525 Velde, G., "Local Network Protection for IPv6", 526 draft-ietf-v6ops-nap-06 (work in progress), January 2007. 528 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 529 Stateless Address Autoconfiguration in IPv6", RFC 3041, 530 January 2001. 532 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 533 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 534 September 2005. 536 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 537 Architecture", RFC 4291, February 2006. 539 Appendix A. Appendix. Revision History 541 01: 542 IP addresse notations changed to docmentation address. 543 Descriptoin of solutions deleted. 544 02: 545 Security considerations section rewritten according to comments 546 from SECDIR. 548 Authors' Addresses 550 Arifumi Matsumoto 551 NTT PF Lab 552 Midori-Cho 3-9-11 553 Musashino-shi, Tokyo 180-8585 554 Japan 556 Phone: +81 422 59 3334 557 Email: arifumi@nttv6.net 559 Tomohiro Fujisaki 560 NTT PF Lab 561 Midori-Cho 3-9-11 562 Musashino-shi, Tokyo 180-8585 563 Japan 565 Phone: +81 422 59 7351 566 Email: fujisaki@nttv6.net 568 Ruri Hiromi 569 Intec Netcore, Inc. 570 Shinsuna 1-3-3 571 Koto-ku, Tokyo 136-0075 572 Japan 574 Phone: +81 3 5665 5069 575 Email: hiromi@inetcore.com 576 Ken-ichi Kanayama 577 Intec Netcore, Inc. 578 Shinsuna 1-3-3 579 Koto-ku, Tokyo 136-0075 580 Japan 582 Phone: +81 3 5665 5069 583 Email: kanayama@inetcore.com 585 Full Copyright Statement 587 Copyright (C) The IETF Trust (2007). 589 This document is subject to the rights, licenses and restrictions 590 contained in BCP 78, and except as set forth therein, the authors 591 retain all their rights. 593 This document and the information contained herein are provided on an 594 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 595 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 596 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 597 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 598 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 599 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 601 Intellectual Property 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; nor does it represent that it has 608 made any independent effort to identify any such rights. Information 609 on the procedures with respect to rights in RFC documents can be 610 found in BCP 78 and BCP 79. 612 Copies of IPR disclosures made to the IETF Secretariat and any 613 assurances of licenses to be made available, or the result of an 614 attempt made to obtain a general license or permission for the use of 615 such proprietary rights by implementers or users of this 616 specification can be obtained from the IETF on-line IPR repository at 617 http://www.ietf.org/ipr. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights that may cover technology that may be required to implement 622 this standard. Please address the information to the IETF at 623 ietf-ipr@ietf.org. 625 Acknowledgment 627 Funding for the RFC Editor function is provided by the IETF 628 Administrative Support Activity (IASA).