idnits 2.17.1 draft-ruffino-conn-scenarios-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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 569. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 11, 2005) is 7014 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) == Unused Reference: '6' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 434, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 437, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 441, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 445, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 449, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 453, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 471, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 474, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 480, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 485, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 488, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 492, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 495, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 499, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2501 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-03 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-06) exists of draft-jeong-adhoc-ip-addr-autoconf-02 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '13') ** Downref: Normative reference to an Experimental RFC: RFC 3561 (ref. '14') ** Downref: Normative reference to an Experimental RFC: RFC 3684 (ref. '15') ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '16') ** Obsolete normative reference: RFC 2460 (ref. '18') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (ref. '19') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3775 (ref. '21') (Obsoleted by RFC 6275) -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Obsolete normative reference: RFC 2461 (ref. '23') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3633 (ref. '24') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '25' Summary: 16 errors (**), 0 flaws (~~), 21 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET S. Ruffino 3 Internet-Draft P. Stupar 4 Expires: August 15, 2005 TILAB 5 T. Clausen 6 LIX 7 S. Singh 8 SAMSUNG AIT 9 February 11, 2005 11 Connectivity Scenarios for MANET 12 draft-ruffino-conn-scenarios-00 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 15, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This Internet Draft aims at describing a wide spread set of possible 48 connectivity scenarios involving mobile ad-hoc networks, in order to 49 provide reference for standardization effort in this field. The 50 aspects considered for definition and classification of the scenarios 51 are number and characteristics of the gateways that connect MANET 52 nodes to external networks. Analysis will range from a scenario 53 where no connectivity is provided, i.e. an isolated MANET, to more 54 complex scenario where a MANET has multiple mobile Gateways. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1 Isolated MANET . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2 MANET connected to an external network . . . . . . . . . . 6 63 3.2.1 Fixed Gateways . . . . . . . . . . . . . . . . . . . . 8 64 3.2.2 Mobile Gateways scenario . . . . . . . . . . . . . . . 9 65 3.3 MANET intermittently connected to external networks . . . 10 66 4. Roaming from a MANET to an Infrastructure Network . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 71 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . . 17 74 1. Introduction 76 MANET were initially designed to be employed in highly dynamic and 77 unpredicatable environments, characterized by high mobility of users 78 and terminals. MANETs are essentially autonomous, self-configuring, 79 self-healing networks, whose mobile nodes discover other nodes and 80 supported services in an automatic fashion. MANET routing protocols, 81 as studied in IETF, enable two generic MANET nodes to exchange data 82 traffic through multi-hop connections, if a 1-hop radio link between 83 them is not available. In this way, nodes can freely move within the 84 MANET: routing protocols dynamically react to movement and constantly 85 discover the optimal path according to a predifined metric, e.g. 86 number of hops. If an intermediary node, belonging to a path between 87 a source and a destination, fails, traffic is automatically re-routed 88 through an alternative path. 90 RFC2501 [1] defines a MANET and also introduces the possibility to 91 connect a MANET to an external network, by means of gateways. These 92 are devices equipped with two or more network interfaces: a MANET 93 interface and an interface typically connected to one or more 94 non-MANET networks. MANET nodes exchange traffic among themselves 95 using multi-hop paths and can reach outside hosts and the Internet by 96 means of the gateways. In this case the MANET acts as a "stub" 97 network, whose nodes route traffic originating and/or terminating 98 within the MANET itself. 100 Operators, Network and Service providers show increasing interest in 101 this type of network, as a consequence of the wide spread deployment 102 of low-cost radio technologies such as IEEE802.11a/b/g/h and the 103 increasing customer base. Initially, commercial MANETs are expected 104 to be deployed as an extension to the traditional infrastructure 105 networks, to realize the so-called hybrid networks. 107 An example of this networks are the Mesh Networks, used to extend the 108 coverage area of a public hot-spot or to realize large-scale low-cost 109 wireless coverage in urban areas. A further interesting application 110 and research field is represented by multi-hop cellular networks: 111 MANETs connected to cellular WAN networks. In this case MANETs can 112 be used to realize an extended wireless coverage in areas where 113 "traditional" cellular network is not available. 115 Many proposals and projects that introduce integration between MANET 116 and 3G+ networks exist: for example, see [2], [3], [4] and [5]. 118 This Internet Draft aims at describing and analyzing connectivity 119 scenarios for MANET, to provide a reference for standardization 120 effort in this field. In fact, the scenarios described herein can be 121 used as a starting point for the design of solutions to technical 122 problems, such as address autoconfiguration, gateway discovery, 123 Duplicate Address Detection and global prefixes management. 125 Analysis will range from a scenario where no connectivity is 126 provided, i.e. an isolated MANET, to more complex scenarios where a 127 MANET has multiple mobile Gateways. This document is structured in 128 the following way: in Section 2 a glossary for commonly used terms is 129 given; in Section 3 connectivity scenarios for a MANET are listed. 130 In this section particular attention is paid to the connection of a 131 MANET with other external networks, by means of one or more fixed 132 (Section 3.2.1) or mobile wireless gateways (Section 3.2.2). In 133 Section 4 the roaming of a node from a Infrastractured wireless LAN 134 to an ad-hoc network is considered. 136 2. Terminology 138 Node 139 An IPv4/IPv6 device which is a MANET element: it runs a MANET 140 routing protocol and exchanges data with other nodes within a 141 MANET and with hosts located within external networks. A node has 142 at least one physical interface connecting it to the MANET. 144 Gateway 145 A node equipped with at least two interfaces, one of which 146 connects it to an external network, i.e. non-MANET, and can be 147 wired or wireless. 149 Host 150 An IPv4/IPv6 terminal/computer, external to the MANET. Host is 151 defined here as only "External" to differentiate it from the nodes 152 of the MANET. 154 Wireless Interface (or MANET interface) 155 The physical network interface that connects a node to the MANET. 157 Radio Interface (or Cellular Interface) 158 The physical network interface that can connect a gateway to an 159 external Wireless Wide Area Network, owned and administered by an 160 operator. 162 3. Scenarios 164 In this section, we describe the typical connectivity scenarios of a 165 MANET. This section is structured as follows: first, the case of an 166 isolated MANET is examined, where no gateways exist. Then, various 167 scenarios of a connected MANET are given, classified by the 168 characteristics and the number of gateways, which can be fixed and/or 169 mobile. In the end, the case of an intermittently connected MANET is 170 analyzed. 172 3.1 Isolated MANET 174 An isolated MANET is a network that is autonomously set-up among 175 wireless mobile nodes localized in the same geographical area. Nodes 176 activate Layer 2 radio links, by which they can exchange traffic with 177 their neighbors, and run an ad-hoc routing protocol, which enables 178 multi-hop data forwarding through intermediate nodes. Routing 179 protocol constantly discovers routes between nodes, in a proactive 180 ([13], [15]) or reactive fashion ([14], [16]): this enables each node 181 to route traffic to all other nodes within the MANET also during 182 movements. 184 In this type of MANET there is no connection to an external network: 185 all traffic is generated by MANET nodes and addressed to MANET nodes. 187 Typical applications of this scenario are temporary networks, that 188 must be set-up in areas where neither wireless coverage nor 189 infrastructure exist. Examples can be emergency networks used for 190 disaster recovery, battlefield applications, electronic surveillance. 191 Other examples can be found in occasional work meetings, where 192 networks are set-up to enable file sharing among co-workers. 194 3.2 MANET connected to an external network 196 In this scenario a MANET is connected to an external network by means 197 of one or more gateways (Figure 1). A generic MANET node can 198 exchange data traffic with every other node through multi-hop paths 199 and communicate with hosts located in the external network, routing 200 its uplink traffic towards a gateway. Such gateway, in turn, will 201 receive return traffic from the host and will route it to the source 202 node. 204 H1 205 | 206 +---------------+ 207 | Internet |** 208 +---------------+ * 209 * * * 210 * * * 211 GW1** * GW3 212 | +--GW2-------+ 213 | | | 214 ---N1--------+ | 215 / \ | 216 N4 \ N2 217 N3-----/ 219 Figure 1: MANET interconnected to an external network 221 Gateways play a critical role here. If the number of nodes in the 222 MANET increases, gateways can become bottlenecks, as they route an 223 increasing and possibily huge amount of traffic. This also depends 224 on the available bandwidth on the uplink interface. Moreover, 225 gateways can be equipped with a number of additional features. For 226 example, they could participate to the external routing protocol, in 227 order to announce internal routes to external routers and hosts, 228 possibly performing some kind of aggregation. They can act as 229 enforcement points for security purposes: they can control access to 230 external networks and, following a common practice, they can enforce 231 Ingress Filtering on MANET generated traffic. Finally they can also 232 provide services like DNS to MANET nodes. 234 This scenario can be expanded, depending on the characteristics of 235 the network interface connecting gateways to the external network: it 236 can be either wired or wireless, which can, in turn, be of a 237 different type with respect to the MANET interface. In the first 238 case Gateways are fixed, while in the second case they can also be 239 mobile, as the other MANET nodes. 241 Moreover, a MANET can have only one gateway (fixed or mobile) or can 242 have multiple gateways (fixed or mobile). Other than guaranteeing a 243 high degree of reliability and fault tolerance to the entire MANET, 244 the presence of multiple gateways enables load balancing among the 245 gateways themselves. This can be very useful especially when the 246 external network is a low-throughput cellular WAN, such as GPRS/EDGE, 247 in order not to overload a single gateway with traffic potentially 248 generated by many nodes at the same time. Single traffic flows of 249 multiple nodes or many flows of a single node can be routed through 250 different gateways, consequently implying an improvement of the 251 overall performances of the MANET. 253 Gateways can also be equipped with additional resources in order to 254 grant better fault tolerance to the entire MANET: additional energy 255 resources, more processing power, more volatile and non-volatile 256 memory. This is especially true in case of fixed gateways, that can 257 be directly powered and directly operated. 259 The following sections detail usage scenarios for fixed and mobile 260 gateways. 262 3.2.1 Fixed Gateways 264 In this scenario, gateways are deployed in predefined positions 265 planned by the network operator. Each gateway is connected to the 266 external network by means of a wired or wireless interface. 268 Mesh networks and networks used for environmental surveillance can be 269 categorized under this scenario. 271 o Mesh Networks: these are probably the most widespread ad-hoc 272 networks. In a Mesh Network, user terminals (nodes) exchange 273 traffic between them directly through a layer-2 radio link and 274 using other nodes or fixed wireless devices as intermediate 275 relays. A Mesh Network is typically connected to an external 276 infrastructure network by means of fixed wired Access Points, 277 which act as gateways and typically connect the Mesh to an 278 external infrastructure network. 279 Mesh Networks can be further classified depending on the kind of 280 devices which form the mesh itself. In fact, in some deployments, 281 the mesh is realized only among the wireless Access Points, which 282 are devices endowed with two wireless interfaces: the first 283 interface forms the mesh with other peer access points, 284 participating to a routing protocol, the second interface provides 285 local connectivity to nodes, which cannot set-up a network 286 themselves, as they don't run any routing protocol. In another 287 case the mesh is realized among all the nodes, which have to run a 288 routing protocol. 289 Applications of this networks are Internet public access 290 (browsing, email etc.) by mobile users from outdoor areas, 291 wireless coverage of corporate building to give employees access 292 to shared data and commonly used services (email, Intranet 293 browswing). These solutions can bring to savings on cabling and 294 maintenance costs. 296 o Surveillance networks: several wireless nodes endowed with sensors 297 of various kinds are spread over high enviromental risk areas 298 (e.g. fires in wooden areas). They communicate through multi-hop 299 connections and run a routing protocol. When an emergency 300 situation arises, data collected by sensors are transmitted from 301 the collecting nodes upwards one or more gateways (which can have 302 both a wired or wireless interface) and conveyed to a manned 303 monitoring station. 304 Topologies of this kind of network are typically static, as the 305 nodes are installed in fixed positions within the monitored areas. 306 Moreover, these networks are characterized by multiple constant 307 low-throughput data flows going from the sensors to the gateways. 309 3.2.2 Mobile Gateways scenario 311 In this scenario, the gateway's radio interface, connecting the MANET 312 to the external network, can be a cellular WAN interface (GSM, GPRS, 313 EDGE, UMTS), a broadband wireless MAN (WMAN) interface (e.g. 314 802.16x, 802.20) or a WLAN interface (802.11a/b/g/h/j). In each of 315 these cases, gateways can forward uplink traffic outside the MANET 316 only if located within the transmission/reception range of one or 317 more Base Stations or Access points. Gateways not only can move 318 freely within the coverage area, but they can also move outside this 319 area. In such case, the gateway can't forward uplink traffic 320 destined to external hosts anymore, nor downlink traffic destined to 321 internal nodes. 323 In this outlined scenario, the MANET can be seen as a coverage 324 extension of the radio infrastractured network to which the gateways 325 are connected. The primary benefit of such extension is that local 326 communication between two nodes is performed without using any 327 cellular radio resource, e.g. radio channels. Another benefit is 328 the possibility to grant network access also to those terminals that 329 are not equipped with a cellular radio interface (e.g. access 330 sharing). The implication of this business model on security, 331 accounting and rewarding aspects are out of the scope of this draft, 332 neverthless must be carefully investigated. 334 A more advanced scenario can be realized when most of the nodes are 335 also equipped with two heterogeneous interfaces. In this case 336 gateways can be "occasional": they can be nodes that, after setting 337 up the connection towards the external network, whenever located 338 within its coverage area, can start forwarding other nodes' outbound 339 packets. In this kind of scenario, gateways can be "special" nodes 340 endowed with additional features, but they can also be ordinary MANET 341 nodes, such as mobile phones and PDAs. In this last case, gateways 342 are characterized by low computational power and limited energy 343 resources. Although the MANET can again exploit benefits given by 344 multiple gateways, additional issues arise: in fact, gateways are not 345 under operators control anymore. It's possible that the owner of the 346 gateway establishes abruplty to turn his terminal off or to tear down 347 the connection towards the cellular network, in order to save battery 348 life. Thus, the number and the position of gateways are higly 349 dynamic and this can cause frequent re-routing of uplink data flows. 351 o Automotive scenario: a MANET is set up by a group of vehicles. 352 One or more of these may become a mobile gateway after connecting 353 to the Wireless LAN of a petrol station or setting up an UMTS 354 connection and, therefore, may be used by the other vehicles of 355 the MANET to exchange traffic with the external hosts. 357 3.3 MANET intermittently connected to external networks 359 Gateways in a MANET, especially if mobile and equipped with a radio 360 interface, may not be permanently connected to the external network. 361 MANETs of this kind have the characteristics of both MANET described 362 in Section 3.1 (while not connected) and of the ones described in 363 Section 3.2 (while connected). 365 Most of the nodes belonging to a MANET of this kind shall exploit the 366 connection temporally set up to an external network to communicate 367 with hosts they can't reach while the MANET is isolated. As a 368 consequence, such MANETs may experience a burst of exchanged traffic 369 while connected to the external network. The amount and the 370 distribution of such traffic depends on how long the MANET can be 371 connected to an external network. 373 o Train network: a MANET built in a train, which is connected while 374 stopped at the station and disconnected otherwise. In particular, 375 if the MANET is set up by some passengers, it may happen that 376 while the train is stopped at the station, some of the nodes may 377 become gateways. For example, the station area may be covered by 378 a wireless technology and some nodes equipped with a non-MANET 379 interface of the same technology may therefore set up a connection 380 to the external network. In this case, most of the users may use 381 the gateways to connect to their mail server, download and 382 eventually send their e-mails: the MANET they belong to may 383 therefore experience a burst of traffic exchanged with the 384 external network. 386 4. Roaming from a MANET to an Infrastructure Network 388 A mobile node, connected e.g. to a IEEE 802.11 network 389 (infrastructure mode), can roam to a nearby IEEE 802.11 (ad-hoc mode) 390 MANET. This situation can be very commonly experienced by a mobile 391 node, during its movement, even not voluntarily. It is worth noting 392 that such roaming doesn't involve only layer-2 operations. It is 393 indeed likely that the procedures used within IEEE 802.11 network, 394 e.g. for address configuration or duplicate address detection, are 395 different from those used in a MANET. This is mainly due to the fact 396 that a MANET is characterized by multi-hop paths while in a WLAN all 397 hosts are connected to the same link. 399 There can be also situation where the destination MANET uses a 400 different radio technology for multi-hop links. This scenario, not 401 addressed in this document, brings added difficulties, because radio 402 interface should be dynamically switched to use a different Layer 1 403 and 2 technology. 405 5. Security Considerations 407 This document raises no security issue. 409 6. IANA Considerations 411 This document has no actions for IANA. 413 7. References 415 [1] Corson, S. and J. Macker, "Mobile ad hoc networking (MANET): 416 Routing protocol performance issues and evaluation 417 considerations", RFC 2501, January 1999. 419 [2] Siebert, M., "On Ad Hoc Networks in the 4G Integration 420 Process", Med-Hoc 2004 , June 2004. 422 [3] "Ambient Networks", http://www.ambient-networks.org . 424 [4] "Daidalos", http://www.ist-daidalos.org . 426 [5] "World Wireless Research Forum", 427 http://www.wireless-world-research.org . 429 [6] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A. 430 Tuominen, "Global connectivity for IPv6 Mobile Ad Hoc 431 Networks", I-D draft-wakikawa-manet-globalv6-03.txt, October 432 2003. 434 [7] Cha, H., Park, J. and H. Kim, "Extended Support for Global 435 Connectivity for IPv6 Mobile Ad Hoc Networks", October 2003. 437 [8] Jeong, J., Park, J., Kim, H. and D. Kim, "Ad Hoc IP Address 438 Autoconfiguration", 439 I-D draft-jeong-adhoc-ip-addr-autoconf-02.txt, February 2004. 441 [9] Perkins, C., Malinen, J., Wakikawa, R. and E. Belding-Royer, 442 "IP Address Autoconfiguration for Ad Hoc Networks", 443 I-D draft-perkins-manet-autoconf-01.txt, November 2001. 445 [10] Singh, S., Kim, JH., Choi, YG., Kang, KL. and YS. Roh, "Mobile 446 multi-gateway support for IPv6 mobile ad hoc networks", 447 I-D draft-singh-manet-mmg-00.txt, June 2004. 449 [11] Paakkonen, P., Rantonen, M. and J. Latvakoski, "IPv6 addressing 450 in a heterogeneous MANET-network", 451 I-D draft-paakkonen-addressing-htr-manet-00.txt, December 2003. 453 [12] Jelger, C., Noel, T. and A. Frey, "Gateway and address 454 autoconfiguration for IPv6 adhoc networks", 455 I-D draft-jelger-manet-gateway-autoconf-v6-02.txt, April 2004. 457 [13] Clausen, T. and P. Jacquet, "Optimized link state routing 458 protocol", RFC 3626, October 2003. 460 [14] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand 461 Distance Vector (AODV) Routing", RFC 3561, July 2003. 463 [15] Ogier, R., Templin, F. and M. Lewis, "Topology Dissemination 464 Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 465 2004. 467 [16] Johnson, D., Maltz, D. and Y. Hu, "The Dynamic Source Routing 468 Protocol for Mobile Ad Hoc Networks (DSR)", 469 I-D draft-ietf-manet-dsr-10.txt, July 2004. 471 [17] Postel, J., "Internet Protocol", STD 5, RFC 791, September 472 1981. 474 [18] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 475 Specification", RFC 2460, December 1998. 477 [19] Thomson, S. and T. Narten, "IPv6 Stateless Address 478 Autoconfiguration", RFC 2462, December 1998. 480 [20] Aboba, B., "Dynamic Configuration of Link-Local IPv4 481 Addresses", 482 Internet-Draft draft-ietf-zeroconf-ipv4-linklocal-17, July 483 2004. 485 [21] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 486 IPv6", RFC 3775, June 2004. 488 [22] Sun, Y. and E. Belding-Royer, "A study of dynamic addressing 489 techniques in mobile ad hod networks", I-D Wireless 490 communication and mobile computing, May 2004. 492 [23] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 493 for IP Version 6 (IPv6)", RFC 2461, December 1998. 495 [24] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 496 Configuration Protocol (DHCP) version 6", RFC 3633, December 497 2003. 499 [25] Engelstad, P., T�nnesen, A., Hafslund, A. and G. Egeland, 500 "Internet Connectivity for Multi-Homed Proactive Ad Hoc 501 Networks", First IEEE International Conference on Sensor and Ad 502 hoc Communications and Networks , October 2004. 504 Authors' Addresses 506 Simone Ruffino 507 Telecom Italia LAB 508 Via G.Reiss Romoli 274 509 Torino 10148 510 Italy 512 Phone: +39 011 228 7566 513 Email: simone.ruffino@telecomitalia.it 515 Patrick Stupar 516 Telecom Italia LAB 517 Via G.Reiss Romoli 274 518 Torino 10148 519 Italy 521 Phone: +39 011 228 5727 522 Email: patrick.stupar@telecomitalia.it 524 Thomas Heide Clausen 525 Laboratoire d'informatique 526 Ecole Polytechnique 527 Palaiseau Cedex 91128 528 France 530 Phone: +33 1 6933 2867 531 Email: thomas.clausen@polytechnique.fr 533 Shubhranshu Singh 534 SAMSUNG Advanced Institute of Technology - i-Networking Laboratory 535 San 14-1, Nongseo-ri, Giheung-eup 536 Yongin-si, Gyeonggi-do 449-712 537 Korea 539 Phone: +82 31 280 9569 540 Email: shubhranshu@samsung.com 542 Appendix A. Acknowledgments 544 The authors would like to thank Ivano Guardini for his valuable 545 comments. 547 Intellectual Property Statement 549 The IETF takes no position regarding the validity or scope of any 550 Intellectual Property Rights or other rights that might be claimed to 551 pertain to the implementation or use of the technology described in 552 this document or the extent to which any license under such rights 553 might or might not be available; nor does it represent that it has 554 made any independent effort to identify any such rights. Information 555 on the procedures with respect to rights in RFC documents can be 556 found in BCP 78 and BCP 79. 558 Copies of IPR disclosures made to the IETF Secretariat and any 559 assurances of licenses to be made available, or the result of an 560 attempt made to obtain a general license or permission for the use of 561 such proprietary rights by implementers or users of this 562 specification can be obtained from the IETF on-line IPR repository at 563 http://www.ietf.org/ipr. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights that may cover technology that may be required to implement 568 this standard. Please address the information to the IETF at 569 ietf-ipr@ietf.org. 571 Disclaimer of Validity 573 This document and the information contained herein are provided on an 574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 576 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 577 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 578 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 581 Copyright Statement 583 Copyright (C) The Internet Society (2005). This document is subject 584 to the rights, licenses and restrictions contained in BCP 78, and 585 except as set forth therein, the authors retain all their rights. 587 Acknowledgment 589 Funding for the RFC Editor function is currently provided by the 590 Internet Society.