idnits 2.17.1 draft-ietf-v6ops-addr-select-ps-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 661. 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 (April 22, 2008) is 5848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational NTT 5 Expires: October 24, 2008 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 April 22, 2008 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-05.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 October 24, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 One physical link can carry multiple subnets. Moreover, we can use 46 multiple physical networks at the same time in a host. In that 47 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 default 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 subnets. 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 . . . . . . . . . . . . . . . . . . . 8 68 2.1.6. Multicast Source Address Selection . . . . . . . . . . 8 69 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 9 70 2.2. Destination Address Selection . . . . . . . . . . . . . . 9 71 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 9 72 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 10 73 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 11 74 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 80 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . . . . 16 84 1. Introduction 86 One physical link can carry multiple subnets. In that case, an end- 87 host has multiple IP addresses. In the IPv4-IPv6 dual stack 88 environment or in a site connected to both a ULA [RFC4193] and Global 89 scope networks, an end-host has multiple IP addresses. These are 90 examples of networks that we focus on in this document. In such an 91 environment, an end-host will encounter some communication troubles. 93 Inappropriate source address selection at the end-host causes 94 unexpected asymmetric routing, filtering by a router or discarding of 95 packets bacause there is no route to the host. 97 Considering a multi-prefix environment, destination address selection 98 is also important for correct or better communication establishment. 100 RFC 3484 [RFC3484] defines default source and destination address 101 selection algorithms. In most cases, the host will be able to 102 communicate with the targeted host using the algorithms. However, 103 there are still problematic cases. This document describes such 104 possibilities of incorrect address selection, which leads to dropping 105 packets and communication failure. 107 1.1. Scope of this document 109 There has been a lot of discussion about "multiple addresses/ 110 prefixes". As other mechanisms already exists, the multi-homing 111 techniques for achieving redundancy are out of our scope. 113 We focus on an end-site network environment. The scope of this 114 document is to sort out problematic cases related to address 115 selection. It includes problems that cannot always be solved by 116 changing the host's address selection algorithm, such as an address 117 selection mechanism that depends on the IPv6 address types. For 118 example, a global address isn't always globally routable and ULA's 119 routable domain is dependent on the network policy. This document 120 includes these kind of network policy related address selection 121 problems, as long as these problems are serious enough and worth 122 solving. 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 | Router1 | | Router2 | 141 +-------+-+ +-+-------+ 142 | | 143 2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64 144 | | 145 -----+-+-----+------ 146 | 147 +-+----+ 2001:db8:1000:1::100 148 | Host | 2001:db8:8000:1::100 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 Router1, the host does not necessarily choose 156 address 2001:db8:1000:1::100 given by Router1 as the source address. 157 This causes the same problem as described in the next section 158 '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 | Router | 174 +----+----+ 175 | 2001:db8:1000:1::/64 176 | 2001:db8:8000:1::/64 177 ------+---+---------- 178 | 179 +-+----+ 2001:db8:1000:1::100 180 | Host | 2001:db8:8000:1::100 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 Router chooses the default route to ISP2 196 and the Host chooses 2001:db8:1000:1::100 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 | Router | 225 +----+----+ 226 | 2001:db8:1000:1::/64 227 | 2001:db8:8000:1::/64 228 ------+---+---------- 229 | 230 +--+-----+ 2001:db8:1000:1::100 231 | Host-A | 2001:db8:8000:1::100 232 +--------+ 234 [Fig. 3] 236 You do not need two physical network connections here. The 237 connection from the Router 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::100, 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::100 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::100, 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. To solve this kind of 256 network policy based address selection problems, it is likely that 257 delivering addtional information to a node fits better than 258 algorithmic solutions that are local to the node. 260 2.1.4. Combined Use of Global and ULA 262 ============ 263 | Internet | 264 ============ 265 | 266 | 267 +----+----+ 268 | ISP | 269 +----+----+ 270 | 271 2001:db8:a::/48 | 272 +----+----+ 273 | Router | 274 +-+-----+-+ 275 | | 2001:db8:a:100::/64 276 fd01:2:3:200:/64 | | fd01:2:3:100:/64 277 -----+--+- -+--+---- 278 | | 279 fd01:2:3:200::101 | | 2001:db8:a:100::100 280 +----+----+ +-+----+ fd01:2:3:100::100 281 | Printer | | Host | 282 +---------+ +------+ 284 [Fig. 4] 286 As NAP [I-D.ietf-v6ops-nap] describes, using a ULA may be beneficial 287 in some scenarios. If the ULA is used for internal communication, 288 packets with ULA need to be filtered at the Router. 290 This case does not presently create an address selection problem 291 because of the dissimilarity between the ULA and the Global Unicast 292 Address. The longest matching rule of RFC 3484 chooses the correct 293 address for both intra-site and extra-site communication. 295 In the future, however, there is a possibility that the longest 296 matching rule will not be able to choose the correct address anymore. 297 That is the moment when the assignment of those Global Unicast 298 Addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], 299 almost all address spaces of IPv6, including those whose first bit is 300 1, are assigned as Global Unicast Addresses. 302 Namely, when we start to assign a part of the address block 8000::/1 303 as the global unicast address and that part is used somewhere in the 304 Internet, the longest matching rule ceases to function properly for 305 the people trying to connect to the servers with those addresses. 307 For example, when the destination host has an IPv6 address 8000::1, 308 and the originating host has 2001:db8::1 and fd0:1::1, the source 309 address will be fd00:1::1, because the longest matching bit length is 310 0 for 2001:db8::1 and 1 for fd0:1::1 respectively. 312 2.1.5. Site Renumbering 314 RFC 4192 [RFC4192] describes a recommended procedure for renumbering 315 a network from one prefix to another. An autoconfigured address has 316 a lifetime, so by stopping advertisement of the old prefix, the 317 autoconfigured address is eventually invalidated. 319 However, invalidating the old prefix takes a long time. You cannot 320 stop routing to the old prefix as long as the old prefix is not 321 removed from the host. This can be a tough issue for ISP network 322 administrators. 324 There is a technique of advertising the prefix with the preferred 325 lifetime zero, however, RFC 4862 [RFC4862] 5.5.4 does not absolutely 326 prohibit the use of a deprecated address for a new outgoing 327 connection due to limitations relating to what applications are 328 capable of doing." 330 +-----+---+ 331 | Router | 332 +----+----+ 333 | 2001:db8:b::/64 (new) 334 | 2001:db8:a::/64 (old) 335 ------+---+---------- 336 | 337 +--+-----+ 2001:db8:b::100 (new) 338 | Host-A | 2001:db8:a::100 (old) 339 +--------+ 341 [Fig. 5] 343 2.1.6. Multicast Source Address Selection 345 This case is an example of site-local or global prioritization. When 346 you send a multicast packet across site-borders, the source address 347 of the multicast packet should be a globally routable address. The 348 longest matching algorithm, however, selects a ULA if the sending 349 host has both a ULA and a Global Unicast Address. 351 2.1.7. Temporary Address Selection 353 RFC 3041 [RFC3041] defines a Temporary Address. The usage of a 354 Temporary Address has both pros and cons. That is good for viewing 355 web pages or communicating with the general public, but that is bad 356 for a service that uses address-based authentication and for logging 357 purposes. 359 If you could turn the temporary address on and off, that would be 360 better. If you could switch its usage per service (destination 361 address), that would also be better. The same situation can be found 362 when using HA (home address) and CoA (care-of address)in a Mobile 363 IPv6 [RFC3775] network. 365 At the Future Work section in RFC 3041, it discusses that the API 366 extension might be necessary to achieve better address selection 367 mechanism with finer granularity. 369 2.2. Destination Address Selection 371 2.2.1. IPv4 or IPv6 prioritization 373 The default policy table gives IPv6 addresses higher precedence than 374 IPv4 addresses. There seem to be many cases, however, where network 375 administrators want to control the address selection policy of end- 376 hosts the other way around. 378 +---------+ 379 | Tunnel | 380 | Service | 381 +--+---++-+ 382 | || 383 | || 384 ===========||== 385 | Internet || | 386 ===========||== 387 | || 388 192.0.2.0/24 | || 389 +----+-+ || 390 | ISP | || 391 +----+-+ || 392 | || 393 IPv4 (Native) | || IPv6 (Tunnel) 394 192.0.2.0/26 | || 395 ++-----++-+ 396 | Router | 397 +----+----+ 398 | 2001:db8:a:1::/64 399 | 192.0.2.0/28 400 | 401 ------+---+---------- 402 | 403 +-+----+ 2001:db8:a:1::100 404 | Host | 192.0.2.2 405 +------+ 407 [Fig. 6] 409 In the figure above, a site has native IPv4 and tunneled-IPv6 410 connectivity. Therefore, the administrator may want to set a higher 411 priority for using IPv4 than using IPv6 because the quality of the 412 tunnel network seems to be worse than that of the native transport. 414 2.2.2. ULA and IPv4 dual-stack environment 416 This is a special form of IPv4 and IPv6 prioritization. When an 417 enterprise has IPv4 Internet connectivity but does not yet have IPv6 418 Internet connectivity, and the enterprise wants to provide site-local 419 IPv6 connectivity, a ULA is the best choice for site-local IPv6 420 connectivity. Each employee host will have both an IPv4 global or 421 private address and a ULA. Here, when this host tries to connect to 422 Host-C that has registered both A and AAAA records in the DNS, the 423 host will choose AAAA as the destination address and the ULA for the 424 source address. This will clearly result in a connection failure. 426 +--------+ 427 | Host-C | AAAA = 2001:db8::80 428 +-----+--+ A = 192.0.2.1 429 | 430 ============ 431 | Internet | 432 ============ 433 | no IPv6 connectivity 434 +----+----+ 435 | Router | 436 +----+----+ 437 | 438 | fd01:2:3::/48 (ULA) 439 | 192.0.2.128/25 440 ++--------+ 441 | Router | 442 +----+----+ 443 | fd01:2:3:4::/64 (ULA) 444 | 192.0.2.240/28 445 ------+---+---------- 446 | 447 +-+----+ fd01:2:3:4::100 (ULA) 448 | Host | 192.0.2.245 449 +------+ 451 [Fig. 7] 453 2.2.3. ULA or Global Prioritization 455 Differentiating services by the client's source address is very 456 common. IP-address-based authentication is an typical example of 457 this. Another typical example is a web service that has pages for 458 the public and internal pages for employees or involved parties. Yet 459 another example is DNS zone splitting. 461 However, a ULA and IPv6 global address both have global scope, and 462 RFC3484 default rules do not specify which address should be given 463 priority. This point makes IPv6 implementation of address-based 464 service differentiation a bit harder. 466 +------+ 467 | Host | 468 +-+--|-+ 469 | | 470 ===========|== 471 | Internet | | 472 ===========|== 473 | | 474 | | 475 +----+-+ +-->+------+ 476 | ISP +------+ DNS | 2001:db8:a::80 477 +----+-+ +-->+------+ fc12:3456:789a::80 478 | | 479 2001:db8:a::/48 | | 480 fc12:3456:789a::/48 | | 481 +----+----|+ 482 | Router || 483 +---+-----|+ 484 | | 2001:db8:a:100::/64 485 | | fc12:3456:789a:100::/64 486 --+-+---|----- 487 | | 488 +-+---|+ 2001:db8:a:100::100 489 | Host | fc12:3456:789a:100::100 490 +------+ 492 [Fig. 7] 494 3. Conclusion 496 We have covered problems related to destination or source address 497 selection. These problems have their roots in the situation where 498 end-hosts have multiple IP addresses. In this situation, every end- 499 host must choose an appropriate destination and source address, which 500 cannot be achieved only by routers. 502 It should be noted that end-hosts must be informed about routing 503 policies of their upstream networks for appropriate address 504 selection. A site administrator must consider every possible address 505 false-selection problem and take countermeasures beforehand. 507 4. Security Considerations 509 When an intermediate router performs policy routing (e.g. source 510 address based routing), inappropriate address selection causes 511 unexpected routing. For example, in the network described in 2.1.3, 512 when Host-A uses a default address selection policy and chooses an 513 inappropriate address, a packet sent to VPN can be delivered to a 514 location via the Internet. This issue can lead to packet 515 eavesdropping or session hijack. However, sending the packet back to 516 the correct path from the attacker to the node is not easy, so these 517 two risk are not serious. 519 As documented in the security consideration section in RFC 3484, 520 address selection algorithms expose a potential privacy concern. 521 When a malicious host can make a target host perform address 522 selection, for example by sending a anycast or a multicast packet, 523 the malicious host can know multiple addresses attached to the target 524 host. In a case like 2.1.4, if an attacker can make Host to send a 525 multicast packet and Host performs the default address selection 526 algorithm, the attacker may be able to determine the ULAs attached to 527 the Host. 529 These security risks have roots in inappropriate address selection. 530 Therefore, if a countermeasure is taken, and hosts always select an 531 appropriate address that is suitable to a site's network structure 532 and routing, these risks can be avoided. 534 5. IANA Considerations 536 This document has no actions for IANA. 538 6. References 540 6.1. Normative References 542 [I-D.ietf-v6ops-nap] 543 Velde, G., "Local Network Protection for IPv6", 544 draft-ietf-v6ops-nap-06 (work in progress), January 2007. 546 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 547 Stateless Address Autoconfiguration in IPv6", RFC 3041, 548 January 2001. 550 [RFC3484] Draves, R., "Default Address Selection for Internet 551 Protocol version 6 (IPv6)", RFC 3484, February 2003. 553 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 554 in IPv6", RFC 3775, June 2004. 556 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 557 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 558 September 2005. 560 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 561 Addresses", RFC 4193, October 2005. 563 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 564 Architecture", RFC 4291, February 2006. 566 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 567 Address Autoconfiguration", RFC 4862, September 2007. 569 6.2. Informative References 571 Appendix A. Appendix. Revision History 573 01: 574 IP addresse notations changed to docmentation address. 575 Descriptoin of solutions deleted. 576 02: 577 Security considerations section rewritten according to comments 578 from SECDIR. 579 03: 580 Intended status changed to Informational. 581 04: 582 This version reflects comments from IESG members. 583 05: 584 This version reflects comments from IESG members and Bob Hinden. 586 Authors' Addresses 588 Arifumi Matsumoto 589 NTT PF Lab 590 Midori-Cho 3-9-11 591 Musashino-shi, Tokyo 180-8585 592 Japan 594 Phone: +81 422 59 3334 595 Email: arifumi@nttv6.net 596 Tomohiro Fujisaki 597 NTT PF Lab 598 Midori-Cho 3-9-11 599 Musashino-shi, Tokyo 180-8585 600 Japan 602 Phone: +81 422 59 7351 603 Email: fujisaki@nttv6.net 605 Ruri Hiromi 606 Intec Netcore, Inc. 607 Shinsuna 1-3-3 608 Koto-ku, Tokyo 136-0075 609 Japan 611 Phone: +81 3 5665 5069 612 Email: hiromi@inetcore.com 614 Ken-ichi Kanayama 615 Intec Netcore, Inc. 616 Shinsuna 1-3-3 617 Koto-ku, Tokyo 136-0075 618 Japan 620 Phone: +81 3 5665 5069 621 Email: kanayama@inetcore.com 623 Full Copyright Statement 625 Copyright (C) The IETF Trust (2008). 627 This document is subject to the rights, licenses and restrictions 628 contained in BCP 78, and except as set forth therein, the authors 629 retain all their rights. 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Intellectual Property 641 The IETF takes no position regarding the validity or scope of any 642 Intellectual Property Rights or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; nor does it represent that it has 646 made any independent effort to identify any such rights. Information 647 on the procedures with respect to rights in RFC documents can be 648 found in BCP 78 and BCP 79. 650 Copies of IPR disclosures made to the IETF Secretariat and any 651 assurances of licenses to be made available, or the result of an 652 attempt made to obtain a general license or permission for the use of 653 such proprietary rights by implementers or users of this 654 specification can be obtained from the IETF on-line IPR repository at 655 http://www.ietf.org/ipr. 657 The IETF invites any interested party to bring to its attention any 658 copyrights, patents or patent applications, or other proprietary 659 rights that may cover technology that may be required to implement 660 this standard. Please address the information to the IETF at 661 ietf-ipr@ietf.org. 663 Acknowledgment 665 Funding for the RFC Editor function is provided by the IETF 666 Administrative Support Activity (IASA).