idnits 2.17.1 draft-ruffino-manet-autoconf-multigw-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1242. ** 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. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 630: '...y means of a single interface MUST NOT...' RFC 2119 keyword, line 695: '... PADD uniqueness MUST be verified by t...' RFC 2119 keyword, line 775: '... set from a node MUST be complete with...' RFC 2119 keyword, line 782: '... [RFC3626], the message MUST be forwarded according to Section 3.4 of...' RFC 2119 keyword, line 787: '...sage, the P_time MUST be computed from...' (17 more instances...) 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 (June 8, 2005) is 6869 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) == Missing Reference: 'TBD' is mentioned on line 743, but not defined == Unused Reference: 'RFC2460' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: '4G-INT' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'AMBNET' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'BELDING' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'ENGELSTAD' is defined on line 1105, but no explicit reference was found in the text == Unused Reference: 'I-D.ruffino-conn-scenarios' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC2501' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'SINGH' is defined on line 1177, but no explicit reference was found in the text == Unused Reference: 'WWRF' is defined on line 1187, but no explicit reference was found in the text == Unused Reference: 'ZEROCONF' is defined on line 1190, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Experimental RFC: RFC 3626 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Unexpected draft version: The latest known version of draft-hinden-ipv6-global-local-addr is -02, but you're referring to -09. == Outdated reference: A later version (-10) exists of draft-dupont-ipv6-imei-08 == Outdated reference: A later version (-01) exists of draft-ruffino-conn-scenarios-00 == Outdated reference: A later version (-03) exists of draft-singh-autoconf-adp-00 == Outdated reference: A later version (-02) exists of draft-wakikawa-manet-ipv6-support-00 == Outdated reference: A later version (-06) exists of draft-jeong-adhoc-ip-addr-autoconf-02 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-03 Summary: 10 errors (**), 0 flaws (~~), 21 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 autoconf S. Ruffino 3 Internet-Draft P. Stupar 4 Expires: December 10, 2005 TILAB 5 June 8, 2005 7 Automatic configuration of IPv6 addresses for nodes in a MANET with 8 multiple gateways 9 draft-ruffino-manet-autoconf-multigw-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 10, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This Internet Draft relates to Mobile Ad-hoc Networks (MANETs) 43 connected to an external network by means of one or more gateways. A 44 solution that enables MANET nodes to automatically discover a global 45 address is proposed. The proposed solution aims at reducing the 46 latency introduced by a global address change and exposes two 47 algorithms a node may adopt to discover if the used address has to be 48 changed. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Applicability Scenario . . . . . . . . . . . . . . . . . . . . 5 55 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Autoconfiguration Method Overview . . . . . . . . . . . . . . 9 57 5.1 Advantages of the proposed method . . . . . . . . . . . . 10 58 5.2 Examples of operations . . . . . . . . . . . . . . . . . . 11 59 5.2.1 Bootstrapping of a node . . . . . . . . . . . . . . . 11 60 5.2.2 Gateway change . . . . . . . . . . . . . . . . . . . . 12 61 6. Data structures . . . . . . . . . . . . . . . . . . . . . . . 15 62 6.1 Prefix Information base . . . . . . . . . . . . . . . . . 15 63 6.2 Delegated Prefixes Information Base . . . . . . . . . . . 15 64 6.3 Secondary Addresses Information Base . . . . . . . . . . . 16 65 6.4 Multiple Interface Association Information Base . . . . . 16 66 7. Detailed operations . . . . . . . . . . . . . . . . . . . . . 18 67 7.1 IPv6 Addresses generation . . . . . . . . . . . . . . . . 18 68 7.2 Primary Address configuration . . . . . . . . . . . . . . 18 69 7.3 Prefix Advertisement . . . . . . . . . . . . . . . . . . . 18 70 7.3.1 Prefix Advertisement (PA) messages format . . . . . . 18 71 7.3.2 PA message generation . . . . . . . . . . . . . . . . 20 72 7.3.3 PA message forwarding . . . . . . . . . . . . . . . . 20 73 7.3.4 PA message processing . . . . . . . . . . . . . . . . 21 74 7.3.5 Secondary Addresses Information Base Management . . . 21 75 7.4 MID messages . . . . . . . . . . . . . . . . . . . . . . . 22 76 7.4.1 MID message generation . . . . . . . . . . . . . . . . 22 77 7.4.2 MID message forwarding . . . . . . . . . . . . . . . . 22 78 7.4.3 MID message processing . . . . . . . . . . . . . . . . 22 79 7.5 Global IPv6 Address configuration for MANET nodes . . . . 23 80 7.5.1 Best Prefix Selection Algorithm . . . . . . . . . . . 24 81 7.5.2 Address change . . . . . . . . . . . . . . . . . . . . 25 82 7.6 Gateway operations . . . . . . . . . . . . . . . . . . . . 25 83 8. Mobile IPv6 Considerations . . . . . . . . . . . . . . . . . . 27 84 9. Proposed Values for Constants . . . . . . . . . . . . . . . . 28 85 9.1 Emission Intervals . . . . . . . . . . . . . . . . . . . . 28 86 9.2 Holding Time . . . . . . . . . . . . . . . . . . . . . . . 28 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 29 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 12.1 Normative references . . . . . . . . . . . . . . . . . . . 31 91 12.2 Informative References . . . . . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 93 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 94 Intellectual Property and Copyright Statements . . . . . . . . 36 96 1. Introduction 98 MANETs are wireless networks characterized by the absence of any 99 infrastructure: nodes of a MANET function both as hosts (i.e. they 100 are end-points of a communication) and as routers. In fact packets 101 which can not be directly delivered between two nodes are routed 102 through other intermediate nodes following a multi-hop path to reach 103 their destination. Routing within a MANET is guaranteed by a routing 104 protocol, which enables nodes calculate the optimal path that data 105 packets must follow within the MANET itself. If the MANET is 106 connected to an external network (e.g. the global Internet), nodes 107 can communicate towards hosts located in such network: in this case, 108 global connectivity has to be guaranteed, i.e. MANET nodes have to 109 be identified by a valid IP address through which packets transmitted 110 by hosts located outside the MANET can be received. 112 This document presents a mechanism for automatic configuration of a 113 topologically correct, globally valid IPv6 address on nodes in a 114 MANET connected to the Internet through one or more gateways. The 115 routing protocol considered in this document is Optimized Link State 116 Routing (OLSR) [RFC3626]. With the solution presented in this 117 document, nodes can effectively exploit all the active gateways in 118 the MANET: a new OLSR message type is introduced, to enable gateways 119 to announce IP prefixes within MANET. When nodes receive such 120 prefixes, they build a set of global addresses and, in turn, 121 advertise them to other MANET nodes. Global addresses announcement 122 enables node to dynamically choose another valid address, among those 123 announced, and to continue to communicate with external IP hosts, 124 without experiencing significant delay. The node can decide to 125 change the global address in use basically for two reasons: after the 126 failure of the gateway announcing the prefix from which it derived 127 its used global address or for performance reasons, e.g. to optimize 128 downlink data traffic path. 130 This document is organized as follows: Section 3 describes the 131 reference scenario and its main features; Section 4 exposes the 132 problem statement regarding global address configuration in the 133 reference scenario; Section 5 outlines the proposed solution, which 134 is detailed in Section 6 and Section 7. 136 2. Terminology 138 Valid IPv6 Global Address 139 An IPv6 address which is globally routable, i.e. it is 140 topologically correct and it is reachable from all hosts and 141 routers located in external networks (e.g. the Internet). 143 Main Address 144 In OLSR [RFC3626], an IPv6 address used as identifier of the node, 145 inserted in the 'Originator Address' field in OLSR control 146 messages. 148 Primary Address (PADD) 149 The identifier used by MANET nodes to partecipate to routing 150 protocol, i.e. it is used as OLSR main address. One MANET node 151 owns exactly one primary address, which must be configured at 152 bootstrapping. In this proposal, such address is MANET-scoped, 153 i.e. it is routable within the MANET only. 155 Secondary Address (SADD) 156 A valid IPv6 global address that can be used as IPv6 source 157 address in datagrams transmitted from a MANET node to internal 158 nodes or external hosts. More than one secondary address can be 159 bound to one node's primary address. 161 Designated Secondary Address (DSADD) 162 A SADD used by the node to communicate with a generic host, namely 163 an address used as IPv6 source address of transmitted packets. 164 This address may change during the lifetime of a node. 166 3. Applicability Scenario 168 The reference scenario to which the mechanism described in this 169 specification applies is shown in Figure 1. In this scenario, MANETs 170 are connected to other external networks by means of one or more 171 gateways that provide Internet connectivity. Nodes that are not 172 directly linked to the external network can use a multihop wireless 173 connection to reach the gateways and forward outbound traffic. An 174 in-depth description of such scenario can be found in [I-D.ruffino- 175 conn-scenarios]. 177 H1 178 | 179 +---------------+ 180 | Internet |** 181 +---------------+ * 182 * * * 183 * * * 184 GW1** * GW3 185 | +--GW2-------+ 186 | | | 187 ---N1--------+ | 188 / \ | 189 N4 \ N2 190 N3-----/ 192 Figure 1: MANET interconnected to an external network 194 An example of the applicability scenario can be a mobile operator 195 cellular network extended by means of ad-hoc "clouds". In this case, 196 mobile nodes are equipped with two interfaces, for example an UMTS 197 interface and an IEEE 802.11g interface. The first one enables nodes 198 to directly set-up a radio link towards the external network and 199 receive a valid global IPv6 address, while the second one is used to 200 participate to a MANET. This is typically achieved by running a 201 MANET routing protocol, s.a. AODV [RFC3561], OLSR [RFC3626], TBRPF 202 [RFC3684] and DSR [DSR]. A node located in the coverage area of the 203 cellular network can act as gateway for the MANET: in this way, nodes 204 that are not in the coverage area of the mobile network can use other 205 MANET nodes to reach the gateways and forward outbound traffic. 207 It is also assumed that gateways own one or more IPv6 prefixes which 208 can be advertised within the MANET. The mechanism by which gateways 209 retrieve this information is out of scope of this specification: it 210 can be manually configured by administrators or dynamically set up, 211 during link establishment towards the Internet, e.g. using DHCP with 212 Prefix Delegation Option ([RFC3633]). It is also assumed that 213 different gateways advertise different prefixes, in order not to 214 require special configuration both on gateways themselves and on 215 Internet routers. As a consequence, traffic directed to an IPv6 216 address derived by one of the prefixes advertised within the MANET is 217 univocally routed towards the gateway owning such prefix. 219 4. Problem Statement 221 Standard configuration methods for IPv6, i.e. stateful ([RFC3315]) 222 and stateless ([RFC2462]) IPv6 autoconfiguration, cannot be applied 223 to MANETs, as outlined by previous work ([PERKINS], [WAKI-GLOBAL6], 224 [I-D.singh-autoconf-adp], [I-D.wakikawa-manet-ipv6-support]). 225 Standard methods have been designed for single-hop link (e.g. a 226 single LAN segment, where all hosts and routers are on the same Layer 227 2 link) and don't address MANET intrinsic characteristics, such as 228 multi-hop connections, partitions and mergers. 230 In the past, a number of solutions has been proposed, to solve 231 automatic configuration of IPv6 addresses in a MANET and the global 232 IPv6 connectivity problem: e.g. [WAKI-GLOBAL6], [CHA], [JELGER], 233 [JEONG], [PAAKKONEN]. Technical issues addressed by these proposals 234 can be summarized as follows: 236 Bootstrapping of a node 237 Actually, there is no standardized method enabling a node to 238 automatically configure a unique address by means of which it can 239 participate to the routing protocol. MANET routing protocols have 240 been defined implicitly assuming that nodes already own a unique 241 address configured on their MANET interface. Moreover, there is 242 not any standard DAD mechanism for MANET, through which a node can 243 verify the uniqueness of its address. 245 Global Connectivity 246 In a MANET endowed with gateways global connectivity problem 247 arises: nodes need a valid global IPv6 address enabling them 248 receive data traffic coming from hosts located outside the MANET. 250 It is worth noting that in the applicability scenario, a number of 251 technical issues arise, besides those described by previous work. In 252 fact, gateways can freely move and they may also leave the MANET: in 253 this case, global prefixes associated to such gateways are no more 254 valid, as the traffic would be routed by external network routers 255 towards a link which is no more active. As a consequence, MANET 256 nodes using global addresses derived from such (no more valid) 257 prefixes are no more reachable from the external network. Nodes must 258 therefore acquire a new valid IPv6 address, derived from a valid 259 prefix which is advertised by an available gateway. 261 The technical issues specific to the applicability scenario described 262 in Section 3 are the following: 264 IPv6 address change 265 Routing protocols (e.g. OLSR) assume that each node configures on 266 its MANET interface only one address, which identifies the node 267 itself and all its related topological information collected by 268 routing protocol. When the node changes such address (named main 269 address in OLSR), all topological information diffused by the node 270 to the MANET is no more valid as it is associated to an address 271 which is not used by any node. From the point of view of the 272 MANET, an address change is similar to the failure of the node. 273 Therefore, after the change of its configured address, a node will 274 experience a period of absence of connectivity as the other MANET 275 nodes don't own a route towards it. Such period will last until 276 the node has transmitted enough topological information bound to 277 its new configured address. 279 Sub-optimal path 280 The choice of the global address defines the path that downlink 281 traffic coming from the Internet will follow to reach a MANET 282 node. Indeed, external hosts will send packets to the global 283 address used by the node: such packets will be delivered to the 284 gateway owning the global prefix from which the global 285 (configured) address was derived and will then follow a path 286 connecting such gateway to the node. If a node doesn't change the 287 global address in use as long as this is valid, the downlink path 288 followed by (return) traffic within the MANET will always start 289 from the same gateway. This doesn't assure that such used path is 290 the best one, according to a predefined metric. Indeed, after a 291 change of MANET topology, there may be a better gateway whose use 292 optimizes download traffic reception: the node doesn't exploit 293 such gateway as long as the global address in use is derived from 294 another gateway's global prefix. 296 It is a non-goal of this specification to solve application session 297 survivability, after a node changes its global address. It is 298 authors' belief that IETF standard method for IPv6 mobility, namely 299 Mobile IPv6 [RFC3775], can be applied to this environment. Section 8 300 elaborates on this. Similarly, this specification does not propose 301 any new Duplicate Address Detection method. A generic DAD procedure 302 (e.g. [PERKINS]) can be used, in order to verify uniqueness of 303 MANET-local and global addresses. 305 5. Autoconfiguration Method Overview 307 This section gives an overview of the proposed IPv6 address 308 autoconfiguration solution, which is specified for nodes running OLSR 309 protocol in Section 6 and Section 7. 311 Each node is characterized by two types of addresses: 313 o its Primary Address (PADD), which does not change during node's 314 life in the MANET and is independent from the prefixes announced 315 by gateways; PADD can be, for example, an IPv6 ULA [I-D.ULA]; 317 o one or more Secondary Addresses (SADD), built using the global 318 prefixes announced by gateways; each node can use one of such 319 addresses as source address of the outgoing traffic, i.e. the 320 Designated Secondary Address (DSADD). 322 A new OSLR message type, named Prefix Advertisements (PA), is 323 defined, to advertise global prefixes. Gateways periodically 324 disseminate PA messages, which contain their delegated prefixes. 325 More details on PA messages format and processing are described in 326 section Section 7.3. PA messages can be considered complementary to 327 OLSR HNA (Host and Network Association) messages, whose content is 328 used by OLSR nodes to perform gateway discovery and default route 329 set-up. 331 Basic operations for a generic node can be summarized as follows: 333 o At bootstrap, node builds and configures a PADD and uses it as 334 main address in OLSR messages. 336 o Node participates to OLSR, sending and receiving topology 337 information. After a transitory period, the node receives Prefix 338 Advertisement (PA) messages from the gateways in the MANET. 340 o It uses the prefixes, received from gateways, to build a set of 341 global IPv6 addresses: at least, it derives an address from each 342 received prefix (i.e. a SADD). Among them, node chooses the 343 "best" address, corresponding to the "best" prefix, according to 344 some method (e.g. Default Gateway method, described in 345 Section 7.5.1), and starts using it as DSADD. 347 o Node inserts all (or a subset) of the addresses (including DSADD) 348 built in the previous step into OLSR MID messages and starts 349 broadcasting them. After a transitory period, all nodes own a 350 route towards the DSADD and all the other SADDs of the node, 351 proactively announced using MID messages. 353 o Topological information regarding gateways announcing global 354 prefixes is constantly monitored by node to know at any time which 355 is the best prefix and therefore the current best global address. 356 Such address is chosen as DSADD. As a consequence, the node 357 changes its DSADD after one of the following events: 359 * The gateway which advertises the prefix used by the node to 360 derive its DSADD is no more reachable. 362 * Node experiences a significant topological change (e.g. it 363 moves) after which the prefix used to derive the DSADD is no 364 more the best one. 366 Since a node inserts into MID messages multiple SADDs, besides those 367 which it is actually using as DSADDs, a node can transparently use a 368 new Secondary Address without bootstrapping the routing protocol 369 every time this happens. Indeed, the traffic destined to any of the 370 Secondary Addresses is immediately routable within the MANET and, in 371 particular, from the gateways to the nodes. 373 In case the considered gateway has several associated prefixes, the 374 node will choose one of these prefixes according to a predetermined 375 rule, for example it may choose the first one it has received, but 376 may also decide to configure many DSADDs (one for each prefix). 378 Section 5.1 exposes the benefits of the solution proposed in this 379 document and Section 5.2 gives two examples of the sequence of 380 operations executed by a node when the proposed solution is adopted. 382 5.1 Advantages of the proposed method 384 The main advantages of the proposed solution are the following: 386 o The downlink path followed by traffic coming from external network 387 can be optimized, with respect to the hop-count metric. This can 388 be achieved when using a best prefix selection method that enables 389 MANET nodes always to use as DSADD an address derived from a 390 prefix announced by the gateway indicated as the best one by 391 routing protocol. 393 o After changing its DSADD, a node can immedately exchange data 394 traffic with hosts located both within and outside the MANET: no 395 significant delay is experienced. This because the local 396 topological information is bound to a PADD and therefore 397 independent from the DSADD currently used. This address has been 398 already announced with MID messages: all other MANET nodes already 399 know the correct path to reach the node by this address. 401 o A gateway which becomes a node, e.g. as the result of losing 402 connectivity towards the external network, can immediately receive 403 downlink traffic by using another active gateway. 405 5.2 Examples of operations 407 5.2.1 Bootstrapping of a node 409 This section gives an overview of the operations executed by a node N 410 that joins a MANET for the first time (i.e. it is bootstrapping). 412 As shown in Figure 2, the node configures its Primary Address and 413 participates to the routing protocol, sending Hellos and TCs. The 414 participation to the routing protocol lets the node to be informed of 415 the network topology (Hello and TC messages), of the gateways 416 addresses (HNA messages) and of the correspondent delegated prefixes 417 (PA messages). 419 HNA messages reception enables the node to choose its default 420 gateway, which will be used to send uplink traffic, while PA messages 421 reception enables the node to receive all the available global 422 prefixes. Among those, it chooses the best prefix and uses it to 423 build the DSADD, which is then configured on the interface. It 424 builds also a set of SADDs, one for each received prefix. At this 425 point the node is not reachable from the external network yet, as no 426 routes towards any of its SADDs have been set up by the MANET nodes. 427 The node starts sending MID messages containing the whole list of the 428 SADDs. 430 Only after MID messages diffusion, the node can receive traffic 431 incoming from the external network (as all MANET nodes own a route to 432 its global address) and can therefore start transmitting data to 433 external hosts. 435 +------+ +-------+ +----+ +----------+ 436 | N | | MANET | | GW | | Internet | 437 +------+ +-------+ +----+ +----------+ 438 | | | | 439 +----------+| | | | 440 |Configures|| | | | 441 | PADD || | | | 442 +----------+| | | | 443 | Hello | | | 444 |<----------->| | | 445 | TC | | | 446 |<----------->| | | 447 | | | | 448 | | | | 449 +----------+| HNA | | 450 | Receives ||<--------------------------| | 451 |PA and HNA|| | | | 452 | messages || PA | | 453 +----------+|<--------------------------| | 454 | | | | 455 +----------+| | | | 456 | Builds || | | | 457 | SADD || MID | | 458 |Configures||-------------------------->| | 459 | DSADD || | | | 460 +----------+| | | | 461 | | | | 462 |<--------------------------O--------------| +----------+ 463 | | | Traffic | 464 |---------------------------O------------->| | with | 465 | external | 466 | hosts | 467 +----------+ 469 Figure 2: Bootstrapping of a node 471 5.2.2 Gateway change 473 In Figure 3 it is represented the message flow triggered by a node N, 474 connected to a MANET endowed with two gateways GW1 and GW2. The 475 Secondary Addresses built by node N are two: SADD1 (derived by 476 gateway GW1 delegated prefix) and SADD2 (derived by gateway GW2 477 delegated prefix). It is assumed that the node is using SADD1 478 (according to a best prefix selection method not specified). It is 479 worth noting that as soon as node N receives PA messages, it can 480 start using SADD1 and sending MID messages at the same time. 482 After the failure of GW1, the Secondary Address SADD1 used by node N 483 is no more valid: node N then stops using SADD1 and starts using the 484 other globally valid Secondary Address, i.e. SADD2: all the other 485 MANET nodes already own a route towards such address as it was 486 inserted into MID messages generated by N, which can start a new 487 communication towards the internet without experiencing significant 488 delay due to the address change. 490 +-----+ +-------+ +-----+ +-----+ +----------+ 491 | N | | MANET | | GW1 | | GW2 | | Internet | 492 +-----+ +-------+ +-----+ +-----+ +----------+ 493 +----------+| | | | | 494 |Configures|| | | | | 495 | PADD || | | | | 496 +----------+| | | | | 497 | Hello | | | | 498 |<----------->| | | | 499 | TC | | | | 500 |<----------->| | | | 501 | | | | | 502 +----------+| HNA/PA | | | 503 | Receives ||<-------------------------| | | 504 |PA and HNA|| | | | | 505 | messages || HNA/PA | | | 506 +----------+|<-----------------------------------| | 507 | | | | | 508 +----------+| | | | | 509 | Builds || | | | | 510 |SADD1 and || | | | | 511 | SADD2 || MID(SADD1,SADD2) | | | 512 +----------+|------------------------->| | | 513 | MID(SADD1,SADD2) | | | 514 |----------------------------------->| | 515 +----------+| | | | | 516 |Configures|| | | | | 517 | SADD1 || | | | | 518 |as DSADD || | | | | 519 +----------+| | | | | 520 |<-------------------------O----------------------| 521 |--------------------------O--------------------->| 522 | | | | | 523 | | +-----------+ | | 524 | | | GW1 fails | | | 525 | | +-----------+ | | 526 +----------+| | | | 527 |Configures|| | | | 528 | SADD2 || | | | 529 |as DSADD || | | | 530 +----------+| | | | 531 |<-----------------------------------O------------| 532 |------------------------------------O----------->| 533 | MID(SADD2) | 534 |----------------------------------->| 536 Figure 3: Gateway change 538 6. Data structures 540 In this section the OLSR data structures used by the proposed 541 solution are detailed. One of these structures, namely the Multiple 542 Interface Association Information Base, is defined in [RFC3626]: the 543 present specification modifies the semantics of one of its fields. 545 6.1 Prefix Information base 547 The Prefix Information Base (PIB) contains the delegated prefixes 548 announced by gateways within the MANET and it is filled processing 549 Prefix Advertisements. It is maintained by each node and gateway. 551 Entries of the PIB have the following structure: 553 +--------------+----------------------------------------------------+ 554 | Field | Data | 555 +--------------+----------------------------------------------------+ 556 | P_address | Primary Address of the gateway which sent the PA | 557 | | | 558 | P_network | A prefix owned by the gateway whose PADD is | 559 | | specified in P_address | 560 | | | 561 | P_prefix_len | Length of the prefix contained in P_network field | 562 | gth | | 563 | | | 564 | P_time | Validity time | 565 +--------------+----------------------------------------------------+ 567 Table 1: Prefix Information Base (PIB) 569 6.2 Delegated Prefixes Information Base 571 Each gateway owns one or more global prefixes to be announced within 572 the MANET. Delegated Prefix Information Base, maintained only by 573 gateways, contains such prefixes. How the table is filled is out of 574 scope of this specification. Prefixes contained in this table are 575 inserted in Prefix Advertisements, sent out by gateways. 577 Entries of the Delegated Prefixes Information Base have the following 578 structure: 580 +--------------+----------------------------------------------------+ 581 | Field | Data | 582 +--------------+----------------------------------------------------+ 583 | P_network | A prefix delegated to the gateway | 584 | | | 585 | P_prefix_len | Length of the prefix contained in P_network field | 586 | gth | | 587 +--------------+----------------------------------------------------+ 589 Table 2: Delegated Prefixes Information Base 591 6.3 Secondary Addresses Information Base 593 The Secondary Addresses Information Base (SAIB) is the set of the 594 Secondary Addresses built by a node. It is maintained on each node 595 and gateway. The Secondary Addresses stored by a node are those 596 built processing Prefix Advertisements carrying global prefixes, i.e. 597 using global prefixes contained into PIB. The refresh of its entries 598 tightly depends on the state of the entries of PIB, as the validity 599 of a Secondary Address is bound to the validity of the global prefix 600 from which the Secondary Address has been derived. 602 Entries of the Secondary Addresses Information Base have the 603 following structure: 605 +--------------+----------------------------------------------------+ 606 | Field | Data | 607 +--------------+----------------------------------------------------+ 608 | S_Address | A valid global IPv6 address, owned by a node | 609 +--------------+----------------------------------------------------+ 611 Table 3: Secondary Addresses Information Base 613 DSADD is chosen among the addresses contained into this Base, using 614 one of the algorithms detailed in Section 7.5. 616 6.4 Multiple Interface Association Information Base 618 Multiple Interface Association Information Base is defined in 619 [RFC3626] and is filled processing MID messages. [RFC3626] mandates 620 that these messages are generated by a MANET node only when it is 621 equipped with multiple physical interfaces, through which it is 622 connected to the MANET and participates to OLSR. MIDs contain the 623 addresses configured on the node's physical interfaces. The node is 624 identified by multiple valid IPv6 addresses, one for each interface 625 connected to the MANET: Multiple Interface Association Information 626 Base contains bindings between such addresses and the main address of 627 the node. Using this table, MANET nodes can set-up routes not only 628 towards main address of other nodes, but also towards multiple 629 interface addresses associated to main address. Following [RFC3626], 630 a node connected to the MANET by means of a single interface MUST NOT 631 generate MIDs. 633 In this specification, as described in Section 7.4, MID messages 634 generated by a node contain the list of the Secondary Addresses, i.e. 635 the list of all the global addresses the node may configure on its 636 MANET interface. The Multiple Interface Association Information Base 637 is maintained by each node and gateway and is used to store the 638 bindings between the Secondary Addresses and Primary Addresses of 639 other nodes. 641 It is worth noting that the semantics of the entries in Multiple 642 Interface Association Information Base, as well as of MID messages, 643 is changed by this specification, since multiple Secondary Addresses 644 can be configured on a single interface. This semantic change has no 645 effect on the processing of MID messages and it is completely 646 backward-compatible: in fact, from a node's perspective, addresses 647 announced in MID messages can be single addresses configured on 648 multiple interfaces, or multiple addresses configured on a single 649 interface. Routing table construction rules are not changed: nodes 650 build necessary routes to both primary and secondary addresses 651 following [RFC3626]. 653 Hence, Multiple Interface Association Information Base entries have 654 the following semantics (same as specified in [RFC3626]): 656 +--------------+----------------------------------------------------+ 657 | Field | Data | 658 +--------------+----------------------------------------------------+ 659 | I_iface_addr | a Secondary Address built (and possibly | 660 | | configured) by a node | 661 | | | 662 | I_main_addr | the Primary Address of the node which has built | 663 | | the Secondary Address contained into I_iface_addr | 664 | | field | 665 | | | 666 | I_time | Validity time | 667 +--------------+----------------------------------------------------+ 669 Table 4: Multiple Interface Association Information Base 671 7. Detailed operations 673 This section gives the complete description of the operations MANET 674 devices must execute in order to build a SADD. Procedures are 675 detailed for nodes running OLSR ([RFC3626]), but mechanism can though 676 be generalized for other routing protocols. 678 7.1 IPv6 Addresses generation 680 An IPv6 address is obtained by a node by attaching a prefix (both 681 local-scoped and global) to the unique 64-bit interface identifier. 682 According to [RFC3513], this identifier can be an End-System Unique 683 Identifier, EUI-64 identifier, e.g. derived from the MAC address of 684 the node. In [I-D.dupont-ipv6-imei] the International Mobile 685 Subscriber Identity of a SIM-card is used for this purpose. 687 7.2 Primary Address configuration 689 At bootstrap, each node builds an IPv6 address and uses it as Primary 690 Address (PADD), i.e. PADD is the OLSR Main Address and will be 691 inserted into the Originator Address field of all sent OLSR messages. 692 The PADD can be generated as described in Section 7.1 using mechanism 693 detailed in [I-D.ULA] to obtain the prefix. It is worth noting that 694 uniqueness of ULAs is not guaranteed, especially if they are locally 695 generated. Therefore, PADD uniqueness MUST be verified by the 696 configuring node, by means of one DAD method, not specified in this 697 document. 699 7.3 Prefix Advertisement 701 Prefix Advertisement messages are transmitted by gateways and contain 702 their delegated prefixes. Such messages are received by nodes 703 partecipating to routing protocol. 705 7.3.1 Prefix Advertisement (PA) messages format 707 The new message type defined to announce the delegated prefixes 708 associated to the MANET is shown in Figure 4 together with OLSR 709 message header 710 0 1 2 3 711 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Message Type | Vtime | Message Size | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | | 716 | Originator Address | 717 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Time To Live | Hop Count | Message Sequence Number | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Prefix Length | Reserved | 722 +---------------------------------------------------------------+ 723 | | 724 | Network Address | 725 | | 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Prefix Length | Reserved | 729 +---------------------------------------------------------------+ 730 | | 731 | Network Address | 732 | | 733 | | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Figure 4: Format of Prefix Advertisement messages 738 Where each field of the message has the following meaning: 740 +---------------------+---------------------------------------------+ 741 | Field | Data | 742 +---------------------+---------------------------------------------+ 743 | Message Type | [TBD] | 744 | | | 745 | Vtime | PA_HOLD_TIME | 746 | | | 747 | Message Size | see [RFC3626] | 748 | | | 749 | Originator Address | the Primary Address of the node (gateway) | 750 | | which generated the message | 751 | | | 752 | Time To Live | see [RFC3626] | 753 | | | 754 | Hop Count | see [RFC3626] | 755 | | | 756 | Message Sequence | see [RFC3626] | 757 | Number | | 758 | | | 759 | Prefix Length | the length of the prefix contained in | 760 | | Network Address field | 761 | | | 762 | Network Address | the delegated prefix of the gateway which | 763 | | generated the message | 764 +---------------------+---------------------------------------------+ 766 Table 5: Prefix Advertisement Fields 768 7.3.2 PA message generation 770 A PA message is sent by a gateway in the network to announce its 771 delegated prefixes. I.e., the PA message contains the list of global 772 prefixes which are associated to it. The list of prefixes can be 773 partial in each PA message (e.g., due to message size limitations, 774 imposed by the network), but parsing of all PA messages describing 775 the interface set from a node MUST be complete within a certain 776 refreshing period (PA_INTERVAL). The information contained in the PA 777 messages is used by the nodes to build their Secondary Addresses. 779 7.3.3 PA message forwarding 781 Upon receiving a PA message, following the rules of Section 3 of 782 [RFC3626], the message MUST be forwarded according to Section 3.4 of 783 [RFC3626]. 785 7.3.4 PA message processing 787 Upon processing a PA message, the P_time MUST be computed from the 788 Vtime field of the message header (see [RFC3626]). The PIB SHOULD 789 then be updated as follows: 791 1. If the sender interface (Note: not the originator) of this 792 message is not in the symmetric 1-hop neighborhood of this node, 793 the message MUST be discarded. 795 2. Otherwise, for each (Network Address, Prefix Length) pair in the 796 message: 798 1. if an entry in the association set already exists, where: 800 P_addr == Originator Address 802 P_network_addr == Network Address 804 P_prefix_length == Prefix Length 806 then the holding time for that entry MUST be set to: 808 P_time = current time + validity time 810 2. otherwise, a new entry MUST be recorded with: 812 P_gateway_addr = Originator Address 814 P_network_addr = Network Address 816 P_prefix_length = Prefix Length 818 P_time = current time + validity time 820 7.3.5 Secondary Addresses Information Base Management 822 For each (valid) prefix contained into Prefix Information Base, the 823 node builds a Secondary Address as described in Section 7.1 and 824 inserts it into the Secondary Address Information Base. 826 If a t-uple contained into Prefix Information Base is removed, e.g. 827 after P_time expiration, the Secondary Address derived from the 828 prefix contained into the removed t-uple MUST be removed from the 829 Secondary Address Information Base. 831 7.4 MID messages 833 By means of standard MID messages processing, when OLSR eventually 834 converges, the node is reachable at any of its Secondary Addresses : 835 MANET nodes' routing tables contain a route for each secondary 836 address listed into MID messages. A packet whose destination is one 837 of the secondary addresses of a node (e.g. traffic from external 838 hosts to MANET nodes) can therefore be routed within the MANET. 839 Return traffic will be destined to such secondary address and will be 840 routed within the MANET by means of the topological information 841 inserted into MID messages. 843 7.4.1 MID message generation 845 A MID message is sent by a node in the network to announce its 846 Secondary Addresses. I.e., the MID message contains the list of the 847 Secondary Addresses which have been built by it and inserted into 848 SAIB. The list of Addresses can be partial in each MID message 849 (e.g., due to message size limitations, imposed by the network), but 850 parsing of all MID messages describing the Secondary Information Base 851 of a node MUST be complete within a certain refreshing period 852 (MID_INTERVAL). The information contained in the MID messages is 853 used by the nodes to route packets, which may be destined to one (or 854 more) of the Secondary Addresses, chosen by a node to communicate 855 with hosts located outside the MANET. 857 7.4.2 MID message forwarding 859 Upon receiving a MID message, following the rules of section 3 of 860 [RFC3626], the message MUST be forwarded according to section 3.4 of 861 [RFC3626]. 863 7.4.3 MID message processing 865 MID messages are processed as described in [RFC3626]. The tuples in 866 the multiple interface association set are recorded with the 867 information that is exchanged through MID messages. Upon receiving a 868 MID message, the "validity time" MUST be computed from the Vtime 869 field of the message header (as described in Section 3.3.2 of 870 [RFC3626]). The Multiple Interface Association Information Base 871 SHOULD then be updated as follows: 873 1. If the sender interface (note: not the originator) of this 874 message is not in the symmetric 1-hop neighborhood of this node, 875 the message MUST be discarded. 877 2. For each Secondary Address listed in the MID message: 879 1. If there exist some tuple in the interface association set 880 where: 882 I_iface_addr == Secondary Address, AND 884 I_main_addr == Originator Address, 886 then the holding time of that tuple is set to: 888 I_time = current time + validity time. 890 2. Otherwise, a new tuple is recorded in the interface 891 association set where: 893 I_iface_addr = Secondary Address, 895 I_main_addr = Originator Address, 897 I_time = current time + validity time. 899 7.5 Global IPv6 Address configuration for MANET nodes 901 A node uses one of the SADDs as its DSADD, i.e. the global IPv6 902 address used to exchange data traffic with other MANET nodes, as well 903 as with external hosts. The choice of the global address must be 904 executed at bootstrap time, after a node receives the first global 905 prefixes. Nevertheless, this operation SHOULD also be executed when 906 particular events trigger a topological change in the MANET. Such 907 events have been cited in Section 5 and can be further detailed as 908 follows: 910 1. The failure or the departure of the gateway owning the chosen 911 prefix; 913 2. A partition, after which the node and the gateway owning the 914 chosen prefix are connected to two different MANETs; 916 3. The gateway, which announces the chosen prefix, becomes a node, 917 e.g. after shutting down the interface connecting it to the 918 external network and stops announcing prefixes; 920 4. After a movement of one or more MANET devices, a gateway has a 921 better metric than the gateway announcing the chosen prefix; 923 5. A merging occurs, after which a gateway previously not connected 924 to the MANET may have the best metric value. 926 In case of events 1., 2. and 3. the global prefix, which the used 927 SADD is derived from, is no more listed into PA messages and 928 therefore is removed from Prefix Information Base: the node MUST 929 change its global address, choosing one of the prefixes announced by 930 active gateways. In case of 4. and 5., the node determines that its 931 DSADD is derived from a prefix which is no more the best one, 932 according to the the topological information it owns: in this cases, 933 the node MAY change its DSADD, although it is still valid. A number 934 of methods can be applied, to enable a node to choose its best 935 prefix, among those announced by active gateways. Next section 936 details two of such algorithms. 938 7.5.1 Best Prefix Selection Algorithm 940 The best prefix selection algorithm must take into account factors 941 related to MANET topology, e.g. the routing metrics of the gateways 942 and external factors, e.g. the number and type of active data 943 sessions. It is assumed that a node, inspecting the routing table, 944 monitors the current metric value of every reachable gateway 945 generating PA messages and always knows which is the current deafult 946 gateway. In this section two alternative algorithms are proposed. 948 1. Default Gateway Method: a node always selects the prefix 949 announced by the current Default Gateway. 951 As in this document the solution is OLSR-based, the default 952 gateway is the closest gateway in terms of number of hops. This 953 algorithm solves the downlink path optimization problem described 954 in Section 4. In fact, if the node uses a global IPv6 address 955 derived from the prefix announced by the default gateway, traffic 956 to and from the external network flows through the same gateway. 957 As a disadvantage, if MANET topology frequently changes, a node 958 using this algorithm may experience frequent address changes, 959 which can cause disruption of data sessions. 961 2. Threshold Method: a node compares the metric value of the gateway 962 announcing the prefix currently used with that of the best 963 gateway (normally, the default gateway); if the absolute value of 964 the difference of the two metrics is higher than a predefined 965 threshold, an address change is triggered; the new address is 966 derived from the prefix announced by the best gateway. 968 Choosing one value of the threshold for many deployment 969 environments can be difficult: it highly depends on the chosen 970 metric and other factors, which do not strictly depend on 971 routing, e.g. Quality of Service required by applications, how 972 many active data sessions the node will tear down after address 973 change. 975 7.5.2 Address change 977 If an address change is triggered by one of the events listed in the 978 previous Section, a node executes the following operations: 980 o It stops using the SADD which was previously used as DSADD 982 o Starts using as DSADD the SADD derived from the prefix announced 983 by the new best gateway (this SADD has been already disseminated 984 in the MANET using MIDs). 986 7.6 Gateway operations 988 As described in Section 3, a gateway is a MANET node, equipped with a 989 MANET interface, and a second interface, connected to the external 990 network. Therefore, gateways have at least one global IPv6 address, 991 belonging to the external network and used on the external interface. 992 While the mechanism, by which such address is acquired, is out of 993 scope of this specification, the configuration of the global address 994 used on the MANET interface is described in this section. 996 Gateways MUST configure the global IPv6 address of their MANET 997 interface using the mechanism specified in Section 6 and Section 7: a 998 gateway MUST execute the operations described in these sections for 999 MANET nodes. Gateways MUST always select the prefix contained into 1000 Delegated Prefixes Information Base to derive global address they 1001 will use on MANET interface. Finally, gateways MUST process PAs 1002 received from other gateways, generate SADDs and disseminate them 1003 with MIDs. 1005 As described in Section 5.1, a gateway can change its mode of 1006 operations, becoming a node, for a number of reasons, e.g. because it 1007 has lost connectivity with the external network or because of its 1008 secondary interface failure. When a gateway becomes a node, it stops 1009 generating PA messages and executes the operations described in 1010 Section 7.5.1 and Section 7.5.2. In particular, it chooses the 1011 secondary address corresponding to the best active gateway as DSADD. 1013 Since the gateway has already disseminated its new global address as 1014 a SADD in MIDs, it can communicate with the hosts located outside the 1015 MANET with negligible latency. 1017 8. Mobile IPv6 Considerations 1019 According to the proposed solution (Section 7.5.1), a node can change 1020 its DSADD for many reasons, e.g. in order to optimize downlink 1021 traffic coming from external hosts: generally, such address change 1022 implies active sessions interruption. In order to cope with this, 1023 Mobile IPv6 [RFC3775] can be used. 1025 It is worth noting that the reduction (ideally to zero) of the 1026 latency introduced by a DSADD change implies better performances when 1027 MANET nodes use MIPv6. In fact, if a node experiments a change from 1028 a gateway to a second gateway, then it chooses a secondary address as 1029 DSADD, associated to the second gateway, and it sends a Binding 1030 Update message, registering the new chosen address as the new Care-of 1031 Address. When the Binding Acknowledge message from the Home Agent 1032 arrives at the gateway, immediately a route to the node will be 1033 available, because the new Care-of Address was announced in the MANET 1034 using the MID messages. Therefore handover latency is reduced to 1035 the time needed to send a Binding Update message and receive the 1036 correspondent Binding Acknowledge message, because routing latency is 1037 negligible. 1039 9. Proposed Values for Constants 1041 9.1 Emission Intervals 1043 PA_INTERVAL = 5 seconds 1045 MID_INTERVAL = 5 seconds 1047 9.2 Holding Time 1049 PA_HOLD_TIME = 3 x PA_INTERVAL 1051 MID_HOLD_TIME = 3 x MID_INTERVAL 1053 10. Security Considerations 1055 TBD. 1057 11. IANA Considerations 1059 This document has no actions for IANA. 1061 12. References 1063 12.1 Normative references 1065 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1066 (IPv6) Specification", RFC 2460, December 1998. 1068 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1069 Discovery for IP Version 6 (IPv6)", RFC 2461, 1070 December 1998. 1072 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1073 Autoconfiguration", RFC 2462, December 1998. 1075 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1076 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1078 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 1079 Protocol (OLSR)", RFC 3626, October 2003. 1081 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1082 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1083 December 2003. 1085 12.2 Informative References 1087 [4G-INT] Siebert, M., "On Ad Hoc Networks in the 4G Integration 1088 Process", Med-Hoc 2004 , June 2004. 1090 [AMBNET] "Ambient Networks", http://www.ambient-networks.org . 1092 [BELDING] Sun, Y. and E. Belding-Royer, "A study of dynamic 1093 addressing techniques in mobile ad hoc networks", 1094 I-D Wireless communication and mobile computing, May 2004. 1096 [CHA] Cha, H., Park, J., and H. Kim, "Extended Support for 1097 Global Connectivity for IPv6 Mobile Ad Hoc Networks", 1098 I-D draft-cha-manet-extended-support-globalv6-00.txt, 1099 October 2003. 1101 [DSR] Johnson, D., Maltz, D., and Y. Hu, "The Dynamic Source 1102 Routing Protocol for Mobile Ad Hoc Networks (DSR)", 1103 I-D draft-ietf-manet-dsr-10.txt, July 2004. 1105 [ENGELSTAD] 1106 Engelstad, P., T?sen, A., Hafslund, A., and G. Egeland, 1107 "Internet Connectivity for Multi-Homed Proactive Ad Hoc 1108 Networks", First IEEE International Conference on Sensor 1109 and Ad hoc Communications and Networks , October 2004. 1111 [I-D.ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1112 Addresses", draft-hinden-ipv6-global-local-addr-09 (work 1113 in progress), January 2005. 1115 [I-D.dupont-ipv6-imei] 1116 Dupont, F. and L. Nuaymi, "IMEI-based universal IPv6 1117 interface IDs", draft-dupont-ipv6-imei-08 (work in 1118 progress), October 2004. 1120 [I-D.ruffino-conn-scenarios] 1121 Ruffino, S., "Connectivity Scenarios for MANET", 1122 draft-ruffino-conn-scenarios-00 (work in progress), 1123 February 2005. 1125 [I-D.singh-autoconf-adp] 1126 Singh, S., "Ad hoc network autoconfiguration: definition 1127 and problem statement", draft-singh-autoconf-adp-00 (work 1128 in progress), February 2005. 1130 [I-D.wakikawa-manet-ipv6-support] 1131 Wakikawa, R., "IPv6 Support on Mobile Ad-hoc Network", 1132 draft-wakikawa-manet-ipv6-support-00 (work in progress), 1133 February 2005. 1135 [JELGER] Jelger, C., Noel, T., and A. Frey, "Gateway and address 1136 autoconfiguration for IPv6 adhoc networks", 1137 I-D draft-jelger-manet-gateway-autoconf-v6-02.txt, 1138 April 2004. 1140 [JEONG] Jeong, J., Park, J., Kim, H., and D. Kim, "Ad Hoc IP 1141 Address Autoconfiguration", 1142 I-D draft-jeong-adhoc-ip-addr-autoconf-02.txt, 1143 February 2004. 1145 [PAAKKONEN] 1146 Paakkonen, P., Rantonen, M., and J. Latvakoski, "IPv6 1147 addressing in a heterogeneous MANET-network", 1148 I-D draft-paakkonen-addressing-htr-manet-00.txt, 1149 December 2003. 1151 [PERKINS] Perkins, C., Malinen, J., Wakikawa, R., and E. Belding- 1152 Royer, "IP Address Autoconfiguration for Ad Hoc Networks", 1153 I-D draft-perkins-manet-autoconf-01.txt, November 2001. 1155 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1156 September 1981. 1158 [RFC2501] Corson, S. and J. Macker, "Mobile ad hoc networking 1159 (MANET): Routing protocol performance issues and 1160 evaluation considerations", RFC 2501, January 1999. 1162 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1163 and M. Carney, "Dynamic Host Configuration Protocol for 1164 IPv6 (DHCPv6)", RFC 3315, July 2003. 1166 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1167 Demand Distance Vector (AODV) Routing", RFC 3561, 1168 July 2003. 1170 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 1171 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 1172 RFC 3684, February 2004. 1174 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1175 in IPv6", RFC 3775, June 2004. 1177 [SINGH] Singh, S., Kim, JH., Choi, YG., Kang, KL., and YS. Roh, 1178 "Mobile multi-gateway support for IPv6 mobile ad hoc 1179 networks", I-D draft-singh-manet-mmg-00.txt, June 2004. 1181 [WAKI-GLOBAL6] 1182 Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A., and 1183 A. Tuominen, "Global connectivity for IPv6 Mobile Ad Hoc 1184 Networks", I-D draft-wakikawa-manet-globalv6-03.txt, 1185 October 2003. 1187 [WWRF] "World Wireless Research Forum", 1188 http://www.wireless-world-research.org . 1190 [ZEROCONF] 1191 Aboba, B., "Dynamic Configuration of Link-Local IPv4 1192 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in 1193 progress), July 2004. 1195 Authors' Addresses 1197 Simone Ruffino 1198 Telecom Italia LAB 1199 Via G.Reiss Romoli 274 1200 Torino 10148 1201 Italy 1203 Phone: +39 011 228 7566 1204 Email: simone.ruffino@telecomitalia.it 1206 Patrick Stupar 1207 Telecom Italia LAB 1208 Via G.Reiss Romoli 274 1209 Torino 10148 1210 Italy 1212 Phone: +39 011 228 5727 1213 Email: patrick.stupar@telecomitalia.it 1215 Appendix A. Acknowledgments 1217 The authors would like to thank Ivano Guardini for his valuable 1218 comments. 1220 Intellectual Property Statement 1222 The IETF takes no position regarding the validity or scope of any 1223 Intellectual Property Rights or other rights that might be claimed to 1224 pertain to the implementation or use of the technology described in 1225 this document or the extent to which any license under such rights 1226 might or might not be available; nor does it represent that it has 1227 made any independent effort to identify any such rights. Information 1228 on the procedures with respect to rights in RFC documents can be 1229 found in BCP 78 and BCP 79. 1231 Copies of IPR disclosures made to the IETF Secretariat and any 1232 assurances of licenses to be made available, or the result of an 1233 attempt made to obtain a general license or permission for the use of 1234 such proprietary rights by implementers or users of this 1235 specification can be obtained from the IETF on-line IPR repository at 1236 http://www.ietf.org/ipr. 1238 The IETF invites any interested party to bring to its attention any 1239 copyrights, patents or patent applications, or other proprietary 1240 rights that may cover technology that may be required to implement 1241 this standard. Please address the information to the IETF at 1242 ietf-ipr@ietf.org. 1244 Disclaimer of Validity 1246 This document and the information contained herein are provided on an 1247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1249 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1250 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1251 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1254 Copyright Statement 1256 Copyright (C) The Internet Society (2005). This document is subject 1257 to the rights, licenses and restrictions contained in BCP 78, and 1258 except as set forth therein, the authors retain all their rights. 1260 Acknowledgment 1262 Funding for the RFC Editor function is currently provided by the 1263 Internet Society.