idnits 2.17.1 draft-clausen-manet-linktype-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 620. 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 27, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Intended status: Informational October 27, 2008 5 Expires: April 30, 2009 7 The MANET Link Type 8 draft-clausen-manet-linktype-00 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 30, 2009. 35 Abstract 37 This document describes the link characteristics and properties for 38 links over which MANET protocols are designed to operate. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 3. The MANET Router . . . . . . . . . . . . . . . . . . . . . . . 4 45 4. MANET Interfaces . . . . . . . . . . . . . . . . . . . . . . . 5 46 5. MANET Network Dynamics . . . . . . . . . . . . . . . . . . . . 6 47 6. The MANET Link Type . . . . . . . . . . . . . . . . . . . . . 8 48 6.1. Connectivity: Symmetry, Transitivity, Continouity ? . . . 8 49 6.2. Subnet Model and Addresses . . . . . . . . . . . . . . . . 9 50 6.3. Multicast and Broadcast Scopes . . . . . . . . . . . . . . 10 51 7. The MANET Addressing Architecture . . . . . . . . . . . . . . 11 52 7.1. MANET Interface Configuration . . . . . . . . . . . . . . 12 53 7.2. MANET Addressing Architecture Characteristics . . . . . . 12 54 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 56 10. Informative References . . . . . . . . . . . . . . . . . . . . 13 57 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 59 1. Introduction 61 A Mobile Ad hoc NETwork, or MANET, is commonly described as a loosely 62 connected set of routers with no predetermined infrastructure and 63 where the routers discover and maintain, even when faced with 64 dynamically changing topologies, a routing structure. Neither the 65 set of routers in the MANET nor their connections to each other can 66 be assumed to be pre-determined nor to be known in advance; either 67 may change randomly over the lifetime of the MANET. 69 MANETs are often constructed from routers using wireless broadcast 70 interfaces, such as IEEE 802.11 interfaces in ad hoc mode, in order 71 to establish connectivity among each other. Other network interfaces 72 and link types, such as Ethernet or point-top-point IP over IP 73 tunnels, are occasionally present between routers in a MANET, and are 74 then also used by MANET protocols, such as a MANET routing protocols 75 (e.g. [RFC3626], [RFC3561], [RFC4728], [RFC3684]) calculating 76 routing paths. 78 This presents MANET protocols with the challenge of operating not 79 only over well known link types such as an Ethernet or a point-to- 80 point IP over IP tunnel, but also to over links as formed over 81 wireless broadcast interfaces. 83 The purpose of this document is to describe a MANET Link Type which 84 accommodates both, such that a protocol designed for the MANET Link 85 Type will operate correctly both when presented with e.g. "an 86 Ethernet" or with "a wireless broadcast interface". 88 2. Terminology 90 Neighbor - a router B is a neighbor of a router A if B can receive 91 communication directly from router A, without passing through any 92 intermediates at the same layer (i.e. an IP router). 94 Wireless broadcast interface - a network interface where the medium 95 supports true broadcast transmissions, and where link layer 96 messages can be either multicast or unicast. The transmission 97 reachability is constrained by the radio range of the 98 transmittter, which can be time-varying. 100 Node - any device (router or host) that implements IP. 102 Router - a node that forwards IP packets not explicitly addressed to 103 itself. 105 MANET Router - a router which has, at least, one MANET interface 106 towards a link of the MANET Link Type, as described in this 107 document, and which is capable of ensuring correct operation over 108 that link. 110 Host - any node that is not a router, i.e. a host does not forward 111 packets addressed to others. A Host runs a standard IP stack, and 112 is subject to no MANET Link specific assumptions. 114 MANET Link - a link of the MANET Link type, as described in this 115 document. 117 3. The MANET Router 119 The entities that are concerned by the MANET Link Type described in 120 this document are MANET routers. A MANET Router is a router which 121 has at least one, but possibly more, MANET interfaces, and zero or 122 more interfaces of other types and towards other networks, as 123 illustrated in Figure 1. 125 \ | / 126 \|/ ------- MANET Interface(s) 127 | 128 +---+----+ 129 | | 130 | Manet | 131 | Router | 132 | | 133 +--------+ 134 | | 135 | | ------- NON-MANET Interface(s) 136 ----+ +---- 138 Figure 1: MANET Router 140 MANET interfaces are the only interfaces which are exposed to links 141 of the MANET Link Type, as described in this document. Protocols 142 operating directly over these MANET interfaces are, therefore, the 143 only protocols which are required to be aware of the characteristics 144 of the MANET Link Type. 146 This entails that protocols which are not intended to operate over 147 MANET interfaces are not required to be able to handle the 148 characteristics of the MANET Link Type. 150 In particular, any node connected to a MANET router over an interface 151 other than a MANET interface, will see the MANET router as it would 152 see any other IP router. For example, in Figure 2 the hosts 153 connected to the MANET router via the Ethernet link will simply 154 perceive an Ethernet link with hosts and a router, oblivious to if 155 the router is a MANET router or not. 157 \ | / 158 \|/ ------- MANET Interface(s) 159 | 160 +---+----+ 161 | | 162 | Manet | 163 | Router | 164 | | 165 +--------+ 166 | 167 | ------- Ethernet Interface 168 | 169 +-----------------------+ 170 | | | | 171 +---+ +---+ +---+ +---+ 172 | H | | H | | H | | H | 173 +---+ +---+ +---+ +---+ 175 Figure 2: MANET Router with Hosts on an Ethernet 177 Isolated by an IP hop, hosts on the Ethernet link in Figure 2 are not 178 exposed to the particularities of the MANET Link Type - similarly to 179 how, say, hosts on an Ethernet connected to an OSPF router with NBMA 180 interfaces are not exposed to the particularities of the NBMA Link 181 Type. 183 4. MANET Interfaces 185 An interface is, according to [RFC4862], "a node's attachment to a 186 link", indicating that an interface is a unique point of attachment 187 to a single link. It therefore follows that a MANET interface is a 188 MANET routers point of attachment to a MANET Link. 190 A MANET interface is often a wireless broadcast interface, as 191 illustrated in Figure 3, in which 5 MANET interfaces are connected to 192 the same MANET link and form a simple MANET. If these MANET 193 interfaces are wireless broadcast interfaces, their transmission 194 range is limited, as indicated. 196 -------+------- ---+------- Transmission 197 ------+------- -------+------- -------+------- Ranges 199 \|/ \|/ \|/ \|/ \|/ 200 | | | | | 201 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 202 | A | | B | | C | | D | | E | 203 +---+ +---+ +---+ +---+ +---+ 205 Figure 3: MANET Interface Transmission Ranges 207 In this simple network, a transmission by the node C reaches only 208 nodes B and D on the MANET link, due to the limited transmission 209 range of the wireless broadcast interface. Similarly, a transmission 210 from node B reaches only nodes A and C and a transmission by node D 211 reaches only node E - the latter might be due to environmental 212 interference or obstacles, transmission power levels or antenna 213 properties of node C or D (e.g. directional antennas on either or 214 both of C and D). 216 Note that the "Ethernet-like" interface characteristics that are 217 usually assumed, where all Ethernet interfaces on the same link can 218 reach each other, is a special case of this; and an Ethernet 219 interface would be a perfectly acceptable MANET interface. 221 This example in Figure 3 exhibits some of the characteristics of a 222 MANET Link: connectivity on a link can not be assumed to be 223 symmetric, nor can it be assumed to be transitive. These MANET Link 224 Type characteristics are detailed in Section 6. 226 5. MANET Network Dynamics 228 In a MANET, the set of participating MANET routers may change, 229 possibly frequently, over time, as can the relative position of the 230 MANET routers change as the network evolves. More specifically, the 231 set of MANET interfaces attached to a given MANET Link may change 232 over time, and a MANET interface may change its position on a MANET 233 Link, which may change the set of neighbors of that MANET interface. 234 The simple network in Figure 3 may evolve over time, as illustrated 235 in Figure 4, where at time t1 node A disappears from the MANET Link 236 and node C and D moves out of radio range from each other and are no 237 longer able to communicate. At time t2, node F appears on the MANET 238 Link, at a position where nodes C and D are within its radio range. 240 The set of MANET interfaces which can be reached by a transmission 241 from any MANET interface on the MANET Link may therefore also change 242 over time. In particular, the ability for a MANET interface to 243 receive a transmission from another MANET interface on the same MANET 244 Link and at a given point in time does not necessarily indicate that 245 such is also possible in the future. 247 -------+------- ---+------- 248 ------+------- -------+------- -------+------- 250 \|/ \|/ \|/ \|/ \|/ 251 | | | | | 252 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ t0 253 | A | | B | | C | | D | | E | 254 +---+ +---+ +---+ +---+ +---+ 256 -------+------- ---+------- 257 ------+------- -------+------- 259 \|/ \|/ \|/ \|/ 260 | | | | 261 +-+-+ +-+-+ +-+-+ +-+-+ t1 262 | B | | C | | D | | E | 263 +---+ +---+ +---+ +---+ 265 -------+------- ---+------- 266 ------+------- -------+------- -------+------- 268 \|/ \|/ \|/ \|/ \|/ 269 | | | | | 270 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ t2 271 | B | | C | | F | | D | | E | 272 +---+ +---+ +---+ +---+ +---+ 274 Figure 4: MANET Network Dynamics 276 6. The MANET Link Type 278 [Thaler] enumerates a set of properties, which are commonly assumed 279 by applications and upper layer protocols, and notes that these 280 assumptions are becoming increasingly less true. The MANET Link Type 281 is an example of a Link Type which challenges these assumptions. 283 The MANET Link Type characteristics can be summarized as follows: 285 o connectivity can not be assumed to be symmetric within a MANET 286 Link; 288 o connectivity can not be assumed to be transitive within a MANET 289 Link; 291 o connectivity can not be assumed to be continuous within a MANET 292 Link; 294 o the point of attachment to a MANET Link determines the view of 295 that MANET link; 297 o multicast and broadcast can not be assumed to work across a MANET 298 Link; 300 o a subnet is smaller than a MANET Link; 302 o addresses can not be assumed to be part of an on-link subnet on a 303 MANET Link. 305 It is important to note that the MANET Link Type is non-prescriptive, 306 i.e. it does not *require* a link to have these characteristics in 307 order for MANET protocols to operate correctly over it, however 308 protocols designed for the MANET Link Type are *required* to be able 309 to operate correctly also when presented with these link 310 characteristics. 312 This, in particular, entails that for example an Ethernet would be 313 perfectly acceptable as a MANET Link and that MANET protocols would 314 operate correctly when presented with an Ethernet. 316 6.1. Connectivity: Symmetry, Transitivity, Continouity ? 318 As indicated in Section 4, MANET interfaces on a MANET Link may not 319 all be neighbors, i.e. may not be able to communicate directly 320 between each other without intermediate retransmissions, 321 specifically: 323 o node A being a neighbor of node B does not necessarily imply that 324 node B is also a neighbor of node A; 326 o node A being a neighbor of nodes B and C does not necessarily 327 imply that nodes B and C are neighbors. 329 Furthermore, as indicated in Section 5, neighbors may change over, 330 specifically: 332 o the ability for a MANET interface to receive a transmission from 333 another MANET interface on the same MANET Link and at a given 334 point in time does not necessarily indicate that such is also 335 possible in the future. 337 6.2. Subnet Model and Addresses 339 [Thaler] observes that "a subnet is smaller than, or equal to a 340 link", specifically that "destinations with addresses in the same 341 subnet can be reached with TTL (or Hop Count) = 1". On a MANET Link, 342 a transmission with TTL (or Hop Count) = 1 can be received only by 343 MANET interfaces which are neighbors of the sending MANET interface. 345 The first observation is, that "subnet", "reachability without 346 decrementing TTL" and "addresses within a subnet" are intimately 347 related, and assume that "all interfaces with addresses within the 348 same subnet are neighbors". 350 -------+------- ---+------- Transmission 351 ------+------- -------+------- -------+------- Ranges 353 \|/ \|/ \|/ \|/ \|/ 354 | | | | | 355 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 356 | A | | B | | C | | D | | E | 357 +---+ +---+ +---+ +---+ +---+ 359 Figure 5: MANET Subnet Challenge 361 Considering node C on the MANET Link as depicted in Figure 5, this 362 router can reach the MANET interfaces of node B and D in a single 363 transmission and with a TTL (or Hop Count) = 1. Nodes B, C and D 364 could, therefore, be candidates for belonging to the same subnet. 365 However a transmission by node B can not reach node D without being 366 retransmitted by node C and so a transmission from node B with a TTL 367 (or Hop Count) = 1 will not reach node D. Furthermore, due to the 368 limited transmission range of node D, node D can reach neither of 369 nodes B and C -- and so, nodes B, C and D can not belong to the same 370 subnet. 372 This leads to the second observation, that the only set of addresses 373 which on a MANET Link can be guaranteed reachable in a single 374 transmission with TTL (or Hop count) = 1 are those of the 375 transmitting interface. The only addresses which can belong to the 376 same subnet on a MANET Link are, therefore, the addresses assigned to 377 the same MANET interface. 379 While the MANET interfaces of nodes B and C in Figure 5 may not be 380 configured with addresses from within the same subnet, these may 381 still communicate e.g. as point-to-point links where the two 382 endpoints have addresses from unrelated address spaces. 384 6.3. Multicast and Broadcast Scopes 386 IPv4 Limited Broadcast (255.255.255.255) and IPv4 and IPv6 Link Local 387 Multicast (FFx2::) are specified to not be forwarded [RFC3927] 388 [RFC4291] [RFC3330]. As a consequence, on a MANET Link: 390 o the scope within which a Limited Broadcast or a Link Local 391 Multicast transmission can be received is limited to that of the 392 transmitting MANET interface and its neighbors. 394 In other words, the broadcast and link local multicast scope of a 395 MANET interface on a MANET Link is the MANET interfaces which are 396 within transmission range. In figure Figure 6, the broadcast and 397 multicast scope of node C is, as indicated, the MANET interfaces of 398 nodes B and D; the broadcast and multicast scope of node D is the 399 MANET interface of node E. 401 ---+------- Multicast 402 -------+------- Scopes 404 \|/ \|/ \|/ \|/ \|/ 405 | | | | | 406 +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 407 | A | | B | | C | | D | | E | 408 +---+ +---+ +---+ +---+ +---+ 410 Figure 6: MANET Broadcast and Multicast Scope 412 Symmetrically, a broadcast or a link local multicast can be received 413 by any MANET interface within transmission range of the transmitter, 414 whether those are the receivers intended or not. Due to the fact 415 that connectivity can not be assumed to be symmetric, the transmitter 416 may not a priori know which MANET interfaces have received the 417 broadcast or link local multicast, nor can it be assumed that the 418 recipients a posteriori can signal that they received the broadcast 419 or link local multicast. 421 7. The MANET Addressing Architecture 423 This section presents an addressing architecture model for MANETs, 424 which preserves the integrity of the conventional IP addressing 425 architecture while allowing for the particularities of the MANET Link 426 Type. In particular, the applications and protocols running on hosts 427 are not exposed to a MANET Link. Only MANET interfaces of MANET 428 routers are required to be aware of the MANET Link Type, and to be 429 configured according to the characteristics of the MANET Link Type. 431 A MANET router is a router with at least one MANET interface towards 432 a MANET Link and, possibly, with zero or more other interfaces 433 towards other routers or hosts. The MANET router may, as any router 434 be delegated zero or more prefixes, which it may assign, integrally 435 or as subnet prefixes, to any links of its non-MANET interfaces, 436 which are configured accordingly. Hosts and routers on these non- 437 MANET interfaces may be assigned addresses from within these prefixes 438 according to the address (auto)configuration mechanisms governing 439 these (non-MANET) links, such as [RFC4862] and [RFC2131]. 441 Considering the example in Figure 7, the MANET router is delegated 442 the prefix p::/48. Subnet-prefixes p:1::/62, p:2::/62 and p:3::/63 443 from p::/48 are derived and assigned to the non-MANET links. 444 Interfaces on these links are configured with addresses from within 445 the subnet prefix of that link, as usual. 447 M 448 A 449 \ | / N 450 \|/ ------- MANET Interface(s) E 451 | T 452 +- --+--- -+ 453 | | 454 Manet | p::/48 455 .........................| Router |.............................. 456 | | 457 +- ------ -+ N 458 p:1::/62 | | | p:3::/62 o 459 +-------+-------+-------+ | +-------+-------+-------+ n 460 | | | | | | | | | | 461 +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ M 462 | H | | H | | H | | H | | | H | | H | | H | | H | A 463 +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ N 464 | E 465 -------------+---------------- T 466 p:2::/62 468 Figure 7: MANET Router and Prefixes Example 470 The configuration of MANET interface(s) of the MANET router requires 471 special attention, and is detailed in Section 7.1. 473 7.1. MANET Interface Configuration 475 As described in Section 6.2, on a MANET Link the only addresses which 476 can be guaranteed to be reachable with TTL (or Hop Count) = 1, and 477 therefore can be admitted to be within the same subnet, are the 478 addresses assigned to the sending MANET interface. Consequently, 479 MANET interfaces must be configured such that: 481 o no two MANET interfaces appear within the same subnet, i.e. with 482 the same prefix and prefix length. 484 This can be, and is commonly, accomplished by configuring MANET 485 interfaces with a /32 (IPv4) or a /128 (IPv6) address, e.g. as an 486 unnumbered interface, borrowing a single IP address from a non-MANET 487 interface of the MANET router. 489 It is worth noting that prefix lengths shorter than /128 (IPv6) or 490 /32 (IPv4) are possible on MANET interfaces, as long as the prefixes 491 are unique to a single MANET interface. Note that the above 492 statements are not an exception, but simply a clarification that 493 MANET are no different from other networks in this respect. 495 7.2. MANET Addressing Architecture Characteristics 497 The MANET addressing architecture presented in this section makes a 498 clear separation between the role of MANET router and host in a 499 MANET, recognizing that: 501 o MANET Link Type characteristics are only exposed to MANET 502 interfaces of MANET-aware routers, running appropriate protocols; 504 o routers and hosts, and more generally networks/subnets, on non- 505 MANET interface(s) are not subject to the particularities of the 506 MANET Link Type but are isolated herefrom by an IP hop; 508 o applications and protocols on hosts and routers, and more 509 generally networks/subnets, on non-MANET interfaces run 510 unmodified. 512 Note that this addressing architecture is similar to how routing in 513 the existing Internet is structured. Routers run their routing 514 protocol over router interconnects with various characteristics to 515 which only the routing protocols are privy. On the other hand, hosts 516 connect to routers over interfaces with well-defined characteristics. 518 8. Security Considerations 520 This document does not currently present any security considerations. 522 9. IANA Considerations 524 This document does not have any IANA actions 526 10. Informative References 528 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 529 RFC 2131, March 1997. 531 [RFC3330] IANA, IANA., "Special-Use IPv4 Addresses", RFC 3330, 532 September 2002. 534 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 535 Demand Distance Vector (AODV) Routing", RFC 3561, 536 July 2003. 538 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 539 Routing Protocol", RFC 3626, October 2003. 541 [RFC3684] Ogier, R., Templin, f., and M. Lewis, "Topology 542 Dissemination Based on Reverse-Path Forwarding", RFC 3684, 543 February 2004. 545 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 546 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 547 IPv4", RFC 4728, February 2007. 549 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 550 Configuration of IPv4 Link-Local Addresses", RFC 3927, 551 May 2005. 553 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 554 Architecture", RFC 4291, February 2006. 556 [RFC4862] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless 557 Address Autoconfiguration", RFC 4862, September 2007. 559 [Thaler] Thaler, D., "Evolution of the IP Model", Work In 560 Progress draft-thaler-ip-model-evolution-01.txt, 561 July 2008. 563 Appendix A. Acknowledgments 565 This document is greatly inspired from discussions with Dave Thaler 566 (Microsoft), Jari Arkko (Ericsson), Mark Townsley (Cisco), Ian 567 Chakeres (Motorola). 569 Christopher Dearlove (BAE Systems) and Emmanuel Baccelli (INRIA) both 570 provided reviews and insightful comments on early iterations of this 571 text. 573 Author's Address 575 Thomas Heide Clausen 576 LIX, Ecole Polytechnique, France 578 Phone: +33 6 6058 9349 579 EMail: T.Clausen@computer.org 580 URI: http://www.thomasclausen.org/ 582 Full Copyright Statement 584 Copyright (C) The IETF Trust (2008). 586 This document is subject to the rights, licenses and restrictions 587 contained in BCP 78, and except as set forth therein, the authors 588 retain all their rights. 590 This document and the information contained herein are provided on an 591 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 592 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 593 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 594 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 595 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 596 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 Intellectual Property 600 The IETF takes no position regarding the validity or scope of any 601 Intellectual Property Rights or other rights that might be claimed to 602 pertain to the implementation or use of the technology described in 603 this document or the extent to which any license under such rights 604 might or might not be available; nor does it represent that it has 605 made any independent effort to identify any such rights. Information 606 on the procedures with respect to rights in RFC documents can be 607 found in BCP 78 and BCP 79. 609 Copies of IPR disclosures made to the IETF Secretariat and any 610 assurances of licenses to be made available, or the result of an 611 attempt made to obtain a general license or permission for the use of 612 such proprietary rights by implementers or users of this 613 specification can be obtained from the IETF on-line IPR repository at 614 http://www.ietf.org/ipr. 616 The IETF invites any interested party to bring to its attention any 617 copyrights, patents or patent applications, or other proprietary 618 rights that may cover technology that may be required to implement 619 this standard. Please address the information to the IETF at 620 ietf-ipr@ietf.org.