idnits 2.17.1 draft-ietf-autoconf-statement-04.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 637. 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 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 (February 25, 2008) is 5876 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: '2' is defined on line 512, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 528, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 531, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 536, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 546, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 549, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 555, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-autoconf-manetarch (ref. '1') -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2740 (ref. '9') (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '12') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '17') (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) 3 Internet-Draft INRIA 4 Expires: August 28, 2008 February 25, 2008 6 Address Autoconfiguration for MANET: Terminology and Problem Statement 7 draft-ietf-autoconf-statement-04 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 28, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document states the problems pertaining to automatic IPv6 41 address configuration and prefix allocation in MANETs. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. MANET Categories . . . . . . . . . . . . . . . . . . . . . . . 5 48 3.1. Subordinate MANET . . . . . . . . . . . . . . . . . . . . 5 49 3.1.1. Scenarios of Subordinate MANETs . . . . . . . . . . . 6 50 3.2. Autonomous MANET . . . . . . . . . . . . . . . . . . . . . 6 51 3.2.1. Scenarios of Autonomous MANETs . . . . . . . . . . . . 7 52 4. MANET Autoconfiguration Goals . . . . . . . . . . . . . . . . 8 53 5. Applicability of standard configuration solutions . . . . . . 9 54 5.1. Applicability of DHCP . . . . . . . . . . . . . . . . . . 9 55 5.1.1. Issues with DHCP Fundamental Assumptions . . . . . . . 9 56 5.1.2. What DHCP Can and Cannot Do in MANETs . . . . . . . . 10 57 5.2. Applicability of SLAAC/NDP . . . . . . . . . . . . . . . . 10 58 5.2.1. Issues with SLAAC/NDP Fundamental Assumptions . . . . 10 59 5.2.2. What SLAAC/NDP Can and Cannot Do in MANETs . . . . . . 11 60 5.3. Applicability of DHCP-PD . . . . . . . . . . . . . . . . . 11 61 5.3.1. Issues with DHCP-PD Fundamental Assumptions . . . . . 11 62 5.3.2. What DHCP-PD Can and Cannot Do in MANETs . . . . . . . 11 63 6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 12 64 6.1. Solutions Requirements . . . . . . . . . . . . . . . . . . 12 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 70 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 Intellectual Property and Copyright Statements . . . . . . . . . . 22 75 1. Introduction 77 As defined in [1], a MANET is a network composed of MANET routers, 78 each of which has at least one MANET interface. This document states 79 the goals of autoconfiguration mechanism(s) for MANETs, with respect 80 to the necessary parameters for basic IP identification. 81 Specifically, this document thus states the requirements for: 83 - autoconfiguring MANET interfaces with IPv6 addresses; 85 - automatic allocation of IPv6 prefixes to MANET routers. 87 2. Terminology 89 This document uses the terminology defined in [1], as well as the 90 following terms : 92 External Network - a network connected to the MANET, through an 93 interface that is not part of this MANET. 95 Subordinate MANET - a MANET, which is connected to one or more 96 external network(s), and where such external network(s) are 97 imposing an addressing hierarchy scheme on the MANET. 99 Autonomous MANET - a MANET upon which no external network imposes an 100 addressing hierarchy. 102 Address autoconfiguration - the process of configuring an interface 103 with a given address, using an automatic mechanism (contrary to 104 manual configuration). 106 Prefix allocation - the process of providing a router with authority 107 over an aggregatable pool of addresses (i.e. a prefix), for the 108 purpose of configuring its interfaces, or other nodes. 110 Disjoint prefixes - two prefixes are said to be disjoint if and only 111 if their respective address ranges do not overlap. 113 Network merging - the process by which two or more previously 114 disconnected MANETs get connected. 116 Network partitioning - the process by which a MANET splits into two 117 or more disconnected MANETs. 119 3. MANET Categories 121 IP address autoconfiguration on MANET interfaces and prefix 122 allocation for MANET routers may be used in a number of deployment 123 scenarios. This section outlines the different types of scenarios 124 that are to be addressed by solutions for MANET autoconfiguration. 126 3.1. Subordinate MANET 128 A subordinate MANET, as shown in Fig. 1, is a MANET which is 129 connected to at least one external network N that imposes a specific 130 addressing hierarchy on the MANET. In a subordinate MANET, this 131 addressing hierarchy yields the use of specific prefixes for 132 communications between nodes in the MANET and nodes in or across 133 network N. For instance, in Fig. 1, these prefixes need to be 134 topologically correct, i.e. allocated from within a prefix p::, over 135 which the point of attachment to network N has authority. 137 '. / 138 `. Network N / 139 `. _,' 140 `-.__ _,,' 141 `'-.,._,,'' 142 : Topologically correct prefix 143 +-:-+ p:: with respect to network N 144 |MNR| 145 +-|-+ 146 +-+ +---+ / /|\ \ +---+ 147 | |...MNR--- .-. ---MNR| 148 +-+ +---+ \ ,-( _)-. / +---+ 149 .-(_ MANET )-. 150 Other ( Communication ) 151 Nodes `-(______)-' 152 and \|/ \|/ 153 Networks +-|-+ +-|-+ 154 |MNR| \|/ |MNR| 155 +-:-+ +-|-+ +-:-+ 156 |MNR| : 157 +-:-+ +-+ 158 +-+ 160 Figure 1: Subordinate MANET. Imposed address 161 hierarchy by external network N. 163 3.1.1. Scenarios of Subordinate MANETs 165 This section contains a non-exhaustive list of examples of MANETs 166 falling in the subordinate category. 168 A typical example of subordinate MANET is a MANET that is part of the 169 Internet, which yields the use of topologically correct IP addresses 170 in order to communicate over the Internet. For instance public 171 wireless mesh networks, i.e. scattered fixed WLAN access routers 172 participating in a MANET of mobile users, and acting as border 173 routers. 175 Another typical example is the coverage extension of a fixed wide- 176 area wireless network, where one or more MANET router(s) are 177 connected to the Internet through technologies such as UMTS or WiMAX. 179 Vehicle communication networks connected to an external 180 infrastructure may also be understood as an instance of subordinate 181 MANET. 183 3.2. Autonomous MANET 185 Autonomous MANETs are MANETs upon which no external network imposes 186 an addressing hierarchy. This is shown in Fig. 2, as opposed to the 187 subordinate MANET category described in Section 3.1. 189 +---+ 190 |MNR| 191 +-|-+ 192 +-+ +---+ / /|\ \ +---+ 193 | |...MNR--- .-. ---MNR| 194 +-+ +---+ \ ,-( _)-. / +---+ 195 .-(_ MANET )-. 196 Other ( Communication ) 197 Nodes `-(______)-' 198 and \|/ \|/ 199 Networks +-|-+ +-|-+ 200 |MNR| \|/ |MNR| 201 +-:-+ +-|-+ +-:-+ 202 |MNR| : 203 +-:-+ +-+ 204 +-+ 206 Figure 2: Autonomous MANET. No subordination to an 207 addressing scheme imposed by an external network. 209 3.2.1. Scenarios of Autonomous MANETs 211 This section contains a non-exhaustive list of instances of MANETs 212 falling in the autonomous category. 214 Typical examples of autonomous MANETs are networks set-up in areas 215 where infrastructure is unavailable or inappropriate. For instance, 216 car-to-car communication for sharing traffic and safety-related 217 information, on-site emergency communication among rescue team 218 members for disaster recovery, file sharing in conference or class 219 rooms. 221 4. MANET Autoconfiguration Goals 223 The goals of AUTOCONF is to provide autoconfiguration mechanisms 224 which allow each MANET router to: 226 1. configure IPv6 addresses that are unique within the MANET, on 227 their MANET interface(s). 229 2. be allocated IPv6 prefixes that are disjoint from prefixes 230 allocated to other routers within the MANET. 232 3. maintain, within the MANET, the uniqueness of configured addresses 233 and the disjoint character of allocated prefixes (even in case of 234 network merging). 236 4. be allocated topologically correct prefixes, in the subordinate 237 MANET scenario. 239 5. Applicability of standard configuration solutions 241 This section reviews the applicability of existing standard protocols 242 for the purposes listed in Section 4. Note that MANET routers are 243 assumed to also run these standard protocols as usual over non-MANET 244 interfaces, if any. 246 5.1. Applicability of DHCP 248 DHCP [4] enables automatic allocation of an IP address to a node by a 249 DHCP server. A node requiring an IP address contacts a DHCP server 250 and requests an address. The DHCP server will dynamically assign an 251 address from a certain pool of addresses, and allocate a so called 252 ''lease'' of that address to the client. The client can then use the 253 address for a certain time. If the client wants to keep the address 254 for a longer time, it has to prolong the lease. If the DHCP server 255 is not on the same link as the DHCP client, it is possible to use one 256 or more DHCP relay agent to forward the messages to a different 257 subnet. 259 5.1.1. Issues with DHCP Fundamental Assumptions 261 DHCP works on the basic assumption that every node in the MANET can 262 directly communicate with either (i) the DHCP server, or (ii) a DHCP 263 relay which can communicate with either the DHCP server or another 264 relay. 266 As described in [1], part (i) of this assumption is often wrong in a 267 MANET, as each node may see a different set of neighboring MANET 268 nodes. On the other hand, part (ii) of this assumption relies on the 269 guarantee that the recursion will end at some point (by reaching the 270 root, i.e. the DHCP server). Because of the dynamics in MANET 271 topology and MANET membership described in [1], there is no such 272 assurance in a MANET, as the DHCP server may be unreachable, or a 273 loop may have appeared along the path. 275 Moreover, DHCP works with the assumption that either (a) there is a 276 unique DHCP server in the network, or (b) if there are several DHCP 277 servers in the network, they are manually configured accordingly. 278 Because of the dynamics in MANET membership described in [1], there 279 is no such assurance in a MANET, as topology changes may produce a 280 situation where several servers with conflicting configuration 281 parameters (e.g. managing non-disjoint pools of local addresses) 282 become part of the same MANET. Servers may thus require dynamic 283 (re)configuration. 285 Similarly, DHCP works with the assumption that should there be DHCP 286 relays, they benefit from appropriate manual configuration. Because 287 of the dynamics in MANET membership and topology described in [1], 288 there is no such assurance in a MANET. Configuration may not remain 289 appropriate over time, and relays may thus require dynamic 290 (re)configuration. 292 5.1.2. What DHCP Can and Cannot Do in MANETs 294 DHCP "as is" could be used to some extent for address configuration 295 purposes (goal 1, listed in Section 4). However DHCP's applicability 296 in this context is limited. Indeed, if the topology is or becomes 297 such that a MANET router does not have access to a DHCP server 298 directly nor through a relay, DHCP is not operational. 300 DHCP "as is" could also be used to some extent for uniqueness 301 maintenance purposes (goal 3, listed in Section 4). However DHCP's 302 applicability in this context is limited. Since different DHCP 303 servers will not automatically check the disjoint character of the 304 pools of addresses they provide leases from, if the topology is or 305 becomes such that several DHCP servers with conflicting configuration 306 lease addresses in the same MANET, there is no guarantee that 307 configured addresses will indeed be unique. 309 5.2. Applicability of SLAAC/NDP 311 Stateless Address Autoconfiguration (SLAAC [5]) enables automatic 312 configuration of an IP address to a host without contacting any kind 313 of server. A host first constructs a tentative IPv6 address by 314 attaching its host identifier (in most cases its MAC address) to the 315 well-known link-local prefix. It then operates duplicate address 316 detection, that verifies that no other host on the link has the same 317 address by broadcasting NDP messages [3]. If the address is not 318 unique, the autoconfiguration process will abort. Upon a successful 319 address uniqueness test, a host may request a prefix from any router 320 on the link by an exchange of NDP messages. It will again attach its 321 host identifier to that router prefix and repeats the address 322 uniqueness test sequence. 324 5.2.1. Issues with SLAAC/NDP Fundamental Assumptions 326 SLAAC relies on NDP signalling, which works on the basic assumption 327 that each node in the MANET can communicate directly with every other 328 node in the MANET, i.e. all the nodes are connected to a single 329 multicast-enabled link. As described in [1], this assumption is 330 often wrong in a MANET, as each node may see a different set of 331 neighboring MANET nodes. 333 5.2.2. What SLAAC/NDP Can and Cannot Do in MANETs 335 SLAAC "as is" could be used to some extent for address configuration 336 and uniqueness maintenance purposes (goal 1 and 3, listed in 337 Section 4), for instance when no DHCP server is available. However 338 SLAAC's applicability in this context is limited, since NDP messages 339 are not relayed beyond the ''link'' (or in MANET terms, beyond the 340 first hop). If topology is or becomes such that the MANET is not 341 contained in a single hop, there is no guarantee that the configured 342 addresses will indeed be unique, since signalling will not reach all 343 the concerned nodes. 345 5.3. Applicability of DHCP-PD 347 DCHP-PD [17] is a DHCP option that enables automatic allocation of 348 IPv6 prefixes to routers using DHCP. A router may request a prefix 349 allocation from a DHCP server by sending a DHCP request including the 350 Prefix Delegation option. The server may then delegate a sub-prefix 351 (i.e. a subset of its address pool) to the router. The DHCP message 352 containing the Prefix Delegation option may be relayed through one or 353 more DHCP relays, as per [4]. 355 5.3.1. Issues with DHCP-PD Fundamental Assumptions 357 DHCP-PD is based on DHCP, and thus encounters the fundamental issues 358 described in Section 5.1.1, with respect to server reachability, and 359 dynamic (re)configuration of servers and relays. 361 5.3.2. What DHCP-PD Can and Cannot Do in MANETs 363 DHCP-PD "as is" could be used to some extent for prefix allocation 364 purposes (goals 2 and 4 listed in Section 4) and for uniqueness 365 maintenance purposes (goal 3, listed in Section 4). However DHCP- 366 PD's applicability in this context is limited. If topology is or 367 becomes such that the MANET router cannot communicate with a DHCP 368 server, DHCP-PD is not operational. Moreover, if topology is or 369 becomes such that several servers with conflicting configuration 370 become part of the same MANET, there are no automatic 371 (re)configuration mechanisms available in order for servers to 372 dynamically adapt to the situation. 374 6. Problem Statement 376 SLAAC, NDP, DHCP and DHCP-PD provide only a partial solution with 377 respect to the goals listed in Section 4. As explained in 378 Section 5.1, Section 5.2, and Section 5.3, existing protocols "as is" 379 cannot deal with the specific dynamic, multi-hop and distributed 380 nature of MANETs. Additional solutions are thus needed to complete 381 the goals of MANET IPv6 autoconfiguration. 383 6.1. Solutions Requirements 385 The following list presents the requirements for potential IPv6 386 address autoconfiguration solutions: 388 R 01. Solutions must configure MANET interfaces with IPv6 addresses 389 that are unique within the MANET. 391 R 02. Solutions must configure routers within the same MANET with 392 disjoint prefixes. 394 R 03. Solution must work even without a MANET routing protocol. 395 However, solutions may leverage the presence of routing protocols, 396 for optimization purposes. 398 R 04. Solutions must provide a mechanism to prevent and deal with 399 address or prefix conflicts (due for instance to network merging, 400 change in MANET membership, preconfiguration or misconfiguration). 402 R 05. Solutions must be designed taking into account the particular 403 characteristics of MANETs [1], including their multi-hop nature, 404 and the potential asymetry of links. 406 R 06. Solutions must achieve their goal(s) with low control 407 overhead. 409 R 07. Solutions must achieve their goal(s) with low delay or 410 convergence time. 412 R 08. Solutions must ensure backward compatibility with other 413 standards defined by the IETF. 415 R 09. Solutions must not require modifications of existing protocols 416 on non-MANET interfaces and non-MANET routers. 418 R 10. Solutions should address security threats considered in 419 existing IPv6 autoconfiguration mechanisms. In addition, 420 solutions should address potential MANET-specific threats (see 421 Section 7). 423 R 11. Solutions should work in MANETs connected to an external 424 network via multiple border routers, as well as in MANETs 425 connected to multiple external networks. 427 R 12. In the case of subordinate MANETs, solutions should have a 428 minimal impact on the routing system of the external network(s) to 429 which a MANET is connected. In particular, this includes the 430 following: 432 R 12.1. Solutions should not preclude prefix aggregation at the 433 edge of the subordinate MANETs. 435 R 13. Solutions should support transitioning from one MANET scenario 436 to another (e.g. from subordinate to autonomous or vice-versa). 438 R 14. Solutions may be designed in a modular way, each module 439 addressing a specific subset of the requirements or scenarios. 441 7. Security Considerations 443 A significant security issue is that of maintaining the 444 confidentiality and the integrity of some data being exchanged 445 between communication end-points in the MANET (e.g. between a server 446 and a client). This task is equivalent to that of ensuring end-to- 447 end security in other types of networks, and existing techniques are 448 therefore applicable. 450 An orthogonal issue with respect to securing MANET protocols is 451 ensuring network integrity. So far, MANET protocols in general allow 452 any node to participate in the network - the assumption being that 453 all nodes are well-behaving and welcome. If that assumption fails, 454 i.e. if the network may count malicious nodes, the integrity of the 455 network may fail. Specific malicious behaviour include, but are not 456 limited to, jamming (resulting in DoS), incorrect traffic generation 457 (e.g. server, router or address spoofing), incorrect traffic relaying 458 (e.g. "man in the middle"), or replay attacks. Most of these threats 459 are already taken into account in RFC 3756, RFC 3971, and the 460 security sections of RFC 4861 and RFC 3315. 462 DoS attacks can highly penalize the operation of IP autoconfiguration 463 solutions, through increasing the signalling overhead and hence 464 harming the solutions' convergence time. "Man-in-the-middle" attacks 465 can cause (i) interception of the IP autoconfiguration messages and 466 hence operation failure, (ii) messages' modifications leading for 467 example to changing assigned IP addresses or prefixes during their 468 transfer and hence causing address or prefix conflicts, (iii) 469 impersonation, which allows a non-legitimate MANET router to 470 participate in the IP autoconfiguration process in place of a 471 legitimate node, and may lead to DoS. On the other hand, IP spoofing 472 can also lead to impersonation, whereby an IP address can be spoofed 473 by a non-legitimate node during transfer. 475 Existing security solutions usually protect network integrity through 476 authentication guaranteed by a "higher" authority, trusted a priori, 477 which typically issues the cryptographic keys used to authenticate. 478 However, for instance in autonomous MANET scenarios, there may not be 479 any "higher" authority, or if there is, it may not be trusted a 480 priori by every node in the MANET. 482 Encryption is thus essential to many existing security mechanisms. 483 However it may affect convergence time or require a process that is 484 too heavy in the context of MANETs, since a significant part of the 485 nodes in a MANET may have limited resources. 487 Another issue specific to MANETs is related to the potential 488 selfishness behaviour of some MANET nodes, a.k.a. "the selfish node 489 problem". This behaviour can cause non-cooperation between MANET 490 nodes during the IP autoconfiguration process, and hence affect the 491 operation of autoconfiguration mechanisms. 493 In the context of MANET IPv6 autoconfiguration, such MANET 494 characteristics are to be considered in addition to general 495 characteristics supported by existing IPv6 autoconfiguration 496 solutions. 498 8. IANA Considerations 500 This document does not specify IANA considerations. 502 9. References 504 9.1. Normative References 506 [1] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc 507 Network Architecture", ID draft-ietf-autoconf-manetarch, 508 February 2007. 510 9.2. Informative References 512 [2] Macker, J. and S. Corson, "MANET Routing Protocol Performance 513 Issues and Evaluation Considerations", RFC 2501, January 1999. 515 [3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 516 "Neighbor Discovery for IPv6", RFC 4861, September 2007. 518 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 519 Carney, "Dynamic Host Configuration Protocol for IPv6", 520 RFC 3315, July 2003. 522 [5] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address 523 Autoconfiguration", RFC 4862, September 2007. 525 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 526 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 528 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 529 Specific Routes", RFC 4191, 2005. 531 [8] Moy, J., "OSPF version 2", RFC 2328, 1998. 533 [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", 534 RFC 2740, 1999. 536 [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) 537 Allocations for the Mobile Ad hoc Networks (MANET) Working 538 Group", ID draft-ietf-manet-iana, May 2007. 540 [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 541 2001. 543 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 544 Address Autoconfiguration in IPv6", RFC 3041, 2001. 546 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 547 Neighbor Discovery (SEND)", RFC 3971, 2005. 549 [14] Aura, T., "Cryptographically Generated Addresses (CGA)", 550 RFC 3972, 2005. 552 [15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 553 IPv6", RFC 4429, 2006. 555 [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 556 Addresses", RFC 4193, 2005. 558 [17] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", 559 RFC 3633, 2003. 561 Contributors 563 Shubhranshu Singh, Samsung. 564 Email: Shubranshu@gmail.com 566 Kenichi Mase, Niigata University. 567 Email: Mase@ie.niigata-u.ac.jp 569 Simone Ruffino, Telecom Italia. 570 Email: Simone.Ruffino@telecomitalia.it 572 Carlos J. Bernardos, Universidad Carlos III de Madrid. 573 Email: cjbc@it.uc3m.es 575 Hassnaa Moustafa, France Telecom. 576 Email: Hassnaa.Moustafa@orange-ftgroup.com 578 Emmanuel Baccelli, INRIA. 579 Email: Emmanuel.Baccelli@inria.fr 581 Thomas Heide Clausen, LIX, Ecole Polytechnique. 582 Email: T.Clausen@computer.org 584 Acknowledgements 586 This document benefited from specific feedback, and helpful 587 discussions with C. Adjih, T. Boot, C. Dearlove, U. Herberg, G. 588 Montenegro, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar, F. Templin, 589 D. Thaler, R. Wakikawa, K. Weniger. 591 Editor's Address 593 Emmanuel Baccelli 594 INRIA 596 Phone: +33 1 69 33 55 11 597 Email: Emmanuel.Baccelli@inria.fr 599 Full Copyright Statement 601 Copyright (C) The IETF Trust (2008). 603 This document is subject to the rights, licenses and restrictions 604 contained in BCP 78, and except as set forth therein, the authors 605 retain all their rights. 607 This document and the information contained herein are provided on an 608 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 609 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 610 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 611 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 612 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 613 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 615 Intellectual Property 617 The IETF takes no position regarding the validity or scope of any 618 Intellectual Property Rights or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; nor does it represent that it has 622 made any independent effort to identify any such rights. Information 623 on the procedures with respect to rights in RFC documents can be 624 found in BCP 78 and BCP 79. 626 Copies of IPR disclosures made to the IETF Secretariat and any 627 assurances of licenses to be made available, or the result of an 628 attempt made to obtain a general license or permission for the use of 629 such proprietary rights by implementers or users of this 630 specification can be obtained from the IETF on-line IPR repository at 631 http://www.ietf.org/ipr. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights that may cover technology that may be required to implement 636 this standard. Please address the information to the IETF at 637 ietf-ipr@ietf.org. 639 Acknowledgment 641 Funding for the RFC Editor function is provided by the IETF 642 Administrative Support Activity (IASA).