idnits 2.17.1 draft-chakeres-manet-arch-01.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 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 680. ** 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 (October 3, 2006) is 6415 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.thaler-autoconf-multisubnet-manets' is defined on line 602, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-08 == 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 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 10 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: April 6, 2007 J. Macker 5 Naval Research Laboratory 6 T. Clausen 7 LIX, Ecole Polytechnique 8 October 3, 2006 10 Mobile Ad hoc Network Architecture 11 draft-chakeres-manet-arch-01 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 April 6, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document discusses Mobile Ad hoc NETworks (MANETs). It 45 introduces basic MANET terms, characteristics, and challenges. This 46 document also defines several MANET entities and architectural 47 concepts. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. MANET Architectural Terms . . . . . . . . . . . . . . . . . . 4 54 4. MANET Motivation Discussion . . . . . . . . . . . . . . . . . 5 55 5. Qualities - Wireless, Mobile, Ad hoc . . . . . . . . . . . . . 6 56 6. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6.1. Semi-Broadcast Interface . . . . . . . . . . . . . . . . . 7 58 6.2. Fuzzy Neighbor Relationship & Extended Neighborhood . . . 8 59 6.3. MANET Membership . . . . . . . . . . . . . . . . . . . . . 9 60 7. Other Important Discussion . . . . . . . . . . . . . . . . . . 10 61 7.1. MANETs' Place in the Network Stack . . . . . . . . . . . . 10 62 7.2. Cross Layering . . . . . . . . . . . . . . . . . . . . . . 10 63 8. Deployment Taxonomy . . . . . . . . . . . . . . . . . . . . . 11 64 8.1. Service Availability . . . . . . . . . . . . . . . . . . . 11 65 8.2. Number of Peer MANET Routers . . . . . . . . . . . . . . . 11 66 8.3. Example Deployments . . . . . . . . . . . . . . . . . . . 12 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 12. Informative References . . . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . . . . 17 74 1. Introduction 76 A Mobile Ad hoc NETwork (MANET) consists of a loosely connected set 77 of MANET routers. These routers organize and maintain a routing 78 structure among themselves. These routers often communicate over 79 wireless links and are often mobile. MANETs' characteristics create 80 challenges in several areas, and often require protocol extensions or 81 new MANET protocols altogether. 83 This document is focused on IP networking, though many of MANETs' 84 concepts and issues span the protocol stack. 86 This document is meant to complement [RFC2501] in describing and 87 defining MANET. 89 2. Terminology 91 Much of the terminology in this document was borrowed from existing 92 documents, to list a few [RFC1812], [RFC2328], [RFC2453], [RFC2460], 93 [RFC2461], [RFC3513], [RFC3753], [I-D.thaler-autoconf-multisubnet- 94 manets], [I-D.templin-autoconf-dhcp], and [I-D.ietf-ipv6-2461bis]. 95 Note that the original text for the terms is often modified, though 96 we have attempted to maintain the same meaning. In the future, terms 97 defined elsewhere will likely be cited instead of included. 99 This document employs the following definitions: 101 Node 102 any device (router or host) that implements IP. 104 Router 105 a node that forwards IP packets not explicitly addressed to 106 itself. 108 Host 109 any node that is not a router, i.e. it does not forward packets 110 addressed to others. 112 Link 113 A communications facility at a layer below IP, over which nodes 114 exchange IP packets directly without decrementing IP TTL (Hop 115 Limit). 117 Asymmetric Reachability 118 A link where non-reflexive and/or non-transitive reachability is 119 part of normal operation. Non-reflexive reachability means 120 packets from X reach Y but packets from Y don't reach X. Non- 121 transitive reachability means packets from X reach Y, and packets 122 from Y reach Z, but packets from X don't reach Z. Many radio/ 123 wireless interfaces exhibit these properties. 125 Neighbor 126 If node X can directly exchange IP packets with node Y, then node 127 Y is node X's neighbor. Packet reception characteristics are 128 often used to assist devices in determining the quality of 129 neighbors' communication. 131 Interface 132 A node's point of attachment to a communication link. 134 Broadcast Interface 135 An interface supporting many attached nodes, together with the 136 capability to address a single link layer message to all of the 137 attached nodes (broadcast). The set of nodes receiving a given 138 physical broadcast message are the neighbors of the node 139 originating the message. 141 Full-Broadcast Interface (FBI) 142 A broadcast interface with reflexive and transitive reachability. 143 All nodes on the interface can send and receive IP packets 144 directly, all nodes are symmetric neighbors. An Ethernet segment 145 is an example of a FBI. 147 Semi-Broadcast Interface (SBI) 148 A broadcast interface that may exhibit non-reflexive and/or non- 149 transitive reachability. A FBI is a special case of SBI. 150 Multiple access wireless radio interfaces are often SBI. 152 Site 153 a set of one or more links. 155 Flooding 156 The process of forwarding information to as many MANET routers as 157 possible. 159 3. MANET Architectural Terms 161 In MANET there are two important entities. We define the following 162 entities: 164 MANET Router 165 a node that engages in a MANET routing protocol. 167 MANET Border Router (MBR) 168 a MANET router that also participates in multiple routing regions, 169 and often multiple routing protocols. A MBR forms a border 170 between its multiple routing regions. A MBR is responsible for 171 presenting a consistent picture of the nodes reachable through 172 itself to each routing region. A MBR chooses the routing 173 information to propagate between different regions. 175 In MANET there are several architectural scopes. We define the 176 following scopes: 178 MANET Neighbors 179 a set of MANET routers that is reachable in one hop. 181 MANET Neighborhood 182 a set of MANET routers that is reachable in a few hops, generally 183 two hops. These routers often have a large number of common 184 neighbors and often compete for shared wireless resources. 186 MANET 187 a set of MANET routers that is reachable via multiple IP hops. A 188 MANET is smaller than or equal to a site. 190 If a link forms between two previously separated MANET routers or 191 MANETs, the two MANETs will merge to form a single larger MANET. 192 Similarly, if a critical link between two MANET routers is lost the 193 MANET will partition into two MANETs. 195 When discussing MANETs' connectivity to other networks, like the 196 Internet, a MANET is bounded by MANET border routers. That is a 197 MANETs' MBR form a border between a MANET and other routing regions. 199 4. MANET Motivation Discussion 201 The Internet Protocol (IP) core design tenets -- connectionless 202 networking and packet-based forwarding -- are ideally suited for use 203 in highly dynamic contexts, such as MANETs. Yet, some additional 204 functionality is required to meet the unique challenges and 205 opportunities present in MANETs. 207 The initial motivation for MANETs was called Packet Radio (PR) 208 networking [FL01]. In PR, each router is equipped with a single SBI. 209 This is the simplest MANET router configuration. Each router may be 210 mobile, and the routers may be or may become spatially distributed 211 such that all routers cannot communicate directly. That is, two 212 routers might require one or more other intermediate routers to 213 forward (route) packets on their behalf. In the example shown in 214 Figure 1, for RT1 to send packets to RT3, the intermediary RT2 must 215 relay the packets. This implies that RT2 must receive the packet 216 from RT1 on its interface and determine that it must retransmit the 217 packet over the same interface as the one where the packet was 218 received, in order for the packet to reach RT3. This example also 219 illustrates how SBIs differ from FBIs: from the point of view of RT2, 220 both RT1 and RT3 are neighbors, whereas RT1 and RT3 are not 221 themselves neighbors with one another. 223 Communication 224 Range 225 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 226 Single | <~~~~~~+~~~~~~> | 227 SBI +-|-+ +-|-+ +-|-+ 228 |RT1| |RT2| |RT3| 229 +---+ +---+ +---+ 231 Figure 1: Basic MANET Network 233 In addition to addressing nodes' asymmetric reachability other 234 challenges exist. In PR networks, shared wireless resources result 235 in interdependence between nearby nodes, and these nodes often 236 communicate directly or indirectly. The dynamic wireless interface 237 characteristics and node mobility often manifest as frequent network 238 topology changes. 240 PR networks also lead to several other architecture related 241 challenges. One challenge was to attach these PR networks to other 242 networks, especially fixed networks like the ARPANET. Another 243 related challenge was how to deal with the large disparity between 244 different node and interface characteristics. 246 These PR network challenges helped stimulate the Internet Protocol; 247 an architecture based on connectionless networking and packet-based 248 forwarding that enables interconnection of heterogeneous devices over 249 heterogeneous interfaces. 251 5. Qualities - Wireless, Mobile, Ad hoc 253 In MANET several qualities impact protocol design. The most 254 fundamental qualities are wireless interface characteristics, 255 mobility, and ad hoc interaction. 257 Wireless interfaces exhibit challenging characteristics when compared 258 with wired interfaces. Many protocols (e.g. neighbor discovery) do 259 not operate in wireless networks with asymmetric reachability. 260 Wireless interfaces also exhibit time varying performance that can 261 significantly impact local communication. 263 Mobility also exacerbates wireless communication issues, making it 264 difficult to attain, establish, and maintain relationships between 265 nodes. 267 Ad hoc networking further compounds problems by allowing nodes to 268 join and leave the network, or even form new networks, at will. 270 6. Challenges 272 MANETs characteristics result in many challenges. These challenges 273 reveal themselves in many forms, and MANET specific protocols must 274 often be developed. 276 6.1. Semi-Broadcast Interface 278 Given a wireless SBI (with non-transitive and non-reflexive 279 properties) and spatially distributed nodes, each node may have a 280 different unique partial view of the MANET. That is, each node may 281 have a different set of adjacent nodes. 283 Communication 284 Range 285 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 286 Single | <~~~~~~+~~~~~~> | 287 SBI +-|-+ +-|-+ +-|-+ 288 |RT1| |RT2| |RT3| 289 +---+ +---+ +---+ 291 RT1 RT2 RT3 292 ------------------------- 293 Neighbors * RT2 RT1 RT2 294 * RT3 296 Figure 2: Semi-Broadcast Interface (SBI) Neighbors 298 The possibly unique set of adjacent nodes in each node often requires 299 nodes to forward packets out the same wireless interface as the one 300 over which they were received. Topologically, this act of forwarding 301 out the same interface causes a packet to reach a possibly different 302 set of nodes by traversing the wireless communication medium in a new 303 location. An example is provided in Figure 2, where each router is 304 capable of reaching a different set of routers. 306 The act of forwarding packets out of the same interface as the one 307 over which they were received often results in duplicate IP packets 308 being received at nodes with more than one neighbor, while also 309 reaching a new subset of nodes. 311 6.2. Fuzzy Neighbor Relationship & Extended Neighborhood 313 Defining the process of determining a neighbor's existence, continued 314 existence, and loss of existence in MANET is arguably the fundamental 315 challenge in MANETs. Neighbors are hard to define due to the 316 expected interface characteristics: non-transitive, non-reflexive, 317 time varying, and other wireless properties. 319 Historically, two nodes are either neighbors or not neighbors and 320 several simple mechanisms have been used to determine a neighbor 321 relationship: single packet reception, acceptable loss rates, and 322 simple handshakes. In wireless networks the types of neighbor 323 relationships expand, as do the mechanisms to detect the state of 324 such relationships. 326 In wireless networks, nodes may often have non-reflexive (also often 327 seen called unidirectional or asymmetric) communication links. 328 Wireless networks also experience significant time varying packet 329 delivery, so simple loss rates may not be sufficient to define a 330 neighbor relationship. Similarly, as nodes move in relationship to 331 each other past loss rates may not reflect future communication 332 capabilities. 334 In wireless systems there is often a lot of communication connectivty 335 between nearby nodes. These nodes form an extended neighbor 336 relationships that is referred to as a neighborhood. A neighborhood 337 is typically composed of several nodes, where each node densely 338 connected to other nodes. 340 These complex neighbor relationships do not sit well with certain 341 Internet Protocols designed assuming an Ethernet like model to 342 communication links (reflexive, transitive, and stable). Given the 343 unknown neighbor relationships, the addressing model often associated 344 with a Ethernet link is not valid. For example, in an Ethernet 345 network routers are often told that a particular range of addresses 346 are directly reachable. In MANETs' a node often cannot make 347 assumptions that a particular set of addressable nodes is always 348 reachable. Instead, nodes must detect and determine their neighbors, 349 and handle the changes to their neighbors over time. 351 6.3. MANET Membership 353 Given MANETs' characteristics (mobile, wireless, ad hoc) determining 354 a MANETs' membership is difficult, if not impossible in certain 355 scenarios. 357 /----------------------\ /----------------------\ 358 | MANET | | MANET | 359 | +---+ +---+ +---+ | | +---+ +---+ +---+ | 360 | |RT1+-+RT2+-+RT3| | | |RT1+-+RT2+-+RT3| | 361 | +-+-+ +---+ +---+ | | +---+ +---+ +-+-+ | 362 | | | | | | 363 | +-+-+ | Change | +-+-+ | 364 | |RT4+ | in | |RT7| | 365 | +---+\ | Time | +---+ | 366 | \+---+ | \----------------------/ 367 | +RT5+ | /----------------------\ 368 | /+---+\ | | MANET | 369 | +---+/ \+---+ | | +---+ +---+ +---+ | 370 | |RT6+ +RT7| | | |RT6+--+RT4+--+RT5| | 371 | +---+ +---+ | | +---+ +---+ +---+ | 372 \----------------------/ \----------------------/ 374 Figure 3: MANET(s) 376 At one moment a MANET might consist of a certain set of nodes, and 377 the next the MANET could partition into several MANETs. Later it 378 might re-merge or merge with a new set of nodes and form a larger 379 MANET. 381 To assist in coordinating among a loosely connected set of MANET 382 routers, a procedure called flooding is used. MANET flooding consist 383 of disseminating a packet to all connected MANET routers. 385 Certain routers in a MANET might connect to other routing regions. 386 These routers are called MANET Border Routers (MBR), and they often 387 run multiple routing protocol instances. The MBR are responsible for 388 choosing the routing information to share between the various 389 attached routing regions. The MBR should also present a consistent 390 picture of the nodes reachable through them. 392 As MANET membership changes, so does the connectivty of MBR within 393 the MANET. Therefore, a MBR may be challenged to present a 394 consistent set of reachable nodes. It may even choose not to share 395 routing information about the MANET topology to other routing 396 regions. 398 7. Other Important Discussion 400 7.1. MANETs' Place in the Network Stack 402 While the MANET WG is focused upon network (L3) routing, that does 403 not imply that MANETs and their protocols are limited to L3. Several 404 previous and existing efforts are applying MANET protocols at various 405 layers. The challenges discussed above, exist independent of at 406 which layer MANET protocols are deployed. Of course, the protocols 407 themselves may need to be retooled slightly to accommodate the 408 information available to the deployed layer. 410 MANET MAC layer (L2) routing, more often called bridging, works well 411 in homogeneous wireless networks for delivering frames over multiple 412 hops. One example of L2 MANET is being developed in the IEEE 802.11s 413 WG. 415 L2 routing/bridging hides the multiple L2 hops from L3. This 416 behavior can be advantageous as this network can transparently mimic 417 an Ethernet, to some extent. The ability to mimic Ethernet allows 418 the L2 MANET to utilize existing L3 network protocols. 420 L2 MANET does not enable heterogeneity. That is, L2 MANET is not 421 capable of bridging across heterogeneous interfaces. For example, L2 422 bridging cannot directly bridge two L2 technologies with different 423 addressing schemes. It can also be difficult if the frame sizes of 424 two L2 vary, as this could require breaking a single frame into 425 multiple frames of a different format. 427 L3 MANET enables heterogeneous networking, as IP was built with this 428 feature in mind. Forming a MANET at L3 implies that the L3 protocols 429 must handle the challenges presented in this document. 431 MANET like protocols can also be used at higher layers. One example 432 is peer-to-peer (P2P) networks. These networks have some of the same 433 challenges as MANET, e.g. variable neighbor relationships and 434 changing membership. 436 7.2. Cross Layering 438 In wireless networks, and especially in MANET, extended interfacing 439 among the network layers (physical, MAC, link, network, etc) can be 440 extremely useful. Arguably, MANET may not be capable of successful 441 deployment without some degree of cross layering. For example, link 442 layer feedback that a packet/frame was not able to be sent or that it 443 was not received could be used by the network layer to indicate that 444 a neighbor is no longer reachable. This information and other 445 extended interfacing could reduce, or eliminate, some upper layer 446 messaging. Further, it could significantly reduce the latency in 447 decision making. Note that though a certain lower information is 448 valuable, it likely needs to be extrapolated or filtered before 449 accurate assumptions about the network state can be made. For 450 example, failure to deliver a frame by itself may not be a good 451 indicator that a node is or is not reachable. 453 In networks with several different layers of MANET mechanism, the 454 sharing of information across different layers can be even more vital 455 to creating and maintaining the network. For example, if a P2P 456 network is run on top of a L3 MANET, the two networks can share 457 information to use a similar optimized topology. Similarly, they 458 could share neighbor state changes to reduce the messaging or latency 459 in making decisions. 461 8. Deployment Taxonomy 463 The present and future proliferation of inexpensive wireless 464 interfaces continues to stimulate technical interest and developments 465 in the area of MANET for a wide variety of deployment scenarios. In 466 this section, we present several characteristics for describing 467 expected MANET deployments. 469 8.1. Service Availability 471 Nodes often expect certain services/servers to be available. When 472 describing a deployment scenario, it is important to specify the 473 expected services available and the distance between the servers and 474 the clients. In MANET, nodes might assume a service is available 475 locally (within one IP hop) or within a particular scope (one or more 476 IP hops - MANET, site, global). Nodes might assume in certain 477 deployments that no special servers/services are available. Finally, 478 nodes might assume that servers are sometimes available, but their 479 availability is not guaranteed or ensured. 481 Different frameworks for autoconfiguration, network management, and 482 intra-AS routing can be developed based upon the expected constraints 483 and operating conditions. 485 8.2. Number of Peer MANET Routers 487 The number of peer MRs in a MANET is an important consideration. 488 This number is not the complete number of nodes in a MANET (since MRs 489 may support an arbitrary number of connected nodes) but a measure of 490 the number of peer MR participating as a cohesive flat routing area. 491 While the number of MRs does not define scalability of a MANET 492 protocol, it is often useful discuss the number of peer MR to get a 493 feel for maturity of typical deployment solutions. For simplicity we 494 define the following network sizes to aid in discussion: 496 Small 497 2-30 MANET peers 499 Moderate 500 30-100 MANET peers 502 Large 503 100-1000 MANET peers 505 Very large 506 Larger than 1000 MANET peers 508 At the time of writing, small and moderate size peer MANET routing 509 scenarios have matured and have reasonable testing and deployment 510 experience. These sizes can perform reasonably well in many cases 511 without hierarchy. MANET architectures can, of course, support 512 routing hierarchies to improve scaling. Large and very large MANET 513 routing areas that are flat are still a topic of active research and 514 are not considered here. Existing MANET routing developments, such 515 as SMF [I-D.ietf-manet-smf], have shown significant performance 516 improvements and capabilities even in small peer router size 517 deployments and experiments. 519 8.3. Example Deployments 521 Here we provide a short list of example deployment scenarios: 523 Home, office, campus, and community mesh networks 525 Disaster relief and first responder networks 527 Sensor networks 529 Range extension 531 Military communications 533 Automotive networks 535 9. Security Considerations 537 TBD 539 10. IANA Considerations 541 This is an informational document. IANA requirements for MANET 542 related protocols will be developed within the protocol 543 specifications for MANET protocols. 545 11. Acknowledgments 547 Discussions and developments concepts and architectural issues have 548 evolved over many years of discussion of related work within the 549 MANET WG. There are obviously many people that have contributed to 550 past discussions and related draft documents within the WG that have 551 influenced the development of these concepts that deserve 552 acknowledgment. The authors would like to thank all contributors to 553 the MANET and AUTOCONF WG efforts and those that have helped in the 554 review and content process. 556 While not entirely complete the authors would like to in 557 particular thank the following individuals for there discussions 558 and contributions: 560 Fred Templin 562 Christopher Dearlove 564 Charles Perkins 566 Justin Dean 568 Subhranshu Singh 570 Tom Henderson 572 Emmanuel Baccelli 574 Dave Thaler 576 Jari Akko 578 Thomas Narten 580 Seung Yi 582 12. Informative References 584 [FL01] Freebersyser, J. and B. Leiner, "A DoD perspective on 585 mobile ad hoc networks", Addison Wesley C. E. Perkin, Ed., 586 2001, pp. 29--51, July 2001. 588 [I-D.ietf-ipv6-2461bis] 589 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 590 draft-ietf-ipv6-2461bis-08 (work in progress), 591 September 2006. 593 [I-D.ietf-manet-smf] 594 Macker, J., "Simplified Multicast Forwarding for MANET", 595 draft-ietf-manet-smf-02 (work in progress), March 2006. 597 [I-D.templin-autoconf-dhcp] 598 Templin, F., "MANET Autoconfiguration using DHCP", 599 draft-templin-autoconf-dhcp-01 (work in progress), 600 June 2006. 602 [I-D.thaler-autoconf-multisubnet-manets] 603 Thaler, D., "Multi-Subnet MANETs", 604 draft-thaler-autoconf-multisubnet-manets-00 (work in 605 progress), February 2006. 607 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 608 RFC 1812, June 1995. 610 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 612 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 613 November 1998. 615 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 616 (IPv6) Specification", RFC 2460, December 1998. 618 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 619 Discovery for IP Version 6 (IPv6)", RFC 2461, 620 December 1998. 622 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 623 (MANET): Routing Protocol Performance Issues and 624 Evaluation Considerations", RFC 2501, January 1999. 626 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 627 (IPv6) Addressing Architecture", RFC 3513, April 2003. 629 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 630 RFC 3753, June 2004. 632 Authors' Addresses 634 Ian Chakeres 635 Boeing 636 The Boeing Company 637 P.O. Box 3707 Mailcode 7L-49 638 Seattle, WA 98124-2207 639 USA 641 Email: ian.chakeres@gmail.com 643 Joe Macker 644 Naval Research Laboratory 645 Washington, DC 20375 646 USA 648 Email: macker@itd.nrl.navy.mil 650 Thomas Heide Clausen 651 LIX, Ecole Polytechnique 652 91128 Palaiseau CEDEX 653 France 655 Email: T.Clausen@computer.org 656 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 658 Intellectual Property Statement 660 The IETF takes no position regarding the validity or scope of any 661 Intellectual Property Rights or other rights that might be claimed to 662 pertain to the implementation or use of the technology described in 663 this document or the extent to which any license under such rights 664 might or might not be available; nor does it represent that it has 665 made any independent effort to identify any such rights. Information 666 on the procedures with respect to rights in RFC documents can be 667 found in BCP 78 and BCP 79. 669 Copies of IPR disclosures made to the IETF Secretariat and any 670 assurances of licenses to be made available, or the result of an 671 attempt made to obtain a general license or permission for the use of 672 such proprietary rights by implementers or users of this 673 specification can be obtained from the IETF on-line IPR repository at 674 http://www.ietf.org/ipr. 676 The IETF invites any interested party to bring to its attention any 677 copyrights, patents or patent applications, or other proprietary 678 rights that may cover technology that may be required to implement 679 this standard. Please address the information to the IETF at 680 ietf-ipr@ietf.org. 682 Disclaimer of Validity 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 687 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 688 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 689 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 Copyright Statement 694 Copyright (C) The Internet Society (2006). This document is subject 695 to the rights, licenses and restrictions contained in BCP 78, and 696 except as set forth therein, the authors retain all their rights. 698 Acknowledgment 700 Funding for the RFC Editor function is currently provided by the 701 Internet Society.