idnits 2.17.1 draft-ietf-autoconf-manetarch-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 888. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 8, 2007) is 6011 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'DWN03' is defined on line 784, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (AUTOCONF) I. Chakeres 3 Internet-Draft Motorola 4 Intended status: Informational J. Macker 5 Expires: May 11, 2008 Naval Research Laboratory 6 T. Clausen 7 LIX, Ecole Polytechnique 8 November 8, 2007 10 Mobile Ad hoc Network Architecture 11 draft-ietf-autoconf-manetarch-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 11, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document discusses Mobile Ad hoc NETworks (MANETs). It presents 45 the initial motivation for MANET and describes unaccustomed 46 characteristics and challenges. It also defines a MANET, other MANET 47 entities, and MANET architectural concepts. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Borrowed Terminology . . . . . . . . . . . . . . . . . . . 3 54 2.2. MANET Terminology . . . . . . . . . . . . . . . . . . . . 4 55 3. MANET Motivation Discussion . . . . . . . . . . . . . . . . . 6 56 3.1. Packet Radio Networks . . . . . . . . . . . . . . . . . . 6 57 3.2. Packet Radio Networks and the Internet . . . . . . . . . . 6 58 3.3. Packet Radio Networks and MANETs . . . . . . . . . . . . . 7 59 4. MANET Interface Characteristics . . . . . . . . . . . . . . . 8 60 4.1. Qualities - Wireless, Mobile, Ad hoc . . . . . . . . . . . 8 61 4.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2.1. Semi-Broadcast Interface . . . . . . . . . . . . . . . 8 63 4.2.2. Fuzzy Relationships Between Nearby MANET Routers & 64 MANET Routers' Extended Neighborhoods . . . . . . . . 9 65 4.2.3. MANET Membership . . . . . . . . . . . . . . . . . . . 10 66 5. Addressing & the MANET Prefix Model . . . . . . . . . . . . . 11 67 5.1. General Address Architecture . . . . . . . . . . . . . . . 12 68 5.2. MANET Interface Configuration . . . . . . . . . . . . . . 13 69 5.3. Routers and Hosts in a MANET . . . . . . . . . . . . . . . 13 70 6. MANETs' Place in the Network Stack . . . . . . . . . . . . . . 14 71 7. Sharing of Information Across Layers . . . . . . . . . . . . . 15 72 8. Deployment Taxonomy . . . . . . . . . . . . . . . . . . . . . 15 73 8.1. Service Availability . . . . . . . . . . . . . . . . . . . 15 74 8.2. Number of MANET Routers in a MANET . . . . . . . . . . . . 16 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 78 12. Informative References . . . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 80 Intellectual Property and Copyright Statements . . . . . . . . . . 20 82 1. Introduction 84 A Mobile Ad hoc NETwork (MANET) consists of a loosely connected 85 domain of routers. A MANET is characterized by inclusion of one or 86 more MANET interfaces; interfaces that are distinguished by their 87 potentially significant time-vary asymmetric reachability amongst 88 neighboring routers. These routers organize and maintain a routing 89 structure among themselves. These routers may communicate over 90 dynamic wireless channels with asymmetric reachability, may be 91 mobile, and may join and leave the network at any time. These 92 MANETs' characteristics create challenges in several areas. 94 This document is focused on IP networking, though many of MANETs' 95 concepts and issues span the protocol stack. 97 This document is meant to complement [RFC2501] in describing and 98 defining MANET. 100 2. Terminology 102 Owing to the fact that a MANET, as described in this document, is an 103 instance of an IP network, much of the terminology employed in this 104 document is borrowed from existing documents. Some of the documents 105 that contain relevant terminology are [RFC1812], [RFC2328], 106 [RFC2453], [RFC2460], [RFC4861], [RFC4291], [RFC3753], and [RFC4903]. 107 In some cases the terminology is slightly abbreviated or rephrased; 108 although, every effort made to retain the meanings. Borrowed 109 terminology is provided in Section 2.1 with the intent of providing a 110 complete discussion of MANETs using coherent terminology. MANET 111 specific terminology is provided in Section 2.2. 113 2.1. Borrowed Terminology 115 This document employs the following definitions: 117 Node (N) 118 any device (router or host) that implements IP. 120 Router (R) 121 a node that forwards IP packets not explicitly addressed to 122 itself. 124 Host (H) 125 any node that is not a router, i.e. a host does not forward 126 packets addressed to others. 128 Link 129 a communication facility or medium over which nodes can 130 communicate at the link layer, i.e., the layer immediately below 131 IP. Examples are Ethernets (simple or bridged), PPP links, X.25, 132 Frame Relay, or ATM networks as well as internet (or higher) layer 133 "tunnels", such as tunnels over IPv4 or IPv6 itself. 135 Asymmetric Reachability 136 Asymmetric reachability describes two properties of certain 137 interface types' underlying communication facilities. First, non- 138 transitive communication means packets from X can reach Y, and 139 packets from Y can reach Z, but packets from X may not reach Z. 140 Second, non-bidirectional communication means that packets from X 141 can reach Y but packets from Y may not reach X. Many radio/ 142 wireless interfaces exhibit these properties. 144 Neighbor 145 In the context of routing, two routers are neighbors if one can 146 send/receive routing protocol IP packets to the other without 147 passing through any intermediaries at the same layer. 149 Interface 150 A node's point of attachment to a communication link. 152 Semi-Broadcast Interface (SBI) 153 A broadcast capable interface that may exhibit asymmetric 154 reachability. Multiple access wireless radio interfaces are often 155 SBI. Note that since a SBI *may* exhibit asymmetric reachability, 156 it also may not. 158 Routing Domain (Domain) 159 A routing domain is an interconnected network with a coherent 160 routing policy and a consistent metric framework. 162 Border Router (BR) 163 A border router participates in multiple routing domains, and 164 often multiple routing protocols. A BR defines the border between 165 its multiple routing domains. A BR is responsible for presenting 166 a consistent picture of the nodes reachable through itself to each 167 routing domain. A BR determines the routing information to 168 propagate between different routing domains. 170 2.2. MANET Terminology 172 The following terminology is specific to MANETs: 174 MANET Interface 175 A MANET interface is distinguished by its potentially significant 176 time-varying asymmetric reachability (e.g., SBI) amongst potential 177 neighboring routers. A more detailed discussion of MANET 178 interface characteristics is presented in Section 4.2. The 179 addressing constraints for a MANET interface are discussed in 180 Section 5.2. 182 MANET Router (MNR) 183 A MANET router is distinguished by having one or more MANET 184 interfaces. A MANET router may also have zero or more non-MANET 185 interfaces. A MANET router is responsible for hiding MANETs' 186 challenging characteristics from nodes that are not MANET-aware. 187 A MANET router with a single MANET interface is illustrated in 188 Figure 1. 190 MANET Neighborhood 191 a set of neighboring routers that can communicate via MANET 192 interfaces without passing through any other routers 193 (intermediaries at the same layer). 195 MANET 196 a routing domain containing MANET routers. A example MANET is 197 illustrated in Figure 3. 199 <~~~~~~+~~~~~~> MANET 200 | Interface 201 ''''''''''''' 202 ' MANET ' 203 ' Router ' 204 ''''''''''''' 206 Figure 1: MANET Router with One MANET Interface 208 Dependent upon the deployment and management strategy, coalescing and 209 fragmentation of MANETs may be a supported feature. In other words, 210 if a communication path between two previously separated MANET 211 routers or MANETs becomes available, the two MANETs may merge to form 212 a single larger MANET. Similarly, if a communication path between 213 two MANET routers disappears and no alternative path between the 214 routers exists, then the MANET may be partitioned into two separate 215 MANETs. 217 When discussing MANETs' connectivity to other networks, such as the 218 Internet, a MANET is bounded by border routers (BR). That is, a 219 MANET's BR form a border between a MANET and other routing domains. 221 3. MANET Motivation Discussion 223 The Internet Protocol (IP) core design tenets -- connectionless 224 networking and packet-based forwarding -- are ideally suited for use 225 in highly dynamic contexts, such as MANETs. Yet, some additional 226 functionality is required to meet the unique challenges and 227 opportunities present in MANETs. 229 3.1. Packet Radio Networks 231 The initial motivation for MANETs was called Packet Radio (PR) 232 networking [FL01]. In PR, each router is equipped with a single 233 wireless interface. Each router may be mobile, and the routers may 234 be or may become spatially distributed such that all routers cannot 235 communicate directly. That is, two routers might require one or more 236 intermediate routers to forward (route) packets on their behalf. In 237 the example shown in Figure 2: for PR1 to send packets to PR3, the 238 intermediary PR2 must relay the packets. This implies that PR2 must 239 receive the packet from PR1 on its interface and determine that it 240 must retransmit the packet over the same interface as the one where 241 the packet was received, in order for the packet to reach PR3. From 242 the point of view of PR2, both PR1 and PR3 are neighboring routers, 243 whereas PR1 and PR3 are not themselves neighboring routers of one 244 another. 246 Communication 247 Range 248 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 249 Single | <~~~~~~+~~~~~~> | 250 MANET +-|-+ +-|-+ +-|-+ 251 Interface |PR1| |PR2| |PR3| 252 +---+ +---+ +---+ 254 Figure 2: Basic Packet Radio Network 256 3.2. Packet Radio Networks and the Internet 258 Packet Radio networks inspired several architecture related 259 challenges, including how to interconnect Packet Radio networks and 260 other networks, especially fixed networks like the ARPANET. Another 261 related challenge was how to deal with the large disparity between 262 different node and interface characteristics present in different 263 networks. 265 These aspects of Packet Radio networks helped stimulate the early 266 development of the Internet Protocol; an architecture based on 267 connectionless networking and packet-based forwarding that enables 268 interconnection of heterogeneous devices over heterogeneous 269 communication technologies. 271 3.3. Packet Radio Networks and MANETs 273 The router configuration in Figure 1 is the simplest MANET router 274 configuration: a single interface exhibiting MANET interface 275 characteristics. Many other challenges exist, in MANETs and in 276 Packet Radio Networks both: wireless interfaces imply shared 277 communication resources which result in interdependence between 278 nearby nodes, and these nodes often communicate directly or 279 indirectly. Wireless channel statistical dynamics and node mobility 280 may result in frequent packet channel losses and network topology 281 changes. 283 Figure 3 shows a general schematic of a MANET: each MANET Router 284 (MNR) has one or more MANET interfaces, over which MANET interface 285 aware protocols operate to ensure MANET communication; and zero or 286 more non-MANET participating interfaces, either towards hosts or 287 other networks. Over these non-MANET aware interfaces protocols need 288 not be aware of MANETs' characteristics. 290 +---+ 291 |MNR| 292 +-|-+ 293 +-+ +---+ / /|\ \ +---+ +-+ 294 | |...MNR--- .-. ---MNR|..| | 295 +-+ +---+ \ ,-( _)-. / +---+ +-+ 296 .-(_ MANET )-. 297 Other ( Communication ) 298 Nodes `-(______)-' 299 and \|/ \|/ 300 Networks +-|-+ +-|-+ 301 |MNR| \|/ |MNR| 302 +-:-+ +-|-+ +-:-+ 303 : |MNR| : 304 +-+ +-:-+ +-+ 305 +-+ : +-+ 306 +-+ 307 +-+ 309 Figure 3: Mobile Ad Hoc NETwork Example 311 4. MANET Interface Characteristics 313 Inheriting from Packet Radio as described above, primary 314 particularities of MANETs are the characteristics and qualities of 315 MANET interfaces, and the challenges these entail for protocol design 316 and development. 318 4.1. Qualities - Wireless, Mobile, Ad hoc 320 In MANETs several qualities impact protocol design. The most 321 fundamental qualities are wireless interface characteristics, 322 mobility, and ad hoc interaction. 324 Wireless interfaces often exhibit more challenging characteristics 325 when compared to wired interfaces. Many protocols (e.g., IPv6 326 neighbor discovery [RFC4861]) were not designed to operate in 327 wireless networks with asymmetric reachability. Wireless interfaces 328 may also exhibit very dynamic time varying performance (e.g., packet 329 loss, data rate), and the factors have a significant impact on local 330 communication. 332 Mobility can also exacerbate communication issues, making it more 333 challenging to attain, establish, and maintain network relationships 334 between nodes. 336 Ad hoc networking further compounds problems by allowing nodes to 337 join and leave the network, or even form new networks, at will. 339 4.2. Challenges 341 MANET characteristics result in many challenges. These challenges 342 reveal themselves in many forms, and MANET specific protocols must 343 often be developed. 345 4.2.1. Semi-Broadcast Interface 347 Given a wireless SBI that exhibits time-varying asymmetric 348 reachability and spatially distributed MANET routers, each MANET 349 router may have a different unique partial view of the MANET. That 350 is, each node may see a different set of neighboring MANET routers. 352 Communication 353 Range 354 <~~~~~~~~+~~~~~~~~> <~~~~~~~~+~~~~~~~> 355 Single |<~~~~~~~~+~~~~~~~~>| 356 SBI +--|-+ +--|-+ +--|-+ 357 |MNR1| |MNR2| |MNR3| 358 +----+ +----+ +----+ 360 MNR1 MNR2 MNR3 361 ------------------------- 362 Neighboring MNR2 MNR1 MNR2 363 Routers MNR3 365 Figure 4: Semi-Broadcast Interface (SBI) Neighboring Routers 367 The possibly unique set of neighboring MANET routers perceived by 368 each MANET router often requires MANET routers to send packets out 369 the same wireless interface as the one over which they were received. 370 Topologically, this act of forwarding out the same interface may 371 cause a packet to reach a different set of MANET routers by 372 traversing the wireless communication medium in a new location. An 373 example is provided in Figure 4, where each MANET router is capable 374 of reaching a different set of MANET routers. 376 The act of forwarding packets out of the same interface as the one 377 over which they were received often results in duplicate IP packets 378 being received by MANET routers with more than one neighboring MANET 379 router, while also reaching a new subset of MANET routers. Thus, 380 duplicate packet detection is often an inherent part of MANET 381 protocol designs. 383 4.2.2. Fuzzy Relationships Between Nearby MANET Routers & MANET 384 Routers' Extended Neighborhoods 386 Defining the process of determining neighboring MANET routers' 387 existence, continued existence, and loss of existence is a 388 fundamental challenge in MANETs. Relationships with neighboring 389 MANET routers are hard to define due to the MANET interface 390 characteristics. 392 Historically, two nodes are either neighbors or not neighbors and 393 several simple mechanisms have been used to determine neighbor 394 relationships: single packet reception, acceptable loss rates, and 395 simple handshakes. [RFC4861], for example, employs an initial 396 exchange of messages to determine neighborship or absence thereof. 397 In networks with MANET interface the types of neighbor relationships 398 expand, as do the mechanisms to detect and maintain the state of such 399 relationships. 401 Wireless network interfaces may exhibit unidirectional communication. 402 Dynamic wireless networks may also experience significant time 403 varying packet delivery between the same pair of wireless network 404 interfaces, so simple loss rates may not be sufficient to define a 405 neighbor relationship. Similarly, as nodes (and, hence, interfaces) 406 move relatively to each other, past loss rates may not reflect future 407 communication capabilities. 409 In MANETs' with SBI, MANET routers within the same small geographic 410 region are often densely connected with other nearby MANET routers. 411 These routers form a set of extended neighbor relationships. This 412 set is referred to as a MANET neighborhood. A MANET neighborhood is 413 typically composed of several MANET routers, with each MANET router 414 being densely connected to other MANET routers. 416 These more dynamic neighbor relationships do not sit well with 417 certain Internet Protocols designed assuming a fixed Ethernet like 418 model to communication links (bidirectional, transitive, and stable). 419 Given the fuzzy neighbor relationships between MANET routers, the 420 addressing model often associated with a Ethernet link is not 421 logical. For example, in an Ethernet network nodes are often told 422 that a particular range of addresses are "on-link". In MANETs' a 423 MANET router often cannot make assumptions that a particular set of 424 MANET routers is always (directly) reachable. Instead, MANET routers 425 must detect and determine neighboring MANET routers, and handle 426 changes to this set over time. 428 4.2.3. MANET Membership 430 Given MANETs' characteristics (mobile, wireless, ad hoc), determining 431 a MANETs' membership is difficult, if not impossible in certain 432 scenarios. 434 /----------------------\ /----------------------\ 435 | MANET | | MANET | 436 | +----+ +----+ +----+ | | +----+ +----+ +----+ | 437 | |MNR1+-+MNR2+-+MNR3| | | |MNR1+-+MNR2+-+MNR3| | 438 | +-+--+ +----+ +----+ | | +----+ +----+ +-+--+ | 439 | | | | | | 440 | +-+--+ | Change | +-+--+ | 441 | |MNR4| | in | |MNR7| | 442 | +----+ | Time | +----+ | 443 | \ | \----------------------/ 444 | +----+ | 445 | |MNR5| | 446 | +----+ | /----------------------\ 447 | / \ | | MANET | 448 | +----+ +----+ | | +----+ +----+ +----+ | 449 | |MNR6| |MNR7| | | |MNR6+-+MNR4+-+MNR5| | 450 | +----+ +----+ | | +----+ +----+ +----+ | 451 \----------------------/ \----------------------/ 453 Figure 5: MANET(s) 455 At one moment a MANET might consist of a certain set of nodes, and 456 the next the MANET could partition into several MANETs. Later it 457 might re-merge or merge with a new set of nodes and form a larger 458 MANET. 460 Certain routers in a MANET might connect to other routing domains. 461 These routers are called Border Routers (BRs), and they often run 462 multiple routing protocol instances. BRs are responsible for 463 choosing the routing information to announce between the various 464 attached routing domains. BRs should also present a consistent 465 picture of the nodes reachable through them. 467 As MANET membership changes, so does the connectivity of BRs within 468 the MANET. Therefore, a BR may be challenged to present a consistent 469 set of reachable nodes. It may even choose not to announce any 470 routing information about the MANET to other routing domains. 472 5. Addressing & the MANET Prefix Model 474 This section presents an architectural model for MANETs which 475 preserves the integrity of the conventional IP addressing 476 architecture while allowing for the particularities of MANET 477 interfaces. 479 5.1. General Address Architecture 481 This architectural model considers MANET routers as simply routers 482 with nodes possibly attached. These attached nodes may be attached 483 "behind the router"; that is, the router may be responsible for 484 announcing the location of a particular address or set of addresses 485 (i.e. a subnet prefix). 487 This configuration implies that, from the point of view of these 488 nodes and the applications running on them, they are not exposed to 489 the specific characteristics of MANET interfaces. 491 A MANET router can be delegated zero or more prefixes. For example, 492 if a MANET router is delegated a prefix p::, then subnet prefixes 493 derived from this prefix (e.g, p:1::/64, p:2::/64, ...) may be 494 assigned to the MANET routers' non-MANET interfaces(s), and nodes on 495 these interfaces may be assigned addresses from within this prefix, 496 and configured with this prefix according to the address 497 autoconfiguration mechanisms governing these interfaces ([RFC4861] 498 and [RFC4862]). This concept is illustrated in Figure 6. 500 MANET interfaces are specifically *NOT* configured with this prefix. 501 The configuration of these MANET interfaces is detailed in 502 Section 5.2. 504 MANET <~~~~~~+~~~~~~> 505 Interface | Delegated 506 | Prefix 507 ''''''''''''''''''''' ========== 508 ' MANET ' <=== P::/62 = 509 ' Router ' ========== 510 ''''''''' : ' Assigned 511 : ' : ' Prefix 512 : '++--------+' ============ 513 : '|Loopback |' <=== P:1::/64 = 514 ============ : '|P:1::L/64|' ============ 515 = : = : '+---------+' 516 = Other = : ''''''''''''' Assigned 517 =Interfaces= : Prefix 518 ============ : ============ 519 +...+...........+ <=== P:2::/64 = 520 : : ============ 521 +------+--+ +--+------+ 522 |P:2::1/64| * * * |P:2::K/64| 523 +---------+ +---------+ 524 Figure 6: MANET Router and Prefixes Example 526 5.2. MANET Interface Configuration 528 MANET interface specific behaviors are exclusively exposed to the 529 MANET routers. These behaviors may include asymmetric reachability, 530 semi-broadcast interfaces, fuzzy MANET router neighbor relationships, 531 changing MANET membership, rapid topology dynamics, etc. 533 The following characteristics deserve particular mention, since they 534 distinguish the configuration and behavior of MANET interface(s): 536 Unique Prefixes 537 MANET interfaces that are known to exhibit the above mentioned 538 properties must be configured with unique prefixes. The reason 539 for this requirements is so that no two MANET interfaces are 540 configured to appear within the same IP prefix. One way to 541 achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth 542 noting that prefix lengths shorter than /128 (IPv6) or /32 (IPv4) 543 are possible on the MANET interfaces, as long as the prefixes are 544 unique to a single MANET interface. Note that the above 545 statements are not an exception, but simply a clarification that 546 MANET are no different from other networks in this respect. 548 Link-local Multicast/Broadcast Scope 549 On a MANET interface, a packet sent to a link-local multicast or 550 all-ones broadcast address reaches the MANET interfaces of 551 neighboring MANET routers, regardless of their configured 552 addresses. Link-local multicast/broadcast packets are never 553 forwarded and since a MANET may span several hops, nodes cannot 554 assume that a packet sent to a link-local multicast/broadcast 555 address will reach all routers within a MANET. 557 5.3. Routers and Hosts in a MANET 559 The MANET addressing model presented in this section makes a clear 560 separation between the role of MANET router and host in a MANET, 561 recognizing that: 563 o MANET interface characteristics are only exposed to MANET-aware 564 routers running appropriate protocols; 566 o nodes and networks/subnets on non-MANET interface(s) are not 567 subjected considering MANET characteristics; 569 o applications on hosts and protocols run unmodified. 571 MANET protocols are protocols developed to work on MANET interfaces 572 and to be MANET-aware. The MANET WG is chartered to develop routing 573 protocols for MANET interfaces. The Autoconf WG is chartered to 574 develop autoconfiguration protocols for MANET interfaces and MANET 575 routers. 577 Note that this addressing framework is similar to how routing in the 578 existing Internet is structured. Routers run their routing protocol 579 over router interconnects with various characteristics to which only 580 the routing protocols are privy. On the other hand, hosts connect to 581 routers over interfaces with well-defined characteristics. 583 6. MANETs' Place in the Network Stack 585 While the MANET WG is focused on network (L3) routing, that does not 586 imply that MANETs and their protocols are limited to L3. Several 587 previous and existing efforts are applying MANET protocols at various 588 layers. Many of the challenges discussed above (with the notable 589 exception being IP addressing) exist independent of at which layer 590 MANET protocols are deployed. Of course, the protocols themselves 591 may need to be retooled slightly to accommodate the information 592 available to the deployed layer. 594 One example of sub-IP MANET routing is MANET MAC layer (L2) routing. 595 This type of routing is often called bridging, and may work in 596 homogeneous wireless networks for delivering frames over multiple 597 hops. 599 L2 routing/bridging hides the multiple L2 hops from L3. This 600 behavior can be advantageous as this network can transparently mimic 601 an Ethernet, to some extent. The ability to mimic Ethernet allows 602 the L2 MANET to utilize existing L3 network protocols. On the other 603 hand, this transparency may lead to performance problems. For 604 example, if the L3 protocols make heavy use of broadcast messaging or 605 if devices assume that high-speed bandwidth resources are available. 607 L2 MANETs do not enable heterogeneity. That is, a L2 MANET is not 608 capable of bridging across heterogeneous interfaces. For example, L2 609 bridging cannot directly bridge two L2 technologies with different 610 addressing schemes. It can also be difficult if the frame sizes of 611 two L2 technologies vary, as this could require breaking a single 612 frame into multiple frames of a different format. 614 L3 MANETs enable heterogeneous networking, as IP was built with this 615 feature in mind. Forming a MANET at L3 implies that the L3 protocols 616 must handle the challenges presented in this document. 618 MANET like protocols can also be used at other layers, both above and 619 below L3. Another example is peer-to-peer (P2P) networks; these 620 networks have some of the same challenges as MANETs. 622 7. Sharing of Information Across Layers 624 In wireless networks, and especially in MANETs, propagation of 625 additional information across layers should be considered. For 626 example, link layer feedback that a packet/frame was not able to be 627 sent or that it was not received could be used by the network layer 628 to indicate that a neighboring MANET router is no longer reachable. 629 This information and other extended interfacing could reduce, or 630 eliminate, some upper layer messaging. Further, it could 631 significantly reduce the latency in decision making. Note that 632 though certain lower layer information is valuable, it likely needs 633 to be extrapolated or filtered before accurate assumptions about the 634 network state can be made. For example, failure to deliver a single 635 frame/packet by itself may not be a good indicator that a node is or 636 is not reachable. 638 In networks with several different layers of MANET mechanisms, the 639 sharing of information across different layers can be even more vital 640 to creating and maintaining the network. For example, if a P2P 641 network is run on top of a L3 MANET, the two networks can share 642 information to use a similar optimized topology, or two network can 643 share neighboring MANET router state changes to reduce the messaging 644 or the latency in making decisions. 646 8. Deployment Taxonomy 648 The present and future proliferation of inexpensive wireless 649 interfaces continues to stimulate technical interest and developments 650 in the area of MANET for a wide variety of deployment scenarios. In 651 this section, we present several characteristics for describing 652 expected MANET deployments. 654 8.1. Service Availability 656 Nodes often expect certain services/servers to be available. When 657 describing a deployment scenario, it is important to specify the 658 expected services available and the distance between the 659 participating nodes. In MANET, nodes might assume a service is 660 available locally (within one IP hop) or within a particular scope 661 (one or more IP hops - MANET, site, global). Nodes might assume in 662 certain deployments that no special servers/services are available. 663 Finally, nodes might assume that servers are sometimes available, but 664 their availability is not guaranteed or ensured. 666 Different frameworks for autoconfiguration, network management, and 667 routing within an Autonomous System (AS) can be developed based upon 668 the expected constraints and operating conditions. 670 8.2. Number of MANET Routers in a MANET 672 The number of MANET routers in a MANET routing domain is an important 673 consideration. This number is not the complete number of nodes in a 674 MANET (since MANET routers may support an arbitrary number of 675 connected nodes) but a measure of the number of MANET routers 676 participating as a cohesive flat routing domain. 678 While the number of MANET routers does not define scalability of a 679 MANET protocol, it is often useful to discuss the number of MANET 680 router to get a feel for maturity of typical deployment solutions. 681 For simplicity we define the following network sizes to aid in 682 discussion: 684 Small 685 2-30 MANET routers 687 Moderate 688 30-100 MANET routers 690 Large 691 100-1000 MANET routers 693 Very large 694 Larger than 1000 MANET routers 696 As of 2007, small and moderate size peer MANET routing scenarios have 697 matured and have undergone reasonable test and deployment experience. 698 MANETs of those sizes can perform reasonably well in many cases 699 without hierarchy. For scaling up to large and very large MANET 700 networks, routing hierarchies, a standard technique for wired 701 Internet routing, is a possibility. While scaling design extensions 702 exist, large and very large MANET flat routing domains are still a 703 topic of ongoing active research and are not discussed further here. 705 9. Security Considerations 707 Each MANET router may not know its neighborhood a priori 708 (Section 2.2), but it should determine its neighborhood dynamically 709 and track changes as the network evolves. Similarly for MANET 710 network membership (Section 4.2.3), MANET routers may leave or join a 711 MANET, and the MANET may partition or merge with others. In addition 712 to these issues, many MANET routers are expected to communicate over 713 wireless interfaces; and the "open" nature of wireless communication 714 means that nearby nodes will often be capable of sending and 715 receiving MANET protocol packets. 717 Without any security measures MANET routers operating under these 718 characteristics will often expose protocol information to and accept 719 information from nearby nodes. Protecting MANET routers from 720 disruptive nearby nodes can be performed by using confidentiality, 721 data integrity, and peer entity authentication. 723 Different deployments of MANETs may have very different security 724 requirements. For example, if a MANET is deployed for a military 725 purpose, exposing the network topology to any outside party may not 726 be acceptable -- whereas for a civilian deployment exposure of 727 topology information may be of little or no importance. Furthermore, 728 different deployments may require different mechanisms to address 729 security issues (e.g., pre-sharing of keys or certificates), and the 730 MANET routers themselves may have various additional constraints 731 (e.g., computational power for generating or verifying cryptographic 732 attributes). Therefore, due to the large diversity of MANET routers 733 and their deployments, MANET protocols should allow for appropriate, 734 and possibly multiple or various, security mechanisms. 736 10. IANA Considerations 738 This is an informational document. IANA requirements for MANET 739 related protocols will be developed within the protocol 740 specifications for MANET protocols. 742 11. Acknowledgments 744 Discussions and developments concepts and architectural issues have 745 evolved over many years of discussion of related work within the 746 MANET WG. There are obviously many people that have contributed to 747 past discussions and related draft documents within the WG that have 748 influenced the development of these concepts that deserve 749 acknowledgment. The authors would like to thank all contributors to 750 the MANET and AUTOCONF WG efforts and those that have helped in the 751 review and content process. 753 While not entirely complete the authors would like to in particular 754 thank the following individuals for extensive discussions and 755 valuable contributions: 757 Jari Arkko 758 Emmanuel Baccelli 760 Alan Cullen 762 Justin Dean 764 Christopher Dearlove 766 Tom Henderson 768 Bob Hinden 770 Thomas Narten 772 Charles Perkins 774 Subhranshu Singh 776 Fred Templin 778 Dave Thaler 780 Seung Yi 782 12. Informative References 784 [DWN03] Macker, J. and S. Corson, "Mobile Ad hoc Networking: 785 Routing Technology for Dynamic, Wireless Networks", IEEE 786 Press, Mobile Ad hoc Networking, Chapter 9, 2003. 788 [FL01] Freebersyser, J. and B. Leiner, "A DoD perspective on 789 mobile ad hoc networks", Addison Wesley C. E. Perkin, Ed., 790 2001, pp. 29--51, July 2001. 792 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 793 RFC 1812, June 1995. 795 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 797 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 798 November 1998. 800 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 801 (IPv6) Specification", RFC 2460, December 1998. 803 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 804 (MANET): Routing Protocol Performance Issues and 805 Evaluation Considerations", RFC 2501, January 1999. 807 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 808 RFC 3753, June 2004. 810 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 811 Architecture", RFC 4291, February 2006. 813 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 814 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 815 September 2007. 817 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 818 Address Autoconfiguration", RFC 4862, September 2007. 820 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 821 June 2007. 823 Authors' Addresses 825 Ian D Chakeres 826 Motorola 827 Bagmane Tech Park 828 66/1, Plot 5, CV Raman Nagar 829 Bangalore, Karnataka 560093 830 India 832 Email: ian.chakeres@gmail.com 833 URI: http://www.ianchak.com/ 835 Joe Macker 836 Naval Research Laboratory 837 Washington, DC 20375 838 USA 840 Email: macker@itd.nrl.navy.mil 842 Thomas Heide Clausen 843 LIX, Ecole Polytechnique 844 91128 Palaiseau CEDEX 845 France 847 Email: T.Clausen@computer.org 848 URI: http://www.thomasclausen.org/ 850 Full Copyright Statement 852 Copyright (C) The IETF Trust (2007). 854 This document is subject to the rights, licenses and restrictions 855 contained in BCP 78, and except as set forth therein, the authors 856 retain all their rights. 858 This document and the information contained herein are provided on an 859 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 860 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 861 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 862 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 863 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 864 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Intellectual Property 868 The IETF takes no position regarding the validity or scope of any 869 Intellectual Property Rights or other rights that might be claimed to 870 pertain to the implementation or use of the technology described in 871 this document or the extent to which any license under such rights 872 might or might not be available; nor does it represent that it has 873 made any independent effort to identify any such rights. Information 874 on the procedures with respect to rights in RFC documents can be 875 found in BCP 78 and BCP 79. 877 Copies of IPR disclosures made to the IETF Secretariat and any 878 assurances of licenses to be made available, or the result of an 879 attempt made to obtain a general license or permission for the use of 880 such proprietary rights by implementers or users of this 881 specification can be obtained from the IETF on-line IPR repository at 882 http://www.ietf.org/ipr. 884 The IETF invites any interested party to bring to its attention any 885 copyrights, patents or patent applications, or other proprietary 886 rights that may cover technology that may be required to implement 887 this standard. Please address the information to the IETF at 888 ietf-ipr@ietf.org. 890 Acknowledgment 892 Funding for the RFC Editor function is provided by the IETF 893 Administrative Support Activity (IASA).