idnits 2.17.1 draft-ietf-autoconf-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 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 (August 2007) is 6070 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 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 (==), 11 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: February 2, 2008 K. Mase 5 Niigata University 6 S. Ruffino 7 Telecom Italia 8 S. Singh 9 Samsung 10 August 2007 12 Address Autoconfiguration for MANET: Terminology and Problem Statement 13 draft-ietf-autoconf-statement-01 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 February 2, 2008. 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 . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 7 61 4.2. Existing Protocols' Shortcomings . . . . . . . . . . . . . 7 62 4.2.1. Lack of Multi-hop Support . . . . . . . . . . . . . . 7 63 4.2.2. Lack of Dynamic Topology Support . . . . . . . . . . . 8 64 4.2.3. Lack of Network Merging Support . . . . . . . . . . . 8 65 4.2.4. Lack of Network Partitioning Support . . . . . . . . . 9 66 4.3. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 9 67 4.3.1. Address and Prefix Generation . . . . . . . . . . . . 9 68 4.3.2. Prefix and Address Uniqueness Requirements . . . . . . 10 69 4.3.3. MANET Border Routers Related Issues . . . . . . . . . 10 70 5. Solutions Considerations . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Informative References . . . . . . . . . . . . . . . . . . . . 15 74 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 18 78 1. Introduction 80 A Mobile Ad hoc NETwork (also known as a MANET [2] [1]) consists of a 81 loosely connected set of MANET routers. Each MANET router embodies 82 IP routing/forwarding functionality and may also incorporate host 83 functionality. These routers dynamically self-organize and maintain 84 a routing structure among themselves, regardless of the availability 85 of a connection to any infrastructure. MANET routers may be mobile 86 and may communicate over symmetric or assymetric wireless links. 87 They may thus join and leave the MANET at any time. 89 However, prior to participation in IP communication, each MANET 90 router that does not benefit from appropriate static configuration 91 needs to automatically acquire at least one IP address, that may be 92 required to be unique within a given scope, or to be topologically 93 appropriate. 95 Standard automatic IPv6 address/prefix assignment solutions [5], [3] 96 [4] do not work "as-is" on MANETs due to ad hoc networks' unique 97 characteristics [2], therefore new or modified mechanisms are needed. 98 This document thus details and categorizes the issues that need to be 99 addressed. 101 2. Terminology 103 This document uses the MANET architecture terminology defined in [2], 104 as well as the following terms : 106 MANET Local address (MLA) - An IP address configured on an interface 107 of a router in a MANET and valid for communication inside this 108 MANET. 110 Global address - An IP address configured on a MANET router and 111 valid for communication with routers in the Internet, as well as 112 internally within the MANET. 114 Standalone MANET - An independent ad hoc network, which does not 115 contain a border router through which it is connected to the 116 Internet. 118 Network merger - The process by which two or more previously 119 disjoint ad hoc networks get connected. 121 Network partitioning - The process by which an ad hoc network splits 122 into two or more disconnected ad hoc networks. 124 Address generation - The process of selecting a tentative address in 125 view to configure an interface. 127 Address assignment - The process of configuring a generated address 128 on an interface. 130 Pre-service address uniqueness - The property of an address which is 131 assigned at most once within a given scope, and which is unique, 132 before it is being used. 134 In-service address uniqueness - The property of an address which was 135 assigned at most once within a given scope, and which remains 136 unique over time, after the address has started being used. 138 3. Deployment Scenarios 140 Automatic configuration of IP addresses and/or prefixes on MANET 141 interfaces is necessary in a number of deployment scenarios. This 142 section outlines the different categories of scenarios that are 143 considered. 145 3.1. Standalone MANET 147 Standalone MANETs are not connected to any external network: all 148 traffic is generated by routers and hosts in the MANET and destined 149 to routers or hosts in the same MANET. 151 Routers joining a standalone MANET may either have (i) no previous 152 configuration, or (ii) pre-configured local or global IP addresses 153 (or prefixes). Due to potential network partitions and mergers, 154 standalone MANETs may be composed of routers of either types. 156 Typical instances of this scenario include private or temporary 157 networks, set-up in areas where neither wireless coverage nor network 158 infrastructure exist (e.g. emergency networks for disaster recovery, 159 or conference-room networks). 161 3.2. Connected MANET 163 Connected MANETs have, contrary to standalone MANETs, connectivity to 164 one or more external networks (leaf networks, or other networks that 165 provide Internet connectivity) by means of one or more MANET border 166 router [2]. MANET routers may generate traffic destined to remote 167 hosts across these external networks, as well as to destination 168 inside the MANET. 170 Again, routers joining a connected MANET may either (i) have no 171 previous configuration, or (ii) already own pre-configured local or 172 global IP addresses (or prefixes). 174 Typical instances of this scenario include public wireless networks 175 of scattered fixed WLAN Access Points participating in a MANET of 176 mobile users, and acting as MANET border routers. Another example of 177 such a scenario is coverage extension of a fixed wide-area wireless 178 network, where one or more mobile routers in the MANET are connected 179 to the Internet through technologies such as UMTS or WiMAX. 181 3.3. Deployment Scenarios Selection 183 Both "Standalone MANET" and "Connected MANET" scenarios are to be 184 addressed by solutions for MANET autoconfiguration. Note that 185 solutions should also aim at addressing cases where a MANET transits 186 from one scenario to an other. 188 4. Problem Statement 190 This section details the goals of MANET autoconfiguration, and 191 highlights the shortcomings of existing autoconfiguration protocols. 192 A taxonomy of autoconfiguration issues on MANETs is then elaborated. 194 4.1. MANET Autoconfiguration Goals 196 A MANET router needs to configure IP addresses and/or prefixes on its 197 non-MANET interfaces. In addition, it needs to configure a link 198 local address, a /128 and/or an MLA on its MANET interface. A MANET 199 router may also configure a IP prefix shorter than /128 on its MANET 200 interface, provided prefix uniqueness is guaranteed [2]. 202 The primary goal of MANET autoconfiguration is thus to provide 203 mechanisms for IPv6 prefix allocation and address assignment, that 204 are suited for mobile ad hoc environments. Note that this task is 205 distinct from that of propagating knowledge about address or prefix 206 location, as a routing protocol does (see for example [8], [9]), or 207 as described in [7]. 209 The mechanisms employed by solutions to be designed must address the 210 distributed, multi-hop nature of MANETs [2], and be able to follow 211 topology and connectivity changes by (re)configuring addresses and/or 212 prefixes accordingly. 214 4.2. Existing Protocols' Shortcomings 216 Traditional dynamic IP address assignment protocols, such as [5], [3] 217 or [4], do not work as-is on MANETs due to these networks' unique 218 properties. This section overviews the shortcomings of these 219 solutions in mobile ad hoc environments. 221 4.2.1. Lack of Multi-hop Support 223 Traditional solutions assume that a broadcast directly reaches every 224 router or host on the subnetwork, whereas this generally is not the 225 case in MANETs (see [2]). Some routers in the MANET will typically 226 assume multihop broadcast, and expect to receive through several 227 intermediate relayings by peer MANET routers. For example, in Fig. 228 1, the MANET router MR3 cannot communicate directly with a DHCP 229 server [4] that would be available through a MANET border router, 230 since the server and the MANET router are not located on the same 231 logical link. While some DHCP extensions (such as the relay-agent 232 [11]) overcome this issue in a static network, it is not the case in 233 a dynamic topology, as explained below. 235 ----- MR1...MR3 236 / . 237 +-------------+ +------------+ / . 238 | | p2p | MANET |/ . 239 | ISP Edge | Link | Border | . 240 | Router +---------+ Router |\ . 241 | | | | \ . 242 +-------------+ +------------+ \----- MR2 244 Fig. 1. Connected MANET router topology. 246 4.2.2. Lack of Dynamic Topology Support 248 A significant proportion of the routers in the MANET may be mobile 249 with wireless interface(s), leading to ever changing neighbor sets 250 for most MANET routers (see [1]). Therefore, network topology may 251 change rather dynamically compared to traditional networks, which 252 invalidates traditional delegation solutions that were developed for 253 infrastructure-based networks, such as [11], which do not assume 254 intermittent reachability of configuration server(s), and a 255 potentially ever changing hierarchy among devices. For instance, in 256 Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with 257 DHCP [4], it cannot be assumed that MR1 and MR3 will not move and 258 become unable to communicate directly. 260 4.2.3. Lack of Network Merging Support 262 Network merging is a potential event that was not considered in the 263 design of traditional solutions, and that may greatly disrupt the 264 autoconfiguration mechanisms in use (see [2]). Examples of network 265 merging related issues include cases where a MANET A may feature 266 routers and hosts that use IP addresses that are locally unique 267 within MANET A, but this uniqueness is not guaranteed anymore if 268 MANET A merges with another MANET B. If address uniqueness is 269 required within the MANET (see Section 4.3.2), issues arise that were 270 not accounted for in traditional networks and solutions. For 271 instance, [5] and [3] test address uniqueness via messages that are 272 sent to neighbors only, and as such cannot detect the presence of 273 duplicate addresses configured within the network but located several 274 hops away. However, since MANETs are generally multi-hop, detection 275 of duplicate addresses over several hops is a feature that may be 276 required for MANET interface address assignment (see Section 4.3.2). 278 4.2.4. Lack of Network Partitioning Support 280 Network partitioning is a potential event that was not considered in 281 the design of traditional solutions, and that may invalidate usual 282 autoconfiguration mechanisms (see [2]). Examples of related issues 283 include cases such as a standalone MANET, whereby connection to the 284 infrastructure is not available, possibly due to network partitioning 285 and loss of connectivity to a MANET border router. The MANET must 286 thus function without traditional address allocation server 287 availability. While stateless protocols such as [5] and [3] could 288 provide IP address configuration (for MANET interfaces, loopback 289 interfaces), these solutions do not provide any mechanism for 290 allocating "unique prefix(es)" to routers in order to enable the 291 configuration of host interfaces. 293 ----- MR1...MR3...MR5 294 / . 295 / . 296 / . 297 MR4 . 298 \ . 299 \ . 300 \----- MR2 302 Fig. 2. Standalone MANET router topology. 304 4.3. MANET Autoconfiguration Issues 306 Taking into account the shortcomings of traditional solutions, this 307 section categorizes general issues with regards to MANET 308 autoconfiguration. 310 4.3.1. Address and Prefix Generation 312 The distributed nature of MANETs brings the need for address 313 generation algorithms that are not always based on traditional 314 "client-server" schemes and hierarchies to provide MANET routers with 315 addresses and prefixes. In addition, the multi-hop aspect of mobile 316 ad hoc networking makes it difficult to totally avoid address and 317 prefix duplication a priori over all the MANET. 319 4.3.2. Prefix and Address Uniqueness Requirements 321 If prefix or address uniqueness is required within a specific scope, 322 and if the address/prefix generation mechanism in use does not 323 totally avoid address/prefix duplication, then additional issues 324 arise. This section overviews these problems. 326 Pre-service Issues -- One category of problems due to address or 327 prefix uniqueness requirements are called pre-service issues. 328 Conceptually, they relate to the fact that before a generated address 329 or prefix is assigned and used, it should be verified that it will 330 not create an address conflict within the specified scope. This is 331 essential in the context of routing, where it is desireable to reduce 332 the risks of loops due to routing table pollution with duplicate 333 addresses. 335 In-Service Issues -- Another category of problems due to address and 336 prefix uniqueness are called in-service issues. They come from the 337 fact that even if an assigned address or prefix is currently unique 338 within the specified scope, it cannot be ensured that it will indeed 339 remain unique over time. 341 Phenomena such as MANET merging and MANET partitioning may bring the 342 need for checking the uniqueness (within the specified scope) of 343 addresses or prefixes that are already assigned and used. This need 344 may depend on (i) the probability of address conflicts, (ii) the 345 amount of the overhead for checking uniqueness of addresses, and 346 (iii) address/prefix uniqueness requirements from applications. 348 For instance, if (i) is extremely low and (ii) significant, checking 349 uniqueness of addresses and prefixes may not be used. If on the 350 other hand (i) is not extremely low, checking uniqueness of addresses 351 and prefixes should be used. In any case, if the application has a 352 hard requirement for address uniqueness assurance, checking 353 uniqueness of addresses and prefixes should always be used, no matter 354 how unlikely is the event of address conflict. 356 4.3.3. MANET Border Routers Related Issues 358 Another category of problems concern MANET border router(s) 359 management. 361 In the case where multiple MANET border routers are available in the 362 MANET, providing access to multiple address configuration servers, 363 specific problems arise. One problem is the way in which global 364 prefixes are managed within the MANET. If one prefix is used for the 365 whole MANET, partitioning of the MANET may result in invalid routes 366 towards MANET routers, over the Internet. On the other hand, the use 367 of multiple network prefixes guarantees traffic is unambiguously 368 routed from the hosts/routers in the Internet towards the MANET 369 border router responsible for one particular prefix. However, 370 asymmetry in the routers' choice of ingress/egress MANET border 371 router can lead to non-optimal paths followed by inbound/outbound 372 data traffic, or to broken connectivity, if egress filtering is being 373 done. 375 When a device changes its MANET border router attachment, some routes 376 may be broken, affecting MANET packet forwarding performance and 377 applications. In a multiple border router / multiple-prefixes MANET, 378 frequent reconfiguration could cause a large amount of control 379 signalling (for instance if [5] is used "as-is"). 381 5. Solutions Considerations 383 Solutions must achieve their task with (i) low overhead, due to 384 scarse bandwidth, and (ii) low delay/convergence time, due to the 385 dynamicity of the topology. The evaluation of such criteria may 386 depend on the targeted network properties, which include (but are not 387 limited to) node cardinality, node mobility characteristics, etc. 389 Solutions are to be designed to work at the network layer and thus to 390 apply to all link types. However, in situations where link-layer 391 multicast is needed it is possible that on some link types (e.g. 392 NBMA links), alternative mechanisms or protocols specifying operation 393 over a particular link type would be required. 395 Solutions must interact with existing protocols in a way that 396 leverages as much as possible appropriate mechanisms that are 397 deployed. For instance, besides the possible use of the well-known 398 IPv6 multicast addresses defined for neighbor discovery in [3] (e.g. 399 for Duplicate Address Detection), solutions may as well use some 400 addresses defined in [10] for auto-configuration purposes. 402 Solutions must also take into account the security and trust issues 403 that are specific to ad hoc networking (see Section 6). 405 6. Security Considerations 407 Address configuration in MANET could be prone to security attacks, as 408 in other types of IPv6 networks. Security threats to IPv6 neighbor 409 discovery were discussed in SEND WG and described in [6]: three 410 different trust models are specified, with varying levels of trust 411 among network nodes and routers. Among them, the model by which no 412 trust exists among nodes may be suitable a priori for most ad hoc 413 networks. However, the other two models may be applicable in some 414 cases, for example when a trust relationship exists between an 415 operator and some MANET routers, or between military devices that are 416 in the same unit. Although [6] does not explicitly address MANETs, 417 the trust models it provides for ad hoc networks can be valid also in 418 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 7. IANA Considerations 440 This document does currently not specify IANA considerations. 442 8. 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, C. 483 Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins, 484 A. Petrescu, P. Ruiz, P. 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).