idnits 2.17.1 draft-clausen-manet-autoconf-recommendations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 45 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2009) is 5540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Autoconf T. Clausen 3 Internet-Draft U. Herberg 4 Intended status: Informational LIX, Ecole Polytechnique 5 Expires: August 29, 2009 February 25, 2009 7 MANET Router Configuration Recommendations 8 draft-clausen-manet-autoconf-recommendations-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 29, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document describes a pragmatic set of configuration 48 recommendations for MANETs, as well as provides a rationale for why 49 these recommendations are sound. While there may be other equally 50 valid ways of configuring a MANET, the recommendations in this 51 document have the merit of being supported by an existence proof 52 (there're running networks in existence, configured according to 53 these recommendations), and they require neither modifications to the 54 IP stack nor to upper-layer protocols or applications. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 60 "OPTIONAL" in this document are to be interpreted as described in RFC 61 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Document Outline . . . . . . . . . . . . . . . . . . . . . 4 67 2. MANET Configuration Recommendations . . . . . . . . . . . . . 4 68 2.1. MANET "Node" Morphology -- Hosts and Routers . . . . . . . 5 69 2.2. MANET Interface Configuration . . . . . . . . . . . . . . 6 70 2.3. Prefixes delegated to MANET Router . . . . . . . . . . . . 7 71 3. Example MANET Configurations . . . . . . . . . . . . . . . . . 7 72 3.1. MANET Router and Single Host . . . . . . . . . . . . . . . 7 73 3.2. MANET Router and Attached Network w. Prefix Delegation . . 9 74 3.3. MANET Router and Attached Network w/o Prefix Delegation . 10 75 3.4. MANET Router with two MANET Interfaces and Attached 76 Network . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Unique MANET Interface Addresses . . . . . . . . . . . . . 13 79 4.2. /32 and /128 Prefix Lengths . . . . . . . . . . . . . . . 14 80 4.3. IP Hop Isolation . . . . . . . . . . . . . . . . . . . . . 18 81 5. Summary and Characteristics . . . . . . . . . . . . . . . . . 20 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 A MANET (Mobile Ad hoc NETwork) is, in academic circles, commonly 93 described as a variation over the following: 95 "a collection of independent nodes, communicating over a wireless, 96 capacity-restricted medium, whereby they form a multi-hop connected 97 network with no assumptions of an a-priori network infrastructure and 98 with a highly dynamic topology." 100 While such a description may be extrapolated to interesting 101 challenges for research and protocol design, such as fast-convergence 102 routing algorithms and bandwidth-economic protocols, it does little 103 to describe the exact morphology and IP configuration of the 104 "independent nodes" from which the MANET is constructed. 105 Consequently, it offers little guidance in how a "real-world" IP- 106 based MANET can be configured and deployed. 108 MANET routing protocol specification as developed by the IETF, such 109 as [RFC3626], [RFC3561], [RFC4728] and [RFC3684], stipulate internal 110 processing of such "independent nodes" as well as specify the exact 111 protocol message exchange between these, in order to allow 112 construction of routing tables. As such, these specifications allow 113 for operation of a MANET, and do provide indications as to under 114 which assumptions such operation is assumed -- but on the other hand 115 do not have as vocation to provide explicit configuration and 116 deployment guidelines for MANETs. MANET routing protocols explicitly 117 assume that all MANET nodes in a MANET are already configured, i.e. 118 that the network interfaces have appropriate IP addresses etc. 120 The purpose of this present document is to remedy that by describing 121 recommendations and considerations for configuring and deploying a 122 MANET. These considerations are characterized by adhering strictly 123 to IP -- i.e. to require no modifications to neither the protocol 124 stack nor to applications accessing the network -- and to be 125 applicable for, to the best of the authors knowledge, any MANET using 126 any choice of routing protocol from among those developed for MANETs 127 within the IETF. 129 Caveat lector: Other configurations and deployment approaches for 130 MANETs are likely possible, and should not be disregarded or 131 excluded. This document, however, describes a set of configuration 132 and deployment recommendations, which practical experience and real- 133 world deployments have shown to be feasible. Also note that this 134 document describes only the end result -- but not any process 135 (automatic or otherwise). Hence, when the term "configuration" is 136 employed, it is as a noun for "the end result". 138 1.1. Document Outline 140 Section 2 presents, without rationale, explanation or apologies, 141 recommendations for the constitution and configuration of a MANET 142 router and of a MANET. This should allow the reader to immediately 143 understand how to -- safely -- configure and deploy an IP based MANET 144 using any of the currently developed IETF MANET routing protocols. 145 This, while maintaining compatibility with all "Internet 146 applications" and with other protocols, and without requiring 147 modifications to the IP stack. 149 Section 3 shows a selection of MANET router configurations, each 150 strictly following the recommendations given in Section 2. These 151 examples are not exhaustive, but rather illustrative for the kind of 152 deployments supported by the recommendations in Section 2. 154 Section 4 explains the background and rationale for the configuration 155 recommendations presented in Section 2. For each configuration 156 recommendation, a selection of justifications are presented and 157 detailed. This should allow the reader to understand why the 158 recommendations given in Section 2 represent a reasonable and 159 operational way of configuring a MANET. 161 Section 5 concludes this document by summarizing the configuration 162 recommendations and the characteristics of a MANET configured 163 according to the recommendations given in this document. 165 2. MANET Configuration Recommendations 167 This section presents a small set of MANET configuration 168 recommendations. As indicated in Section 1, these recommendations 169 constitute an approach for which there is an existence proof that a 170 MANET so configured is both correctly functioning and one in which 171 "Internet applications" and other protocols operate unmodified 172 without requiring modifications to the IP stack. 174 Section 2.1 expands the notion of MANETs being constructed from 175 "independent nodes" into the familiar terminology on the Internet and 176 of IP networking of "Hosts" and "Routers". 178 Section 2.2 describes address configuration of MANET router 179 interfaces, and Section 2.3 how prefixes delegated to a MANET router 180 are used. 182 Caveat lector: This section explains uniquely the HOW of 183 configuration of a MANET router and a MANET. The WHY -- the 184 rationale and justification -- is given in Section 4. 186 2.1. MANET "Node" Morphology -- Hosts and Routers 188 Each "independent node" in a MANET can functionally be described 189 according to Figure 1, with the "MANET node" being composed of a 190 "MANET router" (R) with one or more "MANET interfaces" -- i.e. the 191 interface which is to be used for establishing connectivity between 192 MANET routers -- as well as zero or more interfaces towards other 193 networks or hosts on classic IP links. 195 \|/ 196 MANET interface | 197 +-----------|---------------------+ 198 | +--+------+ | 199 | | R | MANET router| 200 | +---------+ | 201 | | | | 202 | +---+ | Classical IP | 203 | | H | | links with | 204 | +---+ | hosts | 205 | _______|______ | 206 | | | | | 207 | +---+ +---+ +---+ | 208 | | H |...| H | | H | | 209 | +---+ +---+ +---+ | 210 | | 211 +---------------------------------+ 212 MANET node 214 Figure 1: MANET "node" morphology 216 Functionally, this entails that: 218 o MANET routing protocols are run over MANET interfaces only; 220 o MANET routers enable connectivity between the MANET and hosts or 221 other non-MANET networks; 223 o MANET characteristics are "isolated behind an IP hop" from hosts 224 or other networks; 226 o Applications on hosts and other networks can remain "MANET 227 unaware". 229 A MANET, therefore, looks as depicted in Figure 2: the inner cloud 230 represents where MANET routers have MANET interfaces and where only 231 MANET aware protocols operate (e.g. MANET routing protocols) -- and 232 the outer cloud represents the non-MANET-aware part of the network, 233 with hosts and other (non-MANET) networks. 235 ,.----.. _.--'''--._ 236 ___ ,' ``. ,' `. _....._ 237 _,'' ``,' +---+ +---+ ,-' `-. 238 / | H | | H | \ 239 | +---+ +---+ \ 240 | |_______| | 241 | ____| Edge | 242 , ,-' +-. ___ _.' 243 ,' +---+ ,,---../ | `'' ``. ``._ 244 ,' | H |--+ ,' +--+--+ `. \ 245 / +---+ | / +-----+ | R | \ | 246 | +----| R | +-----+ Core | | 247 `. +---+ | ' +-----+ / \ ' | 248 | | H |--+ / \ / \ `. / 249 `. +---+ | \ +-----+ +-----+ \ ,' 250 `-. \ \_| R |------| R | | -''. 251 / \ +--+--+ +-----+ ' `. 252 ,' `. | _,' \ 253 .' `-. | ,`. ,''' | 254 | `-.___.+' `..__,,,' | 255 | | / 256 \ ,-----+--. / 257 \ | | _,' 258 `. +---+ +---+ ..,-' 259 `-..____,,< | H | | H | /( / 260 \ +---+ +---+ ,' \ ,' 261 `. / `. ,' 262 `._ ,-' `-..___,,' 263 ``----'' 265 Figure 2: A MANET with routers (R) and hosts (H). The "core" consists 266 of routers that are responsible for network formation and 267 maintenance. The "edge" includes hosts and non-MANET aware networks. 269 This is akin to, say, an OSPF network, which can be depicted 270 similarly to Figure 2: Within the inner cloud, OSPF routers with NBMA 271 interfaces would be operating using protocol mechanisms suitably 272 aware of NBMA characteristics, whereas the outer cloud would contain 273 non-NBMA-aware parts of the network, such as hosts. 275 2.2. MANET Interface Configuration 277 The following summarizes the configuration constraints for MANET 278 interfaces of a MANET router: 280 o Each MANET interface on a MANET router MUST be configured with an 281 IP address which is unique, at least within the MANET. 283 o Each MANET interface MUST be configured with a prefix length of 284 /32 (for IPv4) or /128 (for IPv6). 286 2.3. Prefixes delegated to MANET Router 288 The following summarizes the configuration constraints for a prefix, 289 delegated to a MANET router: 291 o If a prefix is delegated to a MANET router, this prefix MUST NOT 292 be configured on any MANET interface. 294 o If a prefix is delegated to a MANET router, other (non-MANET) 295 interfaces MAY be configured with this prefix. 297 3. Example MANET Configurations 299 This section provides a set of illustrative examples of common MANET 300 configurations, respecting the considerations given in Section 2.2. 301 Notice that this section does not attempt to exhaustively enumerate 302 all possible MANET deployments or configurations. 304 In the examples below, IP addresses and prefixes are extracted from 305 within the private address space 192.168/16. This is for 306 illustrative purposes only. This document does not take any position 307 as to which address space is to be used for when configuring MANETs 308 or other networks. 310 3.1. MANET Router and Single Host 312 Figure 3 illustrates a MANET node consisting of a MANET router with a 313 single MANET interface and a single host. This is the typical case, 314 for example, when one has a laptop, PDA or smartphone participating 315 in the MANET: the "router" and the "host" are in that case logical 316 components within the same device, and with a single physical 317 interface. 319 The MANET node is assigned a single IPv4 address, in this case 320 192.168.1.1. This IP address is to identify both the MANET interface 321 of the MANET router as well as the host. Logically, this is 322 accomplished by configuring the interface of the MANET router as an 323 "unnumbered interface", by assigning 192.168.1.1/32 to the MANET 324 interface of the router. Traffic to the logical component that is 325 the router will typically be addressed to a well-known multicast 326 address, thus the router can distinguish between traffic to itself 327 and traffic to the logical host. 329 \|/ 330 | 192.168.1.1/32 331 +-------|--------------+ 332 | +--+--+ | 333 | | R | | 334 | +-----+ | 335 | / | 336 | / 192.168.1.1/32 | 337 | +---+ | 338 | | H | | 339 | +---+ | 340 +----------------------+ 342 Figure 3: MANET router (R) and a single internal host (H) 344 It is important to retain that the MANET interface is configured with 345 a prefix length of /32, as this is an IPv4 network -- had it been an 346 IPv6 network, the required prefix length for the MANET interfaces 347 would have been /128. 349 For administrative reasons, e.g. for the ability to aggregate routes 350 for injection into other routing domains, IP addresses assigned to 351 MANET interfaces (or prefixes delegated to MANET routers) within the 352 same MANET may be extracted from within a larger interval, say, 353 192.168.0.0/16. Even so, each MANET interface configured with an IP 354 address MUST be configured with a prefix length of /32 (IPv4) or /128 355 (IPv6) and no MANET interface may be configured with this larger 356 address interval as prefix. Notice that in this situation, the 357 address interval 192.168.0.0/16 represents the ability to aggregate a 358 set of addresses into a single entry, and is specifically *NOT* 359 related to "subnet" or "subnet prefix". 361 A complete MANET so configured might look as depicted in Figure 4. 363 _____ ,,-''''`-.. 364 ,,-' `-.._-' `._ 365 192.168.0.0/16 ,' \ 366 / \|/ \___ 367 / \|/ | `-. 368 | | +---+----+ `. 369 | +----+---+ |192.168.| | 370 | |192.168.| | 1.2/32 | | 371 _' | 1.1/32 | +--------+ / 372 / +--------+ < 373 / \|/ \ 374 | \|/ | \ 375 \ | +----+---+ \ 376 \ +----+---+ |192.168.| | 377 `. |192.168.| | 1.4/32 | | 378 `-..__. | 1.3/32 | +--------+ / 379 \ +--------+ / 380 `. ,' 381 `. _,. ,,-' 382 `--....-' `.. ,,' 383 `'-----'' 385 Figure 4: A correctly configured MANET. IP addresses within the 386 routers are those assigned to the MANET interface. Notice that while 387 all such IP addresses are extracted from the address interval 388 192.168.0.0/16, all MANET interfaces are configured with prefix 389 lengths of /32. 391 3.2. MANET Router and Attached Network w. Prefix Delegation 393 Figure 5 illustrates a MANET router with a single MANET interface and 394 an interface towards a classic IP link such as an Ethernet. The 395 MANET router is delegated the IPv4 prefix 192.168.1.0/24. That 396 prefix is assigned to the non-MANET link, on which interfaces are 397 assigned addresses such as 192.168.1.1/24, 192.168.1.2/24, 398 192.168.1.3/24 etc. Note that the interfaces on that classic IP link 399 are configured with a prefix length of /24, indicating that the 400 interfaces with addresses from within that IP prefix are all 401 reachable within a single IP hop. 403 The MANET interface is configured as an "unnumbered interface" by 404 "borrowing" the address (192.168.1.1) from its interface towards the 405 classic IP link - but is configured with the prefix length /32. The 406 MANET interface is, specifically, not configured with a prefix length 407 of /24, even though that prefix is delegated to the MANET router, as 408 the MANET interface is not able to reach all other interfaces with 409 addresses from within 192.168.1.0./24 in a single IP hop. 411 192.168.1.1/32 \|/ 412 +------------|------------+ 413 | | | 414 | +-+-----+ | 415 | | R | 192.168.1.0/24 416 | +-------+ | 417 |192.168.1.1/24 | | 418 | | | 419 +---------------+---------+ 420 | 421 ,----------+-----------. 422 | | | 423 +---+ +---+ +---+ 424 192.168.1.2/24 | H | | H | | H | 192.168.1.4/24 425 +---+ +---+ +---+ 426 192.168.1.3/24 428 Figure 5: MANET router (R) with an attached network and a delegated 429 subnet prefix. Notice that the prefix 192.168.1.0/24 is assigned to 430 the non-MANET link, where interfaces are configured with that prefix, 431 e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address 432 from that link, however is configured with a prefix length of /32. 434 Traffic to the MANET interface with the IP address 192.168.1.1 can be 435 distinguished from traffic to the non-MANET interface with the same 436 address since traffic destined to the MANET interface of the router 437 typically will be addressed to a well-known multicast address. 439 3.3. MANET Router and Attached Network w/o Prefix Delegation 441 Figure 6 shows a situation similar to that of Section 3.2 except that 442 the MANET router, for whatever reason, is not delegated any prefix. 444 As no prefix has been delegated to the MANET router, the MANET router 445 can not simply "borrow" an IP address from within a delegated prefix 446 for its MANET interface and know this IP address to be unique -- but 447 has to rely on some other mechanism for acquiring an IP address. 448 Whichever mechanism is used for acquiring this IP address, is shall 449 ensure that this IP address is unique, at least within the MANET. 451 Assuming that the MANET router has acquired the IP address 452 130.225.194.42 for use on its MANET interface, and that whatever 453 mechanism gave this IP address to the MANET router ensured that this 454 address is unique, at least within the MANET, then the MANET router 455 can be configured as in figure Figure 6. 457 130.225.194.42/32 \|/ 458 +------------|------------+ 459 | | | 460 | +-+-----+ | 461 | | R | | 462 | +-------+ | 463 | | | 464 | | | 465 +---------------+---------+ 466 | 467 ,----------+-----------. 468 | | | 469 +---+ +---+ +---+ 470 | H | | H | | H | 471 +---+ +---+ +---+ 473 Figure 6: MANET router (R) with an attached network. The router has, 474 through whichever mechanism, acquired the IP address 130.225.194.42 475 -- with which it configures its MANET interface and with a prefix 476 length of /32. At this time, no prefix is delegated to the MANET 477 router. 479 The MANET router may attempt to acquire a prefix, through whatever 480 mechanism availble on the network, for use when configuring attached 481 hosts and networks -- or may assign IP addresses from within a 482 private address space to such hosts and networks, and deploy NAT. 484 3.4. MANET Router with two MANET Interfaces and Attached Network 486 Similar to Figure 5, Figure 7 illustrates the configuration of a 487 MANET router with two MANET interfaces. In this case, the attached 488 network and one of the MANET interfaces is configured exactly as in 489 Figure 5, whereas the second MANET interface is configured using an 490 otherwise unused IP address -- in this case 192.168.1.42 -- from 491 within the 192.168.1.0/24 prefix. This interface is also configured 492 with a prefix length of /32. 494 192.168.1.1/32 \|/ \|/ 192.168.1.42/32 495 +------------|---|--------+ 496 | | | | 497 | +-+---+-+ | 498 | | R | 192.168.1.0/24 499 | +-------+ | 500 |192.168.1.1/24 | | 501 | | | 502 +---------------+---------+ 503 | 504 ,----------+-----------. 505 | | | 506 +---+ +---+ +---+ 507 192.168.1.2/24 | H | | H | | H | 192.168.1.4/24 508 +---+ +---+ +---+ 509 192.168.1.3/24 511 Figure 7: MANET router (R) with an attached network and a delegated 512 subnet prefix and two MANET interfaces. Notice that the prefix 513 192.168.1.0/24 is assigned to the non-MANET link, where interfaces 514 are configured with that prefix, e.g. 192.168.1.3/24. The MANET 515 interface "borrows" the IP address from that link, however is 516 configured with a prefix length of /32. The second MANET interface is 517 configured using an unused IP address from within the same subnet 518 prefix, in this case 192.168.1.42 -- also configured with a prefix 519 length of /32 521 Using IP addresses from within the prefix delegated to the MANET 522 router for configuring MANET interfaces on that router ensures that 523 these IP addresses are unique, at least within the MANET -- assuming, 524 of course, that the prefix delegation mechanism does not delegate the 525 same prefix to multiple MANET routers within the same network. 527 Notice that the same logic applies in this scenario as in the one in 528 Figure 5: the second MANET interface could assume any IP address from 529 within 192.168.1.0/24, even one already used by a host such as 530 192.168.1.2, as long as it is not used on another MANET interface and 531 as long as the second MANET interface is also configured with a 532 prefix length of /32. Traffic to the MANET interface with the IP 533 address 192.168.1.2 can be distinguished from traffic to the non- 534 MANET interface with the same address since traffic destined to the 535 MANET interface of the router typically will be addressed to a well- 536 known multicast address. 538 4. Rationale 540 Section 2 describes three recommendations when configuring MANET 541 routers and MANET interfaces on MANET routers: 543 o Each MANET interface on a MANET router MUST be configured with an 544 IP address which is unique, at least within the MANET; 546 o MANET interfaces MUST be configured with prefix lengths of /32 547 (IPv4) or /128 (IPv6); 549 o MANET routers MUST isolate MANET characteristics from non-MANET 550 interfaces. 552 This section provides a rationale for the configuration 553 recommendations in Section 2 by presenting the reasoning behind each 554 of these -- as well as a selection of consequences from configuring a 555 MANET router without following these recommendations. 557 In the descriptions in the following sections, IP addresses and 558 prefixes are extracted from within the private address space 559 192.168/16. This is for illustrative purposes only. This document 560 does not take any position as to which address space is to be used 561 for when configuring MANETs or other networks. 563 4.1. Unique MANET Interface Addresses 565 MANET interfaces are typically not attached to point-to-point links, 566 but are rather of a "semi-broadcast nature" such as indicated in 567 Figure 8. Hence, a packet transmitted on a MANET interface may be 568 received by any number of MANET interfaces, including the 569 transmitting MANET interface itself. 571 Communication 572 Range 573 <~~~~~~~~+~~~~~~~~> <~~~~~~~~+~~~~~~~> 574 |<~~~~~~~~+~~~~~~~~>| 575 +--|--+ +--|--+ +--|--+ 576 | A | | B | | C | 577 +-----+ +-----+ +-----+ 579 Figure 8: Example of "semi-broadcast" MANET interface 580 characteristics. The arrows indicate the transmission range for each 581 MANET interface, i.e. the range within which a transmitted packet can 582 be successfully received and decoded. 584 In order for MANET routers to be able to forward data packet not 585 destined to themselves or to directly attached non-MANET hosts or 586 networks, they need to be able to uniquely identify the "next hop" 587 for a packet. Symmetrically, in order for a MANET router to 588 discriminate between incoming data packets for it to forward (either 589 within the MANET or to an attached host or network) or to discard, it 590 needs to be able to identify if indeed it is the "next hop" for a 591 received data packet. In order to accomplish this, MANET interfaces 592 which are in direct L2 communication with each other need to be 593 configured with unique IP addresses. 595 Some MANET routing protocols employ flooding mechanisms (also 596 commonly denoted "optimized flooding") in order to reduce the 597 overhead involved in topology dissemination throughout the network. 598 Examples include [RFC3626] and [RFC5449]. Such flooding mechanisms 599 are based on each node selecting a subset of its neighbors as 600 "relays", with only these relays taking part in flooding operations. 601 Such relay selection algorithm in general require the ability to 602 uniquely identify each MANET interface up to two hops away from the 603 source; such is the case for [RFC3626] and [RFC5449]. 605 Other flooding algorithms, studied for MANETs, perform relay 606 selection requiring the ability to uniquely identify each MANET 607 interface further away -- such is the case with various non-connected 608 dominating set flooding approaches, currently a subject of research. 610 By configuring MANET interfaces such that each has a MANET-wide 611 unique address, it is ensured that both the flooding mechanisms from 612 the current crop of MANET routing protocols, as well as potential 613 future developments, are supported. 615 4.2. /32 and /128 Prefix Lengths 617 In early MANET deployments, a common occurrence was to configure a 618 MANET as "a subnet" and configure it as indicated in Figure 9: the 619 MANET would have a subnet prefix, say 192.168.1.0/24 and MANET 620 interfaces would be configured with this subnet prefix, e.g. 621 192.168.1.3/24. 623 Communication 624 Range 625 <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~~~+~~~~~~~~~~~~~> 626 |<~~~~~~~~~~~~+~~~~~~~~~~~~>| 627 +--------+ +--------+ +--------+ 628 |192.168.| |192.168.| |192.168.| 629 | 1.1/24 | | 1.2/24 | | 1.3/24 | 630 +--------+ +--------+ +--------+ 632 Data packet: --------------> 633 dest 192.168.1.3 634 next-hop 192.168.1.2 636 ICMP Redirect <-------------- 638 Figure 9: Misconfigured MANET: MANET interfaces configured with a 639 shared /24 prefix, causing the central router to produce an ICMP 640 redirect when forwarding packets from 192.126.1.1 to 192.168.1.3. 642 If, for example, a data packet was transmitted by the MANET router 643 192.168.1.1 to be received by 192.168.1.3, then this would -- with 644 reference to Figure 9 -- have to be forwarded by the MANET router 645 192.168.1.2. With the MANET interfaces in this MANET being 646 configured with the subnet prefix 192.168.1 and the prefix length 647 /24, it was observed that this produced ICMP redirects by 648 192.168.1.2. 650 An early, and often suggested, solution was to "treat the symptoms 651 rather than cure the disease" by disabling ICMP redirects on MANET 652 routers -- i.e. to require modifications to the IP stack operation in 653 order that it can be supporting MANETs. 655 The ICMP redirect is intended to be used to inform a source to send 656 packets using an alternative, more direct, route -- e.g. if a source, 657 s wishes to send a data packet to a destination node d via the path 658 s-R1-R2-d, and if R1 knows that a direct path s-R2-d is available, 659 then the ICMP redirect from R1 will inform s of this route. 661 Two interfaces, configured with addresses from within the same subnet 662 prefix, and with the same prefix length are defined to be reachable 663 from each other within a single IP hop. More precisely, it is 664 assumed that all interfaces with IP addresses within that subnet 665 prefix and configured with the same prefix length are directly 666 reachable from each other without forwarding by an intermediate 667 router. Hence, a way for R1 to know that a direct path may exist 668 between h and R2 is if h, R1 and R2 are configured with IP addresses 669 from within the same subnet prefix and within the same subnet prefix. 671 Returning to the MANET scenario in Figure 9, with all MANET 672 interfaces being configured with the same subnet prefix and the same 673 prefix length, it follows from the discussion above that all these 674 MANET interfaces are expected to be directly reachable from each 675 other within a single IP hop. When, in this configuration, the 676 router 192.168.1.2 is requested to forward a data packet from 677 192.168.1.1 to 192.168.1.3, it is expected that it generates an ICMP 678 redirect to 192.168.1.1 suggesting that a direct path exists from 679 192.168.1.1 to 192.168.1.3 -- as this is what the configuration 680 suggests. 682 Rather than "treating the symptoms" and disabling ICMP redirects, 683 requiring /32 and /128 prefix lengths on MANET interfaces "cures the 684 disease". An interface so configured will not make any assumptions 685 about other interfaces being within a single IP hop, and so will not 686 generate ICMP redirects when forwarding traffic. 688 An argument could be made, suggesting that for each set of MANET 689 interfaces which are all directly reachable in one IP hop from each 690 other, a shared "subnet prefix" can be assigned. Considering the 691 network from Figure 9, this could allow two "subnets" to be formed, 692 as indicated in Figure 10, with the MANET interface of the center 693 router being configured with two IP addresses (or, being configured 694 with two virtual interfaces, each with one IP address), one in each 695 of the two subnets. 697 . 698 Communication . 699 Range . 700 ~~~~~~~~~~~~+~~~~~~~~~~~~~~~~><~~~~~~~~~~~~~~~~~~~+~~~~~~~~~ 701 <~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~> 702 . 704 192.168.1.1/24 . 192.168.2.2/24 705 \ | / \ | / \ | / 706 \|/ 192.168. \|/ 192.168. \|/ 707 | 1.2/24 | 2.1/24 | 708 +--|-+ +----+ +--|-+ 709 | N1 | | N2 | | N3 | 710 +----+ +-.--+ +----+ 711 . 712 ----------------------. 713 Subnet prefix .-------------------------- 714 192.168.1.0/24 . Subnet prefix 715 . 192.168.2.0/24 717 Figure 10: MANET interfaces configured with a shared /24 subnet 718 prefixes among neighbors which can all communicate directly in one IP 719 hop. Notice that some MANET interfaces will be required to have 720 multiple IP addresses, and as the network topology changes, also 721 change their MANET interface configuration. 723 While this could be a valid configuration, considering that the "M" 724 in MANET is for "mobile", the network topology can be expected to 725 change dynamically and frequently. A network so configured would, 726 therefore, require constant "subnet formation" and "interface 727 reconfiguration", in order to maintain the configuration valid. It 728 would require (complex) mechanisms for tracking the topology dynamics 729 and would entail potentially frequent changes to MANET interface 730 address configurations. Such frequent changes of interface 731 configurations would likely also adversely affect e.g. relay 732 selection mechanisms such as those used for flooding in [RFC3626] and 733 [RFC5449]: from the point of view of a router R, even if the topology 734 within a 2 hop radius from R did not physically change (and so, no 735 relay set recalculations would be needed), the logical configuration 736 of interface addresses on a node 2 hops away from R might change 737 (e.g. due to physical topology changes to the neighborhood of that 738 node, i.e. 3 hops away from R) in order to preserve the ability of 739 having "shared prefixes" among neighboring MANET interfaces. This 740 would then potentially require relay set recalculations by R and 741 additional signaling to this effect by a routing protocol on R -- 742 even though topological changes were 3 hops away from R and such 743 recalculations and signaling would not be necessary in case MANET 744 interface addresses were kept stable. 746 Finally, as the only application(s) to be exposed to MANET interfaces 747 are MANET routing protocols and other protocols explicitly MANET 748 aware and designed for management of a MANET infrastructure, it is 749 highly questionable if there would be any benefits from introducing 750 the complexities necessary for maintaining such dynamically changing 751 "subnets" among MANET interfaces. 753 Configuring MANET interfaces with a /32 or /128 prefix length is, 754 therefore, a safe approach which entails no additional complicated 755 mechanisms or signaling, and which requires no changes to the IP 756 stack. 758 4.3. IP Hop Isolation 760 Upper-layer applications and protocols are designed with a set of 761 (often not explicitly expressed) assumptions as to the nature and 762 characteristics of the underlying network communications fabric. 763 This includes, but is not limited to, assumptions on (i) the 764 relationship between a "subnet" and the ability for interfaces 765 configured within the same subnet to all be able to communicate with 766 each other directly, i.e. in one IP hop (as evoked in Section 4.1 and 767 Section 4.2), (ii) that communication between interfaces on the same 768 link is symmetric (if interface A can receive packets from interface 769 B, then interface B can receive packets from interface A), (iii) that 770 link-local multicast (i.e. with TTL or hop-limit equal to 1) is 771 supported and is well defined (e.g. that the recipients of a link 772 local multicast from interface A is identical to those of interface 773 B, assuming that interfaces A and B are on the same link). 774 Essentially, upper-layer applications and protocols assume an 775 underlying link with characteristics similar to those of an Ethernet. 777 Over MANET interfaces, these assumptions may not hold true. Consider 778 for example the network in Figure 11. If interface A makes a link 779 local multicast transmission, then this is received by the interface 780 B -- whereas if interface B makes a link local multicast 781 transmission, then this is received by the interfaces A and C. 783 Communication 784 Range 785 <~~~~~~~~+~~~~~~~~> <~~~~~~~~+~~~~~~~> 786 |<~~~~~~~~+~~~~~~~~>| 787 +--|--+ +--|--+ +--|--+ 788 | A | | B | | C | 789 +-----+ +-----+ +-----+ 791 Figure 11: Link local multicast over MANET interfaces: without 792 forwarding, a transmission from the manet interface A reaches a 793 different set of interfaces than those for a transmission from 794 interface B (or interface C). 796 There are, essentially, four potential ways of addressing this 797 problem: requiring all upper-layer applications and protocols to 798 become "MANET aware", inventing mechanisms for presenting a MANET 799 as-if it was an Ethernet, pushing the problem to layer 2, or 800 encapsulating any MANET specific behavior in a way such that it is 801 only exposed to explicitly MANET aware applications and protocols. 803 Requiring all upper-layer applications and protocols to be reworked 804 such that they be MANET aware is impossible, due to the sheer volume 805 of such, is undesirable as a tenant of the Internet is to provide an 806 abstraction for applications from the interconnect characteristics, 807 and would likely, not be without technical problems of its own -- for 808 example, Section 4.2 exposes the complexity with respect to the 809 single problem of correctly ensuring the relationship between 810 "subnet" and which MANET interfaces are able to directly communicate. 812 Pushing the problem to layer 2, and requiring a layer 2 to present an 813 "Ethernet-like" medium would for a given layer 2 solve the problem -- 814 but do away with the ability to deploy heterogeneous MANETs, and 815 would be akin to e.g. requiring OSPF to do away with all but one 816 interface type and require all layer 2's over which OSPF is expected 817 to run to adhere to this single remaining interface type. 819 The last way of addressing this problem is to encapsulate MANET 820 specific behaviors in a way such that it only is exposed to 821 explicitly MANET aware applications and protocols. This approach has 822 several merits, not the least of which is that this is exactly the 823 way in which existing routing protocols are deployed: interfaces 824 between routers, and their characteristics, are exposed only to 825 applications and protocols which are explicitly aware of these 826 interfaces and their characteristics, with all other applications and 827 protocols being isolated from these by being connected via an 828 "Ethernet-like" link to the router -- i.e. by virtue of being 829 isolated behind an IP hop (the router). 831 For example, applications on hosts are exposed to an "Ethernet-like" 832 link with other hosts and potentially routers -- and are blissfully 833 unaware whether these routers are connected using point-to-point 834 links, NBMA links, broadcast links etc. 836 For these reasons, configuring a MANET such that the MANET router is 837 isolating the MANET interfaces and their characteristics from hosts 838 and other (non-MANET) networks by an IP hop, and requiring that on 839 MANET routers, only explicitly MANET aware applications are exposed 840 to MANET interfaces, is a safe and simple approach that entails no 841 additional complex mechanisms and signaling. This also requires no 842 changes to neither the IP stack nor the upper-layer applications and 843 protocols operating on these hosts and (non-MANET) networks. 845 5. Summary and Characteristics 847 This document proposes recommendations as to how MANETs can be 848 configured and deployed, specifically, it provides the following 849 three sets of recommendations: 851 MANET Interface Address Configuration: 853 o Each MANET interface on a MANET router MUST be configured with an 854 IP address which is unique, at least within the MANET. 856 o Each MANET interface MUST be configured with a prefix length of 857 /32 (for IPv4) or /128 (for IPv6). 859 Delegated Prefix Configuration: 861 o If a prefix is delegated to a MANET router, this prefix MUST NOT 862 be configured on any MANET interfaces. 864 o If a prefix is delegated to a MANET router, other (non-MANET) 865 interfaces MAY be configured with this prefix. 867 MANET Interface Characteristics Encapsulation: 869 o MANET interface characteristics are exposed only to explicitly 870 MANET-aware protocols and applications, such as MANET routing 871 protocols; 873 o MANET interfaces are not exposed to applications and upper-layer 874 protocols, i.e.; 876 o MANET routers provide connectivity to hosts and other (non-MANET) 877 networks via links with "Ethernet-like" link characteristics, and; 879 o MANET routers provide connectivity from hosts and other (non- 880 MANET) networks via IP routing, i.e. MANET interface 881 characteristics are "hidden behind an IP hop" from applications 882 and upper-layer protocols. 884 A MANET configured according to these recommendations has the 885 following key characteristics: 887 MANET Characteristics: 889 o It requires no modifications to the IP stack on hosts and non- 890 MANET aware networks; 892 o It requires no modifications to the IP stack on MANET routers; 894 o It requires no modifications to upper-layer applications and 895 protocols on hosts and (non-MANET) routers; 897 o It supports all MANET routing protocols, as currently developed 898 within the IETF. 900 6. IANA Considerations 902 This document has no actions for IANA. 904 7. Security Considerations 906 This document does currently not describe any security 907 considerations. 909 8. Acknowledgments 911 The considerations presented in this document are the authors 912 condensation of years of experience within and outside the IETF, from 913 studying, building, testing and deploying MANETs. 915 The authors would like to express his profound thanks to (in no 916 specific order) Dave Thaler (Microsoft), Thomas Narten (IBM), Jari 917 Arkko (Ericsson), Mark Townsley (Cisco), Chris Dearlove (BAE 918 Systems), Justin Dean (NRL), Joe Macker (NRL), Ian Chakeres (CenGen), 919 Charles E. Perkins (WiChorus), Emmanuel Baccelli (INRIA), Henning 920 Rogge (FGAN) and Ryuji Wakikawa (Toyota) for having given their 921 valuable time to participating in the (at time vivid) discussions 922 with the authors, and forming the foundation for writing this present 923 document. 925 Emmanuel Baccelli (INRIA) provided valuable proof-reading of this 926 document in its final stages. 928 9. References 929 9.1. Normative References 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, March 1997. 934 9.2. Informative References 936 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 937 Demand Distance Vector (AODV) Routing", RFC 3561, 938 July 2003. 940 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 941 Protocol (OLSR)", RFC 3626, October 2003. 943 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 944 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 945 RFC 3684, February 2004. 947 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 948 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 949 IPv4", RFC 4728, February 2007. 951 [RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet, 952 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 953 Networks", RFC 5449, February 2009. 955 Authors' Addresses 957 Thomas Heide Clausen 958 LIX, Ecole Polytechnique 960 Phone: +33 6 6058 9349 961 Email: T.Clausen@computer.org 962 URI: http://www.ThomasClausen.org/ 964 Ulrich Herberg 965 LIX, Ecole Polytechnique 967 Phone: +33 1 6933 4126 968 Email: ulrich@herberg.name 969 URI: http://www.herberg.name/