idnits 2.17.1 draft-baccelli-autoconf-statement-03.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 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. 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 (April 3, 2007) is 6227 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 103 -- 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) 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: October 5, 2007 K. Mase 5 Niigata University 6 S. Ruffino 7 Telecom Italia 8 S. Singh 9 Samsung 10 April 3, 2007 12 Address Autoconfiguration for MANET: Terminology and Problem Statement 13 draft-baccelli-autoconf-statement-03 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 October 5, 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 . . . . . . . . . . . . . . 6 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 . . . . . . . . 7 66 4.3. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 8 67 4.3.1. Address and Prefix Generation . . . . . . . . . . . . 8 68 4.3.2. Address Uniqueness Requirements . . . . . . . . . . . 8 69 4.3.3. MANET Border Routers Related Issues . . . . . . . . . 9 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 Mobile ad hoc networks (also known as MANETs [2] [1]) are networks 80 composed of mobile devices that communicate over wireless media, 81 which dynamically self-organize multi-hop IP communication between 82 each other, and such regardless of the availability of a connection 83 to any infrastructure. 85 However, prior to participation in IP communication, each MANET 86 interface that does not benefit from appropriate static configuration 87 needs to automatically acquire at least one IP address, that may be 88 required to be unique within a given scope. 90 Standard automatic IPv6 address/prefix assignment solutions [5], [3] 91 [4] do not work "as-is" on MANETs due to ad hoc networks' unique 92 characteristics [2], and new mechanisms are therefore needed. This 93 document thus details and categorizes the issues that need to be 94 addressed. 96 2. Terminology 98 In this document, several words are used to signify the requirements 99 of the specification. These words are often capitalized. The key 100 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 101 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 102 are to be interpreted as described in [RFC2119]. 104 In addition, this document uses the MANET architecture terminology 105 defined in [2], as well as the following terms : 107 Local address - An IP address configured on an interface of a router 108 in a MANET and valid for communication inside this MANET. A local 109 address MUST NOT be used for communication including routers 110 outside the MANET. 112 Global address - An IP address configured on a MANET router and 113 valid for communication with routers in the Internet, as well as 114 internally within the MANET. 116 Standalone MANET - An independent ad hoc network, which does not 117 contain a border router through which it is connected to the 118 Internet. 120 Network merger - The process by which two or more previously 121 disjoint ad hoc networks get connected. 123 Network partitioning - The process by which an ad hoc network splits 124 into two or more disconnected ad hoc networks. 126 Address generation - The process of selecting a tentative address in 127 view to configure an interface. 129 Address assignment - The process of configuring a generated address 130 on an interface. 132 Pre-service address uniqueness - The property of an address which is 133 assigned at most once at this given point in time, within a given 134 scope. 136 In-service address uniqueness - The property of an address which was 137 assigned at most once within a given scope, and which remains 138 unique over time, as the address is being used. 140 3. Deployment Scenarios 142 Automatic configuration of IP addresses and/or prefixes on MANET 143 interfaces is necessary in a number of deployment scenarios. This 144 section outlines the different categories of scenarios that are 145 considered. 147 3.1. Standalone MANET 149 Standalone MANETs are not connected to any external network: all 150 traffic is generated by MANET nodes and destined to nodes in the same 151 MANET. 153 Routers joining a standalone MANET may either have (i) no previous 154 configuration, or (ii) pre-configured local or global IP addresses 155 (or prefixes). Due to potential network partitions and mergers, 156 standalone MANETs may be composed of routers of either either types. 158 Typical instances of this scenario include private or temporary 159 networks, set-up in areas where neither wireless coverage nor network 160 infrastructure exist (e.g. emergency networks for disaster recovery, 161 or conference-room networks). 163 3.2. Connected MANET 165 Connected MANETs have, contrary to standalone MANETs, connectivity to 166 one or more external networks, typically the Internet, by means of 167 one or more MBR (Manet Border Router, see [2]). MANET routers may 168 generate traffic destined to remote hosts accross these external 169 networks, as well as to destination inside the MANET. 171 Again, routers joining a connected MANET may either (i) have no 172 previous configuration, or (i) already own pre-configured local or 173 global IP addresses (or prefixes). 175 Typical instances of this scenario include public wireless networks 176 of scattered fixed WLAN Access Points participating in a MANET of 177 mobile users, and acting as MBRs. Another example of such a scenario 178 is coverage extension of a fixed wide-area wireless network, where 179 one or more mobile routers in the MANET are connected to the Internet 180 through technologies such as UMTS or WiMAX. 182 3.3. Deployment Scenarios Selection 184 Both "Standalone MANET" scenario and "Connected MANET" scenarii are 185 to be addressed by solutions for MANET autoconfiguration. 187 4. Problem Statement 189 This section details the goals of MANET autoconfiguration, and 190 highlights the shortcomings of existing autoconfiguration solutions. 191 A taxonomy of autoconfiguration issues on MANETs is then elaborated. 193 4.1. MANET Autoconfiguration Goals 195 A MANET router needs to configure an IPv6 prefix(es) on its host 196 interface and/or an IPv6 address on its loopback interface. Besides, 197 it needs to configure a /128 and/or a link local address on its MANET 198 interface. A MANET router may also configure a prefix shorter than 199 /128 on its MANET interface provided prefix uniqueness is guaranteed 200 [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. 206 These mechanisms must address the distributed, multi-hop nature of 207 MANETs [2], and be able to follow topology and connectivity changes 208 by (re)configuring addresses and/or prefixes accordingly. 210 Solutions must achieve their task with (i) low overhead, due to 211 scarse bandwidth, and (ii) low delay, due to the dynamicity of the 212 topology. 214 4.2. Existing Solutions' Shortcomings 216 Traditional dynamic IP address assignment solutions, 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 network, whereas this generally is not the case 225 in MANETs (see [2]). Some routers in the MANET will typically assume 226 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 an MBR. 231 ----- MR1...MR3 232 / . 233 +-------------+ +------------+ / . 234 | | p2p | MANET |/ . 235 | ISP Edge | Link | Border | . 236 | Router +---------+ Router |\ . 237 | | | (MBR) | \ . 238 +-------------+ +------------+ \----- MR2 240 Fig. 1. Connected MANET router topology. 242 4.2.2. Lack of Dynamic Topology Support 244 A significant proportion of the routers in the MANET may be mobile 245 with wireless interface(s), leading to ever changing neighbor sets 246 for most MANET routers (see [1]). Therefore, network topology may 247 change rather dynamically compared to traditional networks, which 248 invalidates traditional delegation solutions that were developed for 249 infrastructure-based networks, which assume the existence of a 250 permanent hierarchy among devices and the permanent reachability of a 251 configuration server. For instance, in Fig. 1, even if MR1 would be 252 able to delegate prefixes to MR3 with DHCP [4], it cannot be assumed 253 that MR1 and MR3 will not move and become unable to communicate 254 directly. 256 4.2.3. Lack of Network Merging Support 258 Network merging is a potential event that was not considered in the 259 design of traditional solutions, and that may greatly disrupt the 260 autoconfiguration mechanisms in use (see [2]). Examples of network 261 merging related issues include cases where a MANET A may feature 262 routers and hosts that use IP addresses that are locally unique 263 within MANET A, but this uniqueness is not guaranteed anymore if 264 MANET A merges with another MANET B. If address uniqueness is 265 required within the MANET (see Section 4.3.2), issues arise that were 266 not accounted for in traditional networks and solutions. 268 4.2.4. Lack of Network Partitionning Support 270 Network partinionning is a potential event that was not considered in 271 the design of traditional solutions, and that may invalidate usual 272 autoconfiguration mechanisms (see [2]). Examples of related issues 273 include cases such as a standalone MANET, whereby connection to the 274 infrastructure is not available, possibly due to network 275 partitnionning and loss of connectivity to an MBR. The MANET must 276 thus function without traditional server availability. While 277 stateless protocols such as [5] and [3] could provide IP address 278 configuration (for MANET interfaces, loopback interfaces), these 279 solutions do not provide any mechanism for allocating "unique 280 prefix(es)" to routers in order to enable the configuration of host 281 interfaces. Moreover, [5] and [3] test address uniqueness via 282 messages that are sent to neighbors only, and as such cannot detect 283 the presence of duplicate addresses configured within the network but 284 located several hops away. However, since MANETs are generally 285 multi-hop, detection of duplicate addresses over several hops is a 286 feature that is required in most cases of MANET interface address 287 assignment (see Section 4.3.2). 289 ----- MR1...MR3...MR5 290 / . 291 / . 292 / . 293 MR4 . 294 \ . 295 \ . 296 \----- MR2 298 Fig. 2. Standalone MANET router topology. 300 4.3. MANET Autoconfiguration Issues 302 Taking into account the shortcomings of traditional solutions, this 303 section categorizes general issues with regards to MANET 304 autoconfiguration. 306 4.3.1. Address and Prefix Generation 308 The distributed nature of MANETs brings the need for address 309 generation algorithms that are not always based on traditional 310 central server schemes and hierarchies to provide MANET routers with 311 addresses and prefixes. In addition, the multi-hop aspect of mobile 312 ad hoc networking makes it difficult to totally avoid address and 313 prefix duplication a priori over all the MANET. 315 4.3.2. Address Uniqueness Requirements 317 If address uniqueness is required within a specific scope, and if the 318 address/prefix generation mechanism in use does not totally avoid 319 address/prefix duplication, then additional issues arise. This 320 section overviews these problems. 322 Pre-service Issues -- One category of problems due to address 323 uniqueness requirements are called pre-service issues. Conceptually, 324 they relate to the fact that before a generated address is assigned 325 and used, it should be verified that it will not create an address 326 conflict within the specified scope. This is essential in the 327 context of routing, where it is desireable to reduce the risks of 328 loops due to routing table pollution with duplicate addresses. 330 In-Service Issues -- Another category of problems due to address 331 uniqueness are called in-service issues. They come from the fact 332 that even if an assigned address is currently unique within the 333 specified scope, it cannot be ensured that it will indeed remain 334 unique over time. 336 Phenomena such as MANET merging and MANET partitionning can bring the 337 need for checking the uniqueness (within the specified scope) of 338 addresses that are already assigned and used, if in-service address 339 uniqueness is required. 341 4.3.3. MANET Border Routers Related Issues 343 Another category of problems concern MBR management. 345 MBR Mobility -- Some addresses may be configured by servers available 346 through MBRs that may themselves be mobile and that may therefore 347 leave the MANET. In this case, global addresses used by routers in 348 the MANET may no longer be valid. 350 MBR Multiplicity -- In the case where multiple MBRs are available in 351 the MANET, providing access to multiple address configuration 352 servers, specific problems arise. One problem is the way in which 353 global prefixes are managed within the MANET. If one prefix is used 354 for the whole MANET, partitioning of the MANET may invalid routes in 355 the Internet towards MANET routers. On the other hand, use of 356 multiple network prefixes guarantees traffic is unambiguously routed 357 towards the MBR responsible for one particular prefix, but asymmetry 358 in the routers' choice of ingress/egress MBR can lead to non-optimal 359 paths followed by inbound/outbound data traffic. When a device 360 changes its MBR attachment, some routes may be broken, affecting 361 MANET packet forwarding performance and applications. 363 IPv6 Specifications -- Additional problems come from issues with 364 current IPv6 specifications. For example, the strict application of 365 [5] may lead to check every IPv6 unicast address for uniqueness: in a 366 multiple-MBR / multiple-prefixes MANET, this could bring to a large 367 amount of control signalling, due to frequent reconfiguration. 369 Moreover, IPv6 does not currently specify an address scope that is 370 appropriate to fit the scope of a MANET, which could lead to 371 undesireable behavior such as MBRs leaking MANET local traffic 372 outside the MANET. 374 5. Security Considerations 376 Address configuration in MANET could be prone to security attacks, as 377 in other type of IPv6 networks. Security threats to IPv6 neighbor 378 discovery are discussed in [6]: in particular, analysis includes 379 trust model and threats for a specific ad hoc network scenario, where 380 all the routers share a common link (i.e. they are one hop away from 381 each other, full-meshed connectivity is available). Although the 382 document does not explicitly address MANETs, where routers can be 383 multiple hop away from each other, the trust model it provides could 384 be valid also in the context of MANET autoconfiguration. It is also 385 worth noting that, in case of MANET connected to the Internet, other 386 threats defined in [6] could apply here, e.g. attacks involving 387 routers and DoS attacks on Duplicate Address Detection procedures. 389 The security analysis has to be further extended to include threats, 390 specific to multi-hop networks and related to the address 391 configuration process in particular. However, general security 392 issues of ad hoc routing protocols' operations are not in the scope 393 of MANET autoconfiguration. 395 6. IANA Considerations 397 This document does currently not specify IANA considerations. 399 7. Informative References 401 [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance 402 Issues and Evaluation Considerations", RFC 2501, January 1999. 404 [2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc Network 405 Architecture", ID draft-ietf-autoconf-manetarch, February 2007. 407 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 408 for IPv6", RFC 2461, December 1998. 410 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 411 Carney, "Dynamic Host Configuration Protocol for IPv6", 412 RFC 3315, July 2003. 414 [5] Narten, T. and S. Thomson, "IPv6 Stateless Address 415 Autoconfiguration", RFC 2462, December 1998. 417 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 418 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 420 Contributors 422 This document is the result of joint efforts, including those of the 423 following contributers, listed in alphabetical order: C. Adjih 424 (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P. 425 Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler 426 (Microsoft). 428 Authors' Addresses 430 Emmanuel Baccelli 431 INRIA 433 Phone: +33 1 69 33 55 11 434 Email: Emmanuel.Baccelli@inria.fr 436 Kenichi Mase 437 Niigata University 439 Phone: +81 25 262 7446 440 Email: Mase@ie.niigata-u.ac.jp 442 Simone Ruffino 443 Telecom Italia 445 Phone: +39 011 228 7566 446 Email: Simone.Ruffino@telecomitalia.it 448 Shubhranshu Singh 449 Samsung 451 Phone: +82 31 280 9569 452 Email: Shubranshu@gmail.com 454 Full Copyright Statement 456 Copyright (C) The IETF Trust (2007). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights. 462 This document and the information contained herein are provided on an 463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 465 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 466 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 467 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 Intellectual Property 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at 492 ietf-ipr@ietf.org. 494 Acknowledgment 496 Funding for the RFC Editor function is provided by the IETF 497 Administrative Support Activity (IASA).