idnits 2.17.1 draft-chakeres-manet-arch-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 29, 2006) is 6480 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) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-02 == Outdated reference: A later version (-38) exists of draft-templin-autoconf-dhcp-01 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (AUTOCONF) I. Chakeres 3 Internet-Draft Boeing 4 Expires: January 30, 2007 J. Macker 5 Naval Research Laboratory 6 T. Clausen 7 LIX, Ecole Polytechnique 8 July 29, 2006 10 Mobile Ad Hoc Network Architecture 11 draft-chakeres-manet-arch-00 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 January 30, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document discusses Mobile Ad hoc NETworks (MANETs). It 45 discusses some basic MANET architectural concepts, related 46 taxonomies, and MANETs' relationship to the Internet architecture. 47 It also discusses the relevant node, interface, and network 48 characteristics that influence Internet protocol development in 49 MANETs. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. MANET Motivation Discussion . . . . . . . . . . . . . . . . . 6 56 4. Challenges and Design Considerations . . . . . . . . . . . . . 7 57 4.1. Wireless Interface . . . . . . . . . . . . . . . . . . . . 7 58 4.2. Neighbors and Neighborhoods . . . . . . . . . . . . . . . 8 59 4.3. Dynamic Network Topology . . . . . . . . . . . . . . . . . 9 60 5. Architectural Issues . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Local Connectivity . . . . . . . . . . . . . . . . . . . . 10 62 5.2. MANET Membership . . . . . . . . . . . . . . . . . . . . . 10 63 5.3. Border Connectivity . . . . . . . . . . . . . . . . . . . 11 64 6. Deployment Taxonomy . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 11 66 6.2. Number of Peer MANET Routers . . . . . . . . . . . . . . . 12 67 6.3. Heterogeneity . . . . . . . . . . . . . . . . . . . . . . 13 68 6.4. Example Deployments . . . . . . . . . . . . . . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 72 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 74 Intellectual Property and Copyright Statements . . . . . . . . . . 17 76 1. Introduction 78 A Mobile Ad hoc NETwork (MANET) is made up from a set of MANET 79 routers (MRs). These MRs organize and maintain a routing structure 80 among themselves over dynamic wireless interfaces. As any IP router, 81 a MR may have an attached set of nodes. These nodes access the MANET 82 via the MR to which they are attached. 84 Due, in part, to relative movements of MR and, in part, to 85 environmental effects (especially wireless characteristics), the 86 network topology and communication links in a MANET may change state 87 more frequently than in fixed wired or fixed wireless networks. 89 These attributes and others influence Internet Protocol (IP) design 90 for MANETs. This document elaborates on the many important 91 properties and their impact. 93 2. Terminology 95 This document employs the following definitions: 97 Node 98 any device (router or host) which implements IP. 100 Router 101 a node that forwards IP packets not explicitly addressed to 102 itself. 104 MANET Router (MR) 105 a router that engages in a MANET routing protocol. In certain 106 scenarios a MR may forward packets only for itself (and its 107 attached nodes). 109 Host 110 any node that is not a router, i.e. it does not forward packets 111 addressed to others. 113 Link 114 A communication facility on a layer below IP, over which nodes 115 exchange IP packets. In a MANET, links may change quality on 116 short time scales, present unique views of their local 117 neighborhood, and have other challenging properties. 119 Neighbor 120 Two nodes are neighbors if and only if their links intersect, i.e. 121 data may be propagated between them without relying on assistance 122 of any forwarding node. 124 Interface 125 A node's point of attachment to a link. 127 Broadcast Interface (BI) 128 An interface supporting many (more than two) attached routers, 129 together with the capability to address a single physical message 130 to all of the attached routers (broadcast). The set of nodes 131 receiving a given physical broadcast message are the neighbors of 132 the node originating the message; this set of receiving nodes will 133 themselves be neighbors with one another. An ethernet segment is 134 an example of a broadcast interface. 136 Wireless Broadcast Interface (WBI) 137 A broadcast interface that communicates over a wireless channel. 138 Compared to traditional broadcast interfaces, a wireless broadcast 139 interface has additional complexity: each device may have a unique 140 local view of its local network. The set of nodes receiving a 141 given physical broadcast message are neighbors of the node 142 originating the message; this set of receiving nodes will, 143 however, not necessarily be neighbors with one another. An IEEE 144 802.11 interface is an example of a wireless broadcast interface. 146 Autonomous System (AS) 147 An Autonomous System (AS) is a network topology that consists of a 148 collection of routers and their subnetworks (with hosts attached) 149 interconnected by a set of routes. The subnetworks and the 150 routers are expected to be under the control of a single 151 operations and maintenance (O&M) organization. Within an AS, 152 routers use the same routing protocol. An AS is expected to 153 present to other ASs the appearance of a coherent interior routing 154 plan, and a consistent picture of the reachable nodes. 156 MANET 157 A MANET is an AS made up of affiliated/associated MRs (and their 158 connected nodes) that maintain a routing structure in arbitrarily 159 dynamic network topologies, as illustrated in Figure 1. 161 /----------------------\ /----------------------\ 162 | MANET | | MANET | 163 | +---+ +---+ +---+ | | +---+ +---+ +---+ | 164 | |RT1+-+RT2+-+RT3| | | |RT1+-+RT2+-+RT3| | 165 | +-+-+ +---+ +---+ | | +---+ +---+ +-+-+ | 166 | | | | | | 167 | +-+-+ | Change | +-+-+ | 168 | |RT4+ | in | |RT7| | 169 | +---+\ | Time | +---+ | 170 | \+---+ | \----------------------/ 171 | +RT5+ | /----------------------\ 172 | /+---+\ | | MANET | 173 | +---+/ \+---+ | | +---+ +-+-+ +---+ | 174 | |RT6+ +RT7| | | |RT6+--+RT4+--+RT5+ | 175 | +---+ +---+ | | +---+ +---+ +---+ | 176 \----------------------/ \----------------------/ 178 Figure 1: MANET(s) 180 MANET Border Router (MBR) 181 A MANET border router is a MR that connects to two or more ASs, as 182 illustrated in Figure 2. A MBR presents a consistent picture of 183 the nodes reachable through itself to connected ASs. A MBR 184 chooses the routing information to propagate between ASs. 186 /------\ /------\ 187 | | +---+ | | 188 | AS +--+MBR+--+ AS | 189 | | +---+ | | 190 \------/ \------/ 192 Figure 2: MBR 194 Flooding 195 The process of forwarding information to MRs throughout a MANET. 197 Much of this terminology was borrowed from existing documents, to 198 list a few [RFC1812], [RFC2453], [RFC2460], [RFC2328], [RFC3513], 199 [RFC3753], [I-D.thaler-autoconf-multisubnet-manets], and 200 [I-D.templin-autoconf-dhcp]. Note that the original text for the 201 terms was modified, though we have attempted to maintain the same 202 meaning. In the future, terms defined elsewhere will likely be cited 203 instead of included. 205 3. MANET Motivation Discussion 207 The Internet Protocol (IP) core design tenets -- connectionless 208 networking and packet-based forwarding -- are ideally suited for use 209 in highly dynamic contexts, such as MANETs. Yet, some additional 210 functionality is required to meet the unique challenges and 211 opportunities present in MANETs. 213 The initial motivation for MANETs was called Packet Radio (PR) 214 networking [FL01]. In PR, each router is equipped with a single 215 wireless broadcast interface (the simplest MR configuration). Each 216 router may be mobile, and the routers may be or may become spatially 217 distributed such that all routers cannot communicate directly. That 218 is, two routers might require one or more other intermediate routers 219 to forward (route) packets on their behalf. In the example shown in 220 Figure 3, for RT1 to send packets to RT3, the intermediary RT2 must 221 relay the packets. This implies that RT2 must receive the packet 222 from RT1 on its interface and determine that it must retransmit the 223 packet over the same interface as the one where the packet was 224 received, in order for the packet to reach RT3. This example also 225 illustrates how WBIs differ from BIs: from the point of view of RT2, 226 both RT1 and RT3 are neighbors, whereas RT1 and RT2 are not 227 themselves neighbors with one another. 229 Communication 230 Range 231 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 232 Single | <~~~~~~+~~~~~~> | 233 Wireless +-|-+ +-|-+ +-|-+ 234 Interface |RT1| |RT2| |RT3| 235 +---+ +---+ +---+ 237 Figure 3: Basic MANET Network 239 The attachment of PR networks to the fixed ARPANET stimulated early 240 introduction of the first Internet architecture approaches and 241 designs enabling heterogeneous interconnection. The taxonomy of 242 scenarios in which MANETs may be deployed is rich, making it 243 important to develop flexible MANET protocols and discuss 244 architectural approaches that cover a set of deployment scenarios 245 reasonably well. 247 The two characteristics having the largest impact on MANET protocol 248 design are: 250 o wireless interface characteristics and 252 o frequent topological change. 254 One more important point to emphasize is that the fundamental MANET 255 design motivation is the same as existing IP intra-domain routing 256 goals, except MANET protocols account for more challenging 257 topological conditions and wireless interface behaviors. These 258 challenging conditions often require new protocols or extensions. 260 4. Challenges and Design Considerations 262 As mentioned in Section 3, the wireless interface characteristics and 263 the frequently changing topology present challenges, under which 264 MANET protocols must be developed. These challenges are detailed 265 further in this section. 267 4.1. Wireless Interface 269 Wireless interface characteristics differ from wired interface 270 characteristics in several ways: 272 Shared resource 273 In wireless networks since the physical channel resources are 274 shared between many devices, the transmission on each wireless 275 interface influences the resources available to all nearby devices 276 often including nodes multiple hops away. Therefore, the overhead 277 of signaling, message exchange, and control plane flooding often 278 induced by protocol designs needs special consideration to reduce 279 channel contention and congestion. In some cases, underlying 280 lower layer protocols may change the shared resource in dynamic 281 ways, and these mechanism also contribute to changing topological 282 and quality conditions. 284 High loss statistics 285 In comparison to wired interfaces, wireless interfaces experience 286 loss statistics which can be several orders of magnitude higher 287 than in wired environments. Furthermore, the losses can vary 288 temporally and dramatically dependent upon the environment 289 scenario and type of wireless technology. Therefore, signaling 290 and message exchange may be unreliable, and this fact must be 291 accommodated in MANET protocols. 293 Time varying interface performance 294 In comparison to wired interfaces, wireless interfaces experience 295 significant changes in performance over time. The capacity, loss, 296 delay, jitter, and other metrics of neighbor quality may vary by 297 several orders of magnitude at large and small time scales. Some 298 of these characteristics can be quantified by the position and 299 distance between devices, but more often these characteristics are 300 unpredictable and related to environmental effects and must be 301 included in higher layer protocol design decisions. 303 Stochastic neighborhoods 304 Given the variance associated with wireless interfaces mentioned 305 above, from an IP perspective the neighbor relationships may 306 change state often. Handling the rapid insertion, deletion, and 307 symmetric variability of wireless channels is a challenge. 309 Wireless broadcast 310 A wireless broadcast/multicast packet reaches only nodes that are 311 neighbors to the node which transmitted the broadcast packet, as 312 described for wireless broadcast interfaces. Given that each MR 313 can be located in a different arbitrary position, or may have 314 unique antenna characteristics, each MR may have a unique set of 315 neighbors. Therefore, a MR may be required to forward a packet 316 out the same logical interface upon which the packet was received 317 to reach another MR. Logically, each MRs' wireless interface may 318 communicate with a unique set of neighboring MR, since no other MR 319 may have the same logical connectivity. This fact and its impact 320 will be discussed further in Section 4.2. 322 Other characteristics 323 There are numerous other factors related to wireless interfaces 324 and MANET routing, but these factors will not be elaborated upon 325 here. For more information on wireless interfaces and other MANET 326 performance characteristics please see [RFC2501]. 328 4.2. Neighbors and Neighborhoods 330 Given a wireless interface and spatially distributed MRs, each device 331 may have a different unique partial view of the MANET. That is, each 332 MR may have a different set of adjacent MRs, and this set may change 333 over time. 335 Communication 336 Range 337 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 338 Single | <~~~~~~+~~~~~~> | 339 Wireless +-|-+ +-|-+ +-|-+ 340 Interface |RT1| |RT2| |RT3| 341 +---+ +---+ +---+ 343 RT1 RT2 RT3 344 ------------------------- 345 Neighbors * RT2 RT1 RT2 346 * RT3 348 Figure 4: Wireless Broadcast Interface (WBI) Neighbors 350 The possibly unique set of adjacent MRs requires MRs to forward 351 packets in and out the same wireless interface. The act of 352 forwarding packets in and out of the same interface, while reaching a 353 new subset of MRs, results in duplicate IP messaging being received 354 at MR with more than one neighboring MR. For unicast traffic, the 355 next-hop designation in each packet ensures that such traffic is 356 simply ignored by routers, other than the designated next hop router, 357 as in all other IP networks. For non-link-local multicast and 358 broadcast traffic, recognition of this duplicate reception needs to 359 be accounted for explicitly in protocol designs. Present MANET 360 routing protocol designs that employ flooding techniques for control 361 traffic meet this requirement. 363 Due to MANETs wireless nature, communication between MRs can be 364 asymmetric: MR X may receive traffic from MR Y, whereas MR Y does not 365 receive traffic from MR X. In other words, the MRs X and Y links 366 provides for unidirectional communication from MR Y to MR X. This is 367 also an example showing that each MR may have its own unique view of 368 the local topology. Generally, MANET routers should use only 369 bidirectional communication links between routing peers. One reason 370 to prefer bidirectional communication between routing pairs is that 371 some common L2 protocols (e.g. IEEE 802.11) employ positive 372 acknowledgments for unicast data traffic and simply won't work 373 otherwise. The mechanisms for sensing and maintaining bidirectional 374 communication are important to the design of MANET routing protocols. 376 4.3. Dynamic Network Topology 378 In the typical use case scenario, MRs are assumed to be mobile and 379 communicating over wireless interfaces, both of these properties 380 create a dynamic arbitrary network topology with varying adjacency 381 statistics. The local topology, as seen by a given MR, is expected 382 to change rapidly and unpredictably. Existing protocols for wired 383 networks are typically not designed or able to manage wireless links 384 and converge on a time-scale appropriate for MANETs. However, MANET 385 extensions for existing wired routing protocols such as OSPF have 386 been developed and are being further explored within the IETF. 387 Another outcome of the dynamic operation requirement is that MANET 388 protocols must be able to operate effectively without strict network 389 wide convergence. 391 5. Architectural Issues 393 The topology within a MANET is expected to change, and the routing 394 protocol should operate effectively given arbitrary dynamic changes. 395 Changes can happen at three different levels: local connectivity, 396 MANET membership, and MANET border connectivity. 398 5.1. Local Connectivity 400 Locally topology changes are the result of either addition or loss of 401 neighbors. That is, two or more MRs are either connected and can 402 communicate (i.e. their links intersect) or they are disconnected and 403 can not communicate. The detection and determination of local 404 connectivity is outside the scope of this document. 406 MRs may need to be aware of these local connectivity changes and 407 handle them appropriately. 409 There are several possible logical local connectivity states that may 410 exist between a pair of MRs: 412 Disconnected 413 The two MRs links do not intersect. 415 Connected 416 The two MRs links intersect. 418 Other 419 The two MRs links might intersect. The MRs are not sure whether 420 their links intersect or not. Given wireless interfaces it may be 421 difficult to classify two MR as connected or disconnected. 423 Note that when local connectivity changes, MANET membership and 424 border connectivity may also be change. 426 5.2. MANET Membership 428 The membership within a MANET may change based on changes to the 429 local connectivity between MRs. A MANET may partition into multiple 430 separate smaller MANETs when two MRs which used to be connected 431 becomes disconnected. Alternatively, when two MANETs collide, i.e. 432 at least one MR from each MANET becomes connected, the two MANETs can 433 merge and form a single, large MANET. These membership events can 434 happen between any pair of MRs. The detection and determination of 435 MANET membership is outside the scope of this document. 437 The following membership events may occur: 439 Partition 440 Loss of a neighbor can cause a MANET to partition into multiple 441 smaller MANETs. Partitioning may also decrease each new MANETs 442 border connectivity. 444 Merge 445 Connection to a new neighboring MR can cause multiple MANETs to 446 merge into a single larger MANET. This new MANET may have 447 additional border connectivity, via now reachable MBR. 449 Note that MANET membership events may happen more quickly than MANET 450 wide communication can occur. This fact is important since a part of 451 a MANET may become its own MANET, while another part of the MANET may 452 merge with another MANET. 454 5.3. Border Connectivity 456 MANET border routers (MBR) hide the details of the internal MANET 457 topology from other ASs. There may be multiple external connections 458 to a MANET, via one or more MBR. A MBR may disseminate routing 459 information about other connected ASs, to each connected AS. 461 A local connectivity or MANET membership change may result in changed 462 MBR connectivity. 464 6. Deployment Taxonomy 466 The present and future proliferation of inexpensive wireless 467 interfaces continues to stimulate technical interest and developments 468 in the area of MANET for a wide variety of deployment scenarios. In 469 this section, we present several key characteristics for describing 470 expected MANET deployments. 472 6.1. Infrastructure 474 We define infrastructure as the assumed availability of services, 475 devices, and resources . This axis of the taxonomy falls into 476 several broad categories: 478 Infrastructure is always available 480 Infrastructure is sometimes available 482 Infrastructure is never available 484 When describing a deployment scenario, it is important to specify the 485 expected infrastructure connection constraints and expectations, 486 especially whether the infrastructure resides in the MANET or behind 487 a MBR. Different frameworks for autoconfiguration, network 488 management, and fundamental services can be developed based upon the 489 expected constraints and operating conditions. 491 6.2. Number of Peer MANET Routers 493 The number of peer MRs in a MANET is an important consideration. 494 This number is not the complete number of nodes in a MANET (since MRs 495 may support an arbitrary number of connected nodes) but a measure of 496 the number of peer MR participating as a cohesive flat routing area. 497 While the number of MRs does not define scalability of a MANET 498 protocol, it is often useful discuss the number of peer MR to get a 499 feel for maturity of typical deployment solutions. For simplicity we 500 define the following network sizes to aid in discussion: 502 Small 503 2-30 MANET peers 505 Moderate 506 30-100 MANET peers 508 Large 509 100-1000 MANET peers 511 Very large 512 Larger than 1000 MANET peers 514 At the time of writing, small and moderate size peer MANET routing 515 scenarios have matured and have reasonable testing and deployment 516 experience. These sizes can perform reasonably well in many cases 517 without hierarchy. MANET architectures can, of course, support 518 routing hierarchies to improve scaling. Large and very large MANET 519 routing areas that are flat are still a topic of active research and 520 are not considered here. Existing MANET routing developments, such 521 as SMF [I-D.ietf-manet-smf], have shown significant performance 522 improvements and capabilities even in small peer router size 523 deployments and experiments. 525 6.3. Heterogeneity 527 The Internet Protocol provides a least common denominator for 528 heterogeneous network interconnection. It allows devices independent 529 of lower layer connectivity properties to inter-operate and 530 communicate seamlessly. This document has concentrated on the 531 architectural description in which MANET technology provides Internet 532 layer routing and possibly between heterogeneous interfaces, although 533 variants of IETF MANET routing solutions have been implemented or 534 adapted at lower layers below IP. Within IP-based MANETs, while a 535 single wireless broadcast interface may be used to support multi-hop 536 IP routing, we allow for the possibility of several different types 537 of lower layer link technologies to be used within the same MANET. 538 Developing MANET routing protocols at the IP layer seamlessly enables 539 lower layer heterogeneity. Also, the initial term MANET was 540 developed by a group of engineers doing this work at the IP layer and 541 envisioning heterogeneity support. 543 6.4. Example Deployments 545 Here we provide a short list of example deployment scenarios: 547 Wireless mesh networks 549 Disaster relief 551 Sensor networks 553 Range extension 555 Military communication 557 Automotive networks 559 7. Security Considerations 561 TBD 563 8. IANA Considerations 565 This is an informational document. IANA requirements for MANET 566 related protocols will be developed within the protocol 567 specifications for MANET protocols. 569 9. Acknowledgments 571 Discussions and developments concepts and architectural issues have 572 evolved over many years of discussion of related work within the 573 MANET WG. There are obviously many people that have contributed to 574 past discussions and related draft documents within the WG that have 575 influenced the development of these concepts that deserve 576 acknowledgment. The authors would like to thank all contributors to 577 the MANET and AUTOCONF WG efforts and those that have helped in the 578 review and content process. 580 While not entirely complete the authors would like to in 581 particular thank the following individuals for there discussions 582 and contributions: 584 Fred Templin 586 Christopher Dearlove 588 Charles Perkins 590 Justin Dean 592 Subhranshu Singh 594 Thomas Henderson 596 Emmanuel Baccelli 598 Dave Thaler 600 Jari Akko 602 Thomas Nartan 604 The RFC text was produced using Marshall Rose's xml2rfc tool. 606 10. Informative References 608 [FL01] Freebersyser, J. and B. Leiner, "A DoD perspective on 609 mobile ad hoc networks", Addison Wesley C. E. Perkin, Ed., 610 2001, pp. 29--51, July 2001. 612 [I-D.ietf-manet-smf] 613 Macker, J., "Simplified Multicast Forwarding for MANET", 614 draft-ietf-manet-smf-02 (work in progress), March 2006. 616 [I-D.templin-autoconf-dhcp] 617 Templin, F., "MANET Autoconfiguration using DHCP", 618 draft-templin-autoconf-dhcp-01 (work in progress), 619 June 2006. 621 [I-D.thaler-autoconf-multisubnet-manets] 622 Thaler, D., "Multi-Subnet MANETs", 623 draft-thaler-autoconf-multisubnet-manets-00 (work in 624 progress), February 2006. 626 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 627 RFC 1812, June 1995. 629 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 631 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 632 November 1998. 634 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 635 (IPv6) Specification", RFC 2460, December 1998. 637 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 638 (MANET): Routing Protocol Performance Issues and 639 Evaluation Considerations", RFC 2501, January 1999. 641 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 642 (IPv6) Addressing Architecture", RFC 3513, April 2003. 644 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 645 RFC 3753, June 2004. 647 Authors' Addresses 649 Ian Chakeres 650 Boeing 651 The Boeing Company 652 P.O. Box 3707 Mailcode 7L-49 653 Seattle, WA 98124-2207 654 USA 656 Email: ian.chakeres@gmail.com 658 Joe Macker 659 Naval Research Laboratory 660 Washington, DC 20375 661 USA 663 Email: macker@itd.nrl.navy.mil 665 Thomas Heide Clausen 666 LIX, Ecole Polytechnique 667 91128 Palaiseau CEDEX 668 France 670 Email: T.Clausen@computer.org 671 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 673 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; nor does it represent that it has 680 made any independent effort to identify any such rights. Information 681 on the procedures with respect to rights in RFC documents can be 682 found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use of 687 such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository at 689 http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at 695 ietf-ipr@ietf.org. 697 Disclaimer of Validity 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 702 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 703 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 704 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Copyright Statement 709 Copyright (C) The Internet Society (2006). This document is subject 710 to the rights, licenses and restrictions contained in BCP 78, and 711 except as set forth therein, the authors retain all their rights. 713 Acknowledgment 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society.