idnits 2.17.1 draft-ietf-autoconf-statement-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 18, 2007) is 6157 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 106 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '3') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '5') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2740 (ref. '9') (Obsoleted by RFC 5340) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) 3 Internet-Draft INRIA 4 Expires: December 20, 2007 K. Mase 5 Niigata University 6 S. Ruffino 7 Telecom Italia 8 S. Singh 9 Samsung 10 June 18, 2007 12 Address Autoconfiguration for MANET: Terminology and Problem Statement 13 draft-ietf-autoconf-statement-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 20, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 Traditional dynamic IPv6 address assignment solutions are not adapted 47 to mobile ad hoc networks. This document elaborates on this problem, 48 states the need for new solutions, and requirements to these 49 solutions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Connected MANET . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 5 59 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 6 61 4.2. Existing Solutions' Shortcomings . . . . . . . . . . . . . 6 62 4.2.1. Lack of Multi-hop Support . . . . . . . . . . . . . . 7 63 4.2.2. Lack of Dynamic Topology Support . . . . . . . . . . . 7 64 4.2.3. Lack of Network Merging Support . . . . . . . . . . . 7 65 4.2.4. Lack of Network Partitionning Support . . . . . . . . 8 66 4.3. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 8 67 4.3.1. Address and Prefix Generation . . . . . . . . . . . . 9 68 4.3.2. Address Uniqueness Requirements . . . . . . . . . . . 9 69 4.3.3. MANET Border Routers Related Issues . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Informative References . . . . . . . . . . . . . . . . . . . . 13 73 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . . . . 16 77 1. Introduction 79 A Mobile Ad hoc NETwork (also known as a MANET [2] [1]) consists of a 80 loosely connected set of MANET routers. Each MANET router embodies 81 IP routing/forwarding functionality and may also incorporate host 82 functionality. These routers dynamically self-organize and maintain 83 a routing structure among themselves, regardless of the availability 84 of a connection to any infrastructure. MANET routers may be mobile 85 and may communicate over symmetric or assymetric wireless links. 86 They may thus join and leave the MANET at any time. 88 However, prior to participation in IP communication, each MANET 89 interface that does not benefit from appropriate static configuration 90 needs to automatically acquire at least one IP address, that may be 91 required to be unique within a given scope. 93 Standard automatic IPv6 address/prefix assignment solutions [5], [3] 94 [4] do not work "as-is" on MANETs due to ad hoc networks' unique 95 characteristics [2], and new mechanisms are therefore needed. This 96 document thus details and categorizes the issues that need to be 97 addressed. 99 2. Terminology 101 In this document, several words are used to signify the requirements 102 of the specification. These words are often capitalized. The key 103 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 104 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 105 are to be interpreted as described in [RFC2119]. 107 In addition, this document uses the MANET architecture terminology 108 defined in [2], as well as the following terms : 110 Local address - An IP address configured on an interface of a router 111 in a MANET and valid for communication inside this MANET. A local 112 address MUST NOT be used for communication including routers 113 outside the MANET. 115 Global address - An IP address configured on a MANET router and 116 valid for communication with routers in the Internet, as well as 117 internally within the MANET. 119 Standalone MANET - An independent ad hoc network, which does not 120 contain a border router through which it is connected to the 121 Internet. 123 Network merger - The process by which two or more previously 124 disjoint ad hoc networks get connected. 126 Network partitioning - The process by which an ad hoc network splits 127 into two or more disconnected ad hoc networks. 129 Address generation - The process of selecting a tentative address in 130 view to configure an interface. 132 Address assignment - The process of configuring a generated address 133 on an interface. 135 Pre-service address uniqueness - The property of an address which is 136 assigned at most once at this given point in time, within a given 137 scope. 139 In-service address uniqueness - The property of an address which was 140 assigned at most once within a given scope, and which remains 141 unique over time, as the address is being used. 143 3. Deployment Scenarios 145 Automatic configuration of IP addresses and/or prefixes on MANET 146 interfaces is necessary in a number of deployment scenarios. This 147 section outlines the different categories of scenarios that are 148 considered. 150 3.1. Standalone MANET 152 Standalone MANETs are not connected to any external network: all 153 traffic is generated by MANET nodes and destined to nodes in the same 154 MANET. 156 Routers joining a standalone MANET may either have (i) no previous 157 configuration, or (ii) pre-configured local or global IP addresses 158 (or prefixes). Due to potential network partitions and mergers, 159 standalone MANETs may be composed of routers of either either types. 161 Typical instances of this scenario include private or temporary 162 networks, set-up in areas where neither wireless coverage nor network 163 infrastructure exist (e.g. emergency networks for disaster recovery, 164 or conference-room networks). 166 3.2. Connected MANET 168 Connected MANETs have, contrary to standalone MANETs, connectivity to 169 one or more external networks, typically the Internet, by means of 170 one or more MBR (Manet Border Router, see [2]). MANET routers may 171 generate traffic destined to remote hosts accross these external 172 networks, as well as to destination inside the MANET. 174 Again, routers joining a connected MANET may either (i) have no 175 previous configuration, or (i) already own pre-configured local or 176 global IP addresses (or prefixes). 178 Typical instances of this scenario include public wireless networks 179 of scattered fixed WLAN Access Points participating in a MANET of 180 mobile users, and acting as MBRs. Another example of such a scenario 181 is coverage extension of a fixed wide-area wireless network, where 182 one or more mobile routers in the MANET are connected to the Internet 183 through technologies such as UMTS or WiMAX. 185 3.3. Deployment Scenarios Selection 187 Both "Standalone MANET" scenario and "Connected MANET" scenarii are 188 to be addressed by solutions for MANET autoconfiguration. 190 4. Problem Statement 192 This section details the goals of MANET autoconfiguration, and 193 highlights the shortcomings of existing autoconfiguration solutions. 194 A taxonomy of autoconfiguration issues on MANETs is then elaborated. 196 4.1. MANET Autoconfiguration Goals 198 A MANET router needs to configure an IPv6 prefix(es) on its host 199 interface and/or an IPv6 address on its loopback interface. Besides, 200 it needs to configure a /128 and/or a link local address on its MANET 201 interface. A MANET router may also configure a prefix shorter than 202 /128 on its MANET interface provided prefix uniqueness is guaranteed 203 [2]. 205 The primary goal of MANET autoconfiguration is thus to provide 206 mechanisms for IPv6 prefix allocation and address assignment, that 207 are suited for mobile ad hoc environments. Note that this task is 208 namely distinct from that of just vehiculing knowledge about address 209 or prefix location such as a routing protocol does (see for example 210 [8], [9]), or such as described in [7]. 212 The mechanisms employed by solutions to be designed must address the 213 distributed, multi-hop nature of MANETs [2], and be able to follow 214 topology and connectivity changes by (re)configuring addresses and/or 215 prefixes accordingly. 217 Solutions must achieve their task with (i) low overhead, due to 218 scarse bandwidth, and (ii) low delay, due to the dynamicity of the 219 topology. Solutions are designed to work at the network layer and 220 thus applies to all link types. However, in situations where link- 221 layer multicast is needed it is possible that on some link types 222 (e.g. NBMA links), alternative mechanisms or protocols specifying 223 operation over a particular link type would be required. 225 Besides the possible use of the well-known IPv6 multicast addresses 226 defined for neighbor discovery in [3] (e.g. for Duplicate Address 227 Detection), solutions may also use some addresses defined in [10] for 228 auto-configuration purposes. 230 4.2. Existing Solutions' Shortcomings 232 Traditional dynamic IP address assignment solutions, such as [5], [3] 233 or [4], do not work as-is on MANETs due to these networks' unique 234 properties. This section overviews the shortcomings of these 235 solutions in mobile ad hoc environments. 237 4.2.1. Lack of Multi-hop Support 239 Traditional solutions assume that a broadcast directly reaches every 240 router or host on the subnetwork, whereas this generally is not the 241 case in MANETs (see [2]). Some routers in the MANET will typically 242 assume multihop broadcast, and expect to receive through several 243 intermediate relayings by peer MANET routers. For example, in Fig. 244 1, the MANET router MR3 cannot communicate directly with a DHCP 245 server [4] that would be available through an MBR, since the server 246 and the MANET router are not located on the same logical link. While 247 some DHCP extensions (such as the relay-agent [11]) overcome this 248 issue in a static network, it is not the case in a dynamic topology, 249 as explained below. 251 ----- MR1...MR3 252 / . 253 +-------------+ +------------+ / . 254 | | p2p | MANET |/ . 255 | ISP Edge | Link | Border | . 256 | Router +---------+ Router |\ . 257 | | | (MBR) | \ . 258 +-------------+ +------------+ \----- MR2 260 Fig. 1. Connected MANET router topology. 262 4.2.2. Lack of Dynamic Topology Support 264 A significant proportion of the routers in the MANET may be mobile 265 with wireless interface(s), leading to ever changing neighbor sets 266 for most MANET routers (see [1]). Therefore, network topology may 267 change rather dynamically compared to traditional networks, which 268 invalidates traditional delegation solutions that were developed for 269 infrastructure-based networks, such as [11], which assume the 270 existence of a permanent hierarchy among devices and the permanent 271 reachability of a configuration server. For instance, in Fig. 1, 272 even if MR1 would be able to delegate prefixes to MR3 with DHCP [4], 273 it cannot be assumed that MR1 and MR3 will not move and become unable 274 to communicate directly. 276 4.2.3. Lack of Network Merging Support 278 Network merging is a potential event that was not considered in the 279 design of traditional solutions, and that may greatly disrupt the 280 autoconfiguration mechanisms in use (see [2]). Examples of network 281 merging related issues include cases where a MANET A may feature 282 routers and hosts that use IP addresses that are locally unique 283 within MANET A, but this uniqueness is not guaranteed anymore if 284 MANET A merges with another MANET B. If address uniqueness is 285 required within the MANET (see Section 4.3.2), issues arise that were 286 not accounted for in traditional networks and solutions. 288 4.2.4. Lack of Network Partitionning Support 290 Network partinionning is a potential event that was not considered in 291 the design of traditional solutions, and that may invalidate usual 292 autoconfiguration mechanisms (see [2]). Examples of related issues 293 include cases such as a standalone MANET, whereby connection to the 294 infrastructure is not available, possibly due to network 295 partitnionning and loss of connectivity to an MBR. The MANET must 296 thus function without traditional server availability. While 297 stateless protocols such as [5] and [3] could provide IP address 298 configuration (for MANET interfaces, loopback interfaces), these 299 solutions do not provide any mechanism for allocating "unique 300 prefix(es)" to routers in order to enable the configuration of host 301 interfaces. Moreover, [5] and [3] test address uniqueness via 302 messages that are sent to neighbors only, and as such cannot detect 303 the presence of duplicate addresses configured within the network but 304 located several hops away. However, since MANETs are generally 305 multi-hop, detection of duplicate addresses over several hops is a 306 feature that is required in most cases of MANET interface address 307 assignment (see Section 4.3.2). 309 ----- MR1...MR3...MR5 310 / . 311 / . 312 / . 313 MR4 . 314 \ . 315 \ . 316 \----- MR2 318 Fig. 2. Standalone MANET router topology. 320 4.3. MANET Autoconfiguration Issues 322 Taking into account the shortcomings of traditional solutions, this 323 section categorizes general issues with regards to MANET 324 autoconfiguration. 326 4.3.1. Address and Prefix Generation 328 The distributed nature of MANETs brings the need for address 329 generation algorithms that are not always based on traditional 330 "client-server" schemes and hierarchies to provide MANET routers with 331 addresses and prefixes. In addition, the multi-hop aspect of mobile 332 ad hoc networking makes it difficult to totally avoid address and 333 prefix duplication a priori over all the MANET. 335 4.3.2. Address Uniqueness Requirements 337 If address uniqueness is required within a specific scope, and if the 338 address/prefix generation mechanism in use does not totally avoid 339 address/prefix duplication, then additional issues arise. This 340 section overviews these problems. 342 Pre-service Issues -- One category of problems due to address 343 uniqueness requirements are called pre-service issues. Conceptually, 344 they relate to the fact that before a generated address is assigned 345 and used, it should be verified that it will not create an address 346 conflict within the specified scope. This is essential in the 347 context of routing, where it is desireable to reduce the risks of 348 loops due to routing table pollution with duplicate addresses. 350 In-Service Issues -- Another category of problems due to address 351 uniqueness are called in-service issues. They come from the fact 352 that even if an assigned address is currently unique within the 353 specified scope, it cannot be ensured that it will indeed remain 354 unique over time. 356 Phenomena such as MANET merging and MANET partitionning can bring the 357 need for checking the uniqueness (within the specified scope) of 358 addresses that are already assigned and used, if in-service address 359 uniqueness is required. 361 The need for checking uniqueness of addresses that are to be assigned 362 or already assigned and used may depend on (i) the probability of 363 address conflicts, (ii) the amount of the overhead for checking 364 uniqueness of addresses, and (iii) address uniqueness requirements 365 from applications. 367 For instance, if (i) is extremely low and (ii) significant, checking 368 uniqueness of addresses may not be used. If on the other hand (i) is 369 not extremely low, checking uniqueness of addresses should be used. 370 In any case, if the application has a hard requirement for address 371 uniqueness assurance, checking uniqueness of addresses should always 372 be used, no matter how unlikely is the event of address conflict. 374 4.3.3. MANET Border Routers Related Issues 376 Another category of problems concern MBR management. 378 MBR Mobility -- Some addresses may be configured by servers available 379 through MBRs that may themselves be mobile and that may therefore 380 leave the MANET. In this case, global addresses used by routers in 381 the MANET may no longer be valid. 383 MBR Multiplicity -- In the case where multiple MBRs are available in 384 the MANET, providing access to multiple address configuration 385 servers, specific problems arise. One problem is the way in which 386 global prefixes are managed within the MANET. If one prefix is used 387 for the whole MANET, partitioning of the MANET may invalid routes in 388 the Internet towards MANET routers. On the other hand, use of 389 multiple network prefixes guarantees traffic is unambiguously routed 390 towards the MBR responsible for one particular prefix, but asymmetry 391 in the routers' choice of ingress/egress MBR can lead to non-optimal 392 paths followed by inbound/outbound data traffic. When a device 393 changes its MBR attachment, some routes may be broken, affecting 394 MANET packet forwarding performance and applications. 396 IPv6 Specifications -- Additional problems come from issues with 397 current IPv6 specifications. For example, the strict application of 398 [5] may lead to check every IPv6 unicast address for uniqueness: in a 399 multiple-MBR / multiple-prefixes MANET, this could bring to a large 400 amount of control signalling, due to frequent reconfiguration. 401 Moreover, IPv6 does not currently specify an address scope that is 402 appropriate to fit the scope of a MANET, which could lead to 403 undesireable behavior such as MBRs leaking MANET local traffic 404 outside the MANET. 406 5. Security Considerations 408 Address configuration in MANET could be prone to security attacks, as 409 in other types of IPv6 networks. Security threats to IPv6 neighbor 410 discovery were discussed in SEND WG and described in [6]: three 411 different trust models are specified, with varying levels of trust 412 among network nodes and routers. Among them, the model by which no 413 trust exists among nodes is considered most suitable for ad hoc 414 networks, although the other two models may also be applicable in 415 some cases, for example when a trust relationship exists between an 416 operator and some MANET routers. Although [6] does not explicitly 417 address MANETs, the trust models it provides for ad hoc networks can 418 be valid also in the context of MANET autoconfiguration. 420 It is worth noting that analysis of [6] is strictly related to 421 Neighbor Discovery, Neighbor Unreachability Detection and Duplicate 422 Address Detection procedures, as defined in [3] and [5]. As 423 explained in the present document, current standard procedures cannot 424 be used as-is in MANET context to achieve autoconfiguration of MANET 425 routers and, therefore, design of new mechanisms can be foreseen. 427 In this case, although security threats and attacks defined in [6] 428 could also apply in presence of new solutions, additional threats and 429 attacks could be possible (e.g., non-cooperation in message 430 forwarding in multi-hop communications). Therefore, the security 431 analysis has to be further extended to include threats, specific to 432 multi-hop networks and related to the particular address 433 configuration solution. 435 General security issues of ad hoc routing protocols' operations are 436 not in the scope of MANET autoconfiguration. 438 6. IANA Considerations 440 This document does currently not specify IANA considerations. 442 7. Informative References 444 [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance 445 Issues and Evaluation Considerations", RFC 2501, January 1999. 447 [2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc 448 Network Architecture", ID draft-ietf-autoconf-manetarch, 449 February 2007. 451 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 452 for IPv6", RFC 2461, December 1998. 454 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 455 Carney, "Dynamic Host Configuration Protocol for IPv6", 456 RFC 3315, July 2003. 458 [5] Narten, T. and S. Thomson, "IPv6 Stateless Address 459 Autoconfiguration", RFC 2462, December 1998. 461 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 462 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 464 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 465 Specific Routes", RFC 4191, 2005. 467 [8] Moy, J., "OSPF version 2", RFC 2328, 1998. 469 [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", 470 RFC 2740, 1999. 472 [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) 473 Allocations for the Mobile Ad hoc Networks (MANET) Working 474 Group", ID draft-ietf-manet-iana, May 2007. 476 [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 477 2001. 479 Contributors 481 This document is the result of joint efforts, including those of the 482 following contributers, listed in alphabetical order: C. Adjih, T. 483 Boot, T. Clausen, C. Dearlove, C. Perkins, A. Petrescu, P. Ruiz, P. 484 Stupar, F. Templin, D. Thaler, K. Weniger. 486 Authors' Addresses 488 Emmanuel Baccelli 489 INRIA 491 Phone: +33 1 69 33 55 11 492 Email: Emmanuel.Baccelli@inria.fr 494 Kenichi Mase 495 Niigata University 497 Phone: +81 25 262 7446 498 Email: Mase@ie.niigata-u.ac.jp 500 Simone Ruffino 501 Telecom Italia 503 Phone: +39 011 228 7566 504 Email: Simone.Ruffino@telecomitalia.it 506 Shubhranshu Singh 507 Samsung 509 Phone: +82 31 280 9569 510 Email: Shubranshu@gmail.com 512 Full Copyright Statement 514 Copyright (C) The IETF Trust (2007). 516 This document is subject to the rights, licenses and restrictions 517 contained in BCP 78, and except as set forth therein, the authors 518 retain all their rights. 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 523 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 524 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 525 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Intellectual Property 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed to 532 pertain to the implementation or use of the technology described in 533 this document or the extent to which any license under such rights 534 might or might not be available; nor does it represent that it has 535 made any independent effort to identify any such rights. Information 536 on the procedures with respect to rights in RFC documents can be 537 found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use of 542 such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository at 544 http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org. 552 Acknowledgment 554 Funding for the RFC Editor function is provided by the IETF 555 Administrative Support Activity (IASA).