idnits 2.17.1 draft-ietf-autoconf-statement-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 602. 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 (November 19, 2007) is 5996 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: '12' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 516, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 528, but no explicit reference was found in the text -- 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. '18') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 9 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: May 22, 2008 K. Mase 5 Niigata University 6 S. Ruffino 7 Telecom Italia 8 S. Singh 9 Samsung 10 November 19, 2007 12 Address Autoconfiguration for MANET: Terminology and Problem Statement 13 draft-ietf-autoconf-statement-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 22, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 Traditional dynamic IPv6 address assignment solutions are not adapted 47 to mobile ad hoc networks. This document elaborates on this problem, 48 states the need for new solutions, and requirements to these 49 solutions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Connected MANET . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 6 58 3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 6 59 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 7 61 4.1.1. Multi-hop Support . . . . . . . . . . . . . . . . . . 7 62 4.1.2. Dynamic Topology Support . . . . . . . . . . . . . . . 8 63 4.1.3. Network Merging Support . . . . . . . . . . . . . . . 8 64 4.1.4. Network Partitioning Support . . . . . . . . . . . . . 9 65 4.2. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 9 66 4.2.1. Address and Prefix Generation . . . . . . . . . . . . 10 67 4.2.2. Prefix and Address Uniqueness Requirements . . . . . . 10 68 4.2.3. Internet Configuration Provider Related Issues . . . . 11 69 5. Solutions Considerations . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Informative References . . . . . . . . . . . . . . . . . . . . 15 73 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 75 Intellectual Property and Copyright Statements . . . . . . . . . . 19 77 1. Introduction 79 A Mobile Ad hoc NETwork (also known as a MANET [1]) consists of a 80 loosely connected set of MANET routers. Each MANET router embodies 81 IP routing/forwarding functionality and may also incorporate host 82 functionality [2]. These routers dynamically self-organize and 83 maintain a routing structure among themselves, regardless of the 84 availability of a connection to any infrastructure. 86 MANET routers may be mobile and may communicate over symmetric or 87 assymetric wireless links. They may thus join and leave the MANET at 88 any time, at a rate that can be substantially higher than in usual 89 networks. 91 However, prior to participation in IP communication, each MANET 92 router that does not benefit from appropriate static configuration 93 needs to automatically acquire at least one IP address, and may also 94 need to be delegated an IP prefix. This address or this prefix may 95 be required to be unique within a given scope, or to be topologically 96 appropriate. 98 Standard automatic IPv6 address assignment and prefix delegation 99 solutions [5], [3] [4] do not work "as-is" on MANETs due to ad hoc 100 networks' unique characteristics [2]. Therefore new or modified 101 mechanisms are needed for operation within MANET scope, and this 102 document thus details and categorizes the issues that need to be 103 addressed. 105 2. Terminology 107 This document uses the terminology defined in [2], as well as the 108 following terms : 110 MANET Local Prefix (MLP) - An IP prefix delegated to a MANET router, 111 consisting in chunks of IP addresses valid for communications 112 inside the MANET. 114 MANET Local Address (MLA) - An IP address configured on a MANET 115 interface, and valid for communications inside the MANET. 117 Global prefix - An IP prefix delegated to a MANET router, consisting 118 in chunks of IP addresses valid for communications reaching 119 outside the MANET (as well as communications within the MANET). 121 Global address - An IP address configured on an interface and valid 122 for communications reaching outside the MANET (as well as 123 communications within the MANET). 125 Internet Configuration Provider (ICP) - A router that can provide 126 other routers requesting configuration with addresses or prefixes 127 derived from a global prefix. 129 Connected MANET - A mobile ad hoc network, which contains at least 130 one ICP. 132 Standalone MANET - A mobile ad hoc network, which does not contain 133 any ICP. 135 Network merger - The process by which two or more previously 136 disjoint ad hoc networks get connected. 138 Network partitioning - The process by which an ad hoc network splits 139 into two or more disconnected ad hoc networks. 141 Address generation - The process of selecting a tentative address 142 with the purpose of configuring an interface. 144 Address assignment - The process of configuring an interface with a 145 given address. 147 Prefix delegation - The process of providing a router with a set of 148 contiguous addresses it may manage for the purpose of configuring 149 interfaces or other routers. 151 Pre-service address uniqueness - The property of an address which is 152 assigned at most once within a given scope, and which is unique, 153 before it is being used. 155 In-service address uniqueness - The property of an address which was 156 assigned at most once within a given scope, and which remains 157 unique over time, after the address has started being used. 159 3. Deployment Scenarios 161 Automatic configuration of IP addresses on MANET interfaces and 162 prefix delegation to MANET routers are necessary in a number of 163 deployment scenarios. This section outlines the different categories 164 of scenarios that are considered. 166 3.1. Connected MANET 168 Connected MANETs are mobile ad hoc networks which contain at least 169 one ICP, i.e. a router that can provide other routers requesting 170 configuration with addresses or prefixes derived from a global 171 prefix. Routers joining a connected MANET may either (i) have no 172 previous configuration, or (ii) already own pre-configured local or 173 global IP addresses (or prefixes). 175 Typical instances of this scenario include public wireless networks 176 of scattered fixed WLAN Access Points participating in a MANET of 177 mobile users, and acting as MANET border routers. Another example of 178 such a scenario is coverage extension of a fixed wide-area wireless 179 network, where one or more mobile routers in the MANET are connected 180 to the Internet through technologies such as UMTS or WiMAX. 182 3.2. Standalone MANET 184 Standalone MANETs are mobile ad hoc networks which do not contain any 185 ICP, i.e. which do not contain any router able to provide other 186 routers requesting configuration with addresses or prefixes derived 187 from a global prefix. Again, routers joining a standalone MANET may 188 either have (i) no previous configuration, or (ii) pre-configured 189 local or global IP addresses (or prefixes). Due to potential network 190 partitions and mergers, standalone MANETs may be composed of routers 191 of either types. 193 Typical instances of this scenario include private or temporary 194 networks, set-up in areas where neither wireless coverage nor network 195 infrastructure exist (e.g. emergency networks for disaster recovery, 196 or conference-room networks). 198 3.3. Deployment Scenarios Selection 200 Both "Standalone MANET" and "Connected MANET" scenarios are to be 201 addressed by solutions for MANET autoconfiguration. Note that 202 solutions should also aim at addressing cases where a MANET transits 203 from one scenario to an other. 205 4. Problem Statement 207 This section details the goals of MANET autoconfiguration. A 208 taxonomy of autoconfiguration issues specific to MANETs is then 209 elaborated. 211 4.1. MANET Autoconfiguration Goals 213 A MANET router needs to configure IP addresses and prefixes as usual, 214 on its non-MANET interfaces as well as its attached hosts and 215 routers, if any. In addition, a MANET router needs to configure at 216 least one IP address on its MANET interface, this being a link local 217 address, an MLA or a global address. A MANET router may also require 218 a delegated MLP, provided prefix uniqueness is guaranteed [2]. 220 The primary goal of MANET autoconfiguration is thus to provide 221 mechanisms for IPv6 prefix delegation and address assignment for 222 operation on mobile ad hoc networks. Note that this task is distinct 223 from that of propagating knowledge about address or prefix location, 224 as a routing protocol does (see for example [8], [9]), or as 225 described in [7]. 227 The mechanisms employed by solutions to be designed must address the 228 distributed, multi-hop nature of MANETs [2], and be able to follow 229 topology and connectivity changes by (re)configuring addresses and/or 230 prefixes accordingly. 232 Traditional dynamic IP address assignment protocols, such as [5], [3] 233 or [4], do not work efficiently (if at all) on MANETs, due to these 234 networks' unique properties. The following thus overviews what must 235 be specifically supported for efficient operation on mobile ad hoc 236 networks. 238 4.1.1. Multi-hop Support 240 Traditional solutions assume that a broadcast directly reaches every 241 router or host on the subnetwork, whereas this generally is not the 242 case in MANETs (see [2]). Some routers in the MANET will typically 243 assume multihop broadcast, and expect to receive through several 244 intermediate relayings by peer MANET routers. For example, in Fig. 245 1, the MANET router MR3 cannot communicate directly with a DHCP 246 server [4] that would be available through a MANET border router, 247 since the server and the MANET router are not located on the same 248 logical link. While DHCP can to some extent overcome this issue in a 249 static network, it is not the case in a dynamic topology, as 250 explained below. 252 ----- MR1...MR3 253 / . 254 +-------------+ +------------+ / . 255 | | p2p | MANET |/ . 256 | ISP Edge | Link | Border | . 257 | Router +---------+ Router |\ . 258 | | | | \ . 259 +-------------+ +------------+ \----- MR2 261 Fig. 1. Connected MANET router topology. 263 4.1.2. Dynamic Topology Support 265 A significant proportion of the routers in the MANET may be mobile 266 with wireless interface(s), leading to ever changing neighbor sets 267 for most MANET routers (see [1]). Therefore, network topology may 268 change rather dynamically compared to traditional networks, which 269 invalidates traditional delegation solutions that were developed for 270 infrastructure-based networks, such as [11], which do not assume 271 intermittent reachability of configuration server(s), and a 272 potentially ever changing hierarchy among devices. For instance, in 273 Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with 274 DHCP [4], it cannot be assumed that MR1 and MR3 will not move and 275 become unable to communicate directly. Moreover, possible frequent 276 reconfiguration due to intermittent reachability cause [5] to be less 277 efficient than expected, due to large amounts of control signalling. 279 In particular, supporting multihop dynamic topologies means that even 280 if some address configuration servers are present somewhere, it 281 cannot be assumed that they are reachable most of the time, contrary 282 to usual scenarios. Therefore, reusing "as-is" existing solutions 283 (for instance [4]) using servers on a MANET would basically imply 284 that "everyone is a server" in order to ensure server reachability. 285 This implication is the specificity of MANETs that brings the 286 requirement for new levels of service distribution, since the 287 "everyone is a server" approach is essentially not functional. 289 4.1.3. Network Merging Support 291 Network merging is a potential event that was not considered in the 292 design of traditional solutions, and that may greatly disrupt the 293 autoconfiguration mechanisms in use (see [2]). Examples of network 294 merging related issues include cases where a MANET A may feature 295 routers and hosts that use IP addresses that are locally unique 296 within MANET A, but this uniqueness is not guaranteed anymore if 297 MANET A merges with another MANET B. If address uniqueness is 298 required within the MANET (see Section 4.2.2), issues arise that were 299 not accounted for in traditional networks and solutions. For 300 instance, [5] and [3] test address uniqueness via messages that are 301 sent to neighbors only, and as such cannot detect the presence of 302 duplicate addresses configured within the network but located several 303 hops away. However, since MANETs are generally multi-hop, detection 304 of duplicate addresses over several hops is a feature that may be 305 required for MANET interface address assignment (see Section 4.2.2). 307 4.1.4. Network Partitioning Support 309 Network partitioning is a potential event that was not considered in 310 the design of traditional solutions, and that may invalidate usual 311 autoconfiguration mechanisms (see [2]). Examples of related issues 312 include cases such as a standalone MANET, whereby connection to the 313 infrastructure is not available, possibly due to network partitioning 314 and loss of connectivity to a MANET border router. The MANET must 315 thus function without traditional address allocation server 316 availability. While stateless protocols such as [5] and [3] could 317 provide IP address configuration (for MANET interfaces, loopback 318 interfaces), these solutions do not provide any mechanism for 319 allocating "unique prefix(es)" to routers in order to enable the 320 configuration of host interfaces. 322 ----- MR1...MR3...MR5 323 / . 324 / . 325 / . 326 MR4 . 327 \ . 328 \ . 329 \----- MR2 331 Fig. 2. Standalone MANET router topology. 333 4.2. MANET Autoconfiguration Issues 335 Taking into account the shortcomings of traditional solutions in the 336 mobile ad hoc context, this section categorizes general issues with 337 regards to MANET autoconfiguration. 339 4.2.1. Address and Prefix Generation 341 The distributed nature of MANETs brings the need for address 342 generation algorithms that can complement existing solutions by 343 supporting operation outside "client-server" schemes and without 344 fixed hierarchies to provide routers with appropriate addresses and 345 prefixes. In addition, the multi-hop aspect of MANETs brings 346 specific needs as far as address and prefix uniqueness is concerned, 347 as detailed below. 349 4.2.2. Prefix and Address Uniqueness Requirements 351 If prefix or address uniqueness is required within a specific scope, 352 and if the address/prefix generation mechanism in use does not ensure 353 address/prefix uniqueness, then additional issues arise. This 354 section overviews these problems. 356 Pre-service Issues -- Address or prefix uniqueness problems in this 357 category are called pre-service issues. Conceptually, they relate to 358 the fact that before a generated address or prefix is assigned and 359 used, it should be verified that it will not create an address 360 conflict within the specified scope. This is essential in the 361 context of routing, where it is desireable to reduce the risks of 362 loops due to routing table pollution with duplicate addresses. 364 In-Service Issues -- Address or prefix uniqueness problems in this 365 category are called in-service issues. They come from the fact that 366 even if an assigned address or prefix is currently unique within the 367 specified scope, it cannot be ensured that it will indeed remain 368 unique over time. 370 Phenomena such as MANET merging and MANET partitioning may bring the 371 need for checking the uniqueness (within the specified scope) of 372 addresses or prefixes that are already assigned and used. This need 373 may depend on (i) the probability of address conflicts, (ii) the 374 amount of the overhead for checking uniqueness of addresses, and 375 (iii) address/prefix uniqueness requirements from applications. 377 For instance, if (i) is extremely low and (ii) significant, then 378 checking pre-service uniqueness of addresses and prefixes may not be 379 used. If on the other hand (i) is not extremely low, then checking 380 pre-service and in-service uniqueness of addresses or prefixes may be 381 required. In any case, if the application has a hard requirement for 382 address uniqueness assurance, in-service uniqueness checks of 383 addresses and prefixes should always be used, no matter how unlikely 384 is the event of address conflict. 386 4.2.3. Internet Configuration Provider Related Issues 388 Another category of problems concern the management of Internet 389 configuration providers (ICPs). 391 In the case where multiple ICPs are available in the MANET, providing 392 access to multiple address configuration servers, specific problems 393 arise. One problem is the way in which global prefixes are managed 394 within the MANET. If one prefix is used for the whole MANET, 395 partitioning of the MANET may result in invalid routes towards MANET 396 routers, over the Internet. On the other hand, the use of multiple 397 network prefixes guarantees traffic is unambiguously routed from the 398 hosts/routers in the Internet towards the border router responsible 399 for one particular prefix. However, asymmetry in the routers' choice 400 of ingress/egress border router can lead to non-optimal paths 401 followed by inbound/outbound data traffic, or to broken connectivity, 402 if egress filtering is being done. 404 When a router changes its ICP affiliation, some routes may be broken, 405 affecting MANET packet forwarding performance and applications. In a 406 multiple border router / multiple-prefixes MANET, frequent 407 reconfiguration could cause a large amount of control signalling (for 408 instance if [5] is used). 410 5. Solutions Considerations 412 Solutions must achieve their task with (i) low overhead, due to 413 scarse bandwidth, and (ii) low delay/convergence time, due to the 414 dynamicity of the topology. The evaluation of such criteria may 415 depend on the targeted network properties, which include (but are not 416 limited to) node cardinality, node mobility characteristics, etc. 418 Solutions are to be designed to work at the network layer and thus to 419 apply to all link types. However, in situations where link-layer 420 multicast is needed it is possible that on some link types (e.g. 421 NBMA links), alternative mechanisms or protocols specifying operation 422 over a particular link type would be required. 424 Solutions must interact with existing protocols in a way that 425 leverages as much as possible appropriate mechanisms that are 426 deployed. For instance, besides the possible use of the well-known 427 IPv6 multicast addresses defined for neighbor discovery in [3] (e.g. 428 for Duplicate Address Detection), solutions may as well use some 429 addresses defined in [10] for auto-configuration purposes. However, 430 it must be ensured that no modification of existing protocols is to 431 be required outside of MANET scope. 433 Solutions must also take into account the security and trust issues 434 that are specific to ad hoc networking (see Section 6). 436 6. Security Considerations 438 Address configuration in MANET could be prone to security attacks, as 439 in other types of IPv6 networks. Security threats to IPv6 neighbor 440 discovery were discussed in SEND WG and described in [6]: three 441 different trust models are specified, with varying levels of trust 442 among network nodes and routers. Among them, the model by which no 443 trust exists among nodes may be suitable a priori for most ad hoc 444 networks. However, the other two models may be applicable in some 445 cases, for example when a trust relationship exists between an 446 operator and some MANET routers, or between military devices that are 447 in the same unit. Although [6] does not explicitly address MANETs, 448 the trust models it provides for ad hoc networks can be valid also in 449 the context of MANET autoconfiguration. 451 It is worth noting that analysis of [6] is strictly related to 452 Neighbor Discovery, Neighbor Unreachability Detection and Duplicate 453 Address Detection procedures, as defined in [3] and [5]. As 454 explained in the present document, current standard procedures cannot 455 be used as-is in MANET context to achieve autoconfiguration of MANET 456 routers and, therefore, design of new mechanisms can be foreseen. 458 In this case, although security threats and attacks defined in [6] 459 could also apply in presence of new solutions, additional threats and 460 attacks could be possible (e.g., non-cooperation in message 461 forwarding in multi-hop communications). Therefore, the security 462 analysis has to be further extended to include threats, specific to 463 multi-hop networks and related to the particular address 464 configuration solution. 466 General security issues of ad hoc routing protocols' operations are 467 not in the scope of MANET autoconfiguration. 469 7. IANA Considerations 471 This document does currently not specify IANA considerations. 473 8. Informative References 475 [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance 476 Issues and Evaluation Considerations", RFC 2501, January 1999. 478 [2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc 479 Network Architecture", ID draft-ietf-autoconf-manetarch, 480 February 2007. 482 [3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 483 "Neighbor Discovery for IPv6", RFC 4861, September 2007. 485 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 486 Carney, "Dynamic Host Configuration Protocol for IPv6", 487 RFC 3315, July 2003. 489 [5] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address 490 Autoconfiguration", RFC 4862, September 2007. 492 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 493 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 495 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 496 Specific Routes", RFC 4191, 2005. 498 [8] Moy, J., "OSPF version 2", RFC 2328, 1998. 500 [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", 501 RFC 2740, 1999. 503 [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) 504 Allocations for the Mobile Ad hoc Networks (MANET) Working 505 Group", ID draft-ietf-manet-iana, May 2007. 507 [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 508 2001. 510 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 511 Address Autoconfiguration in IPv6", RFC 3041, 2001. 513 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 514 Neighbor Discovery (SEND)", RFC 3971, 2005. 516 [14] Aura, T., "Cryptographically Generated Addresses (CGA)", 517 RFC 3972, 2005. 519 [15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 520 IPv6", RFC 4429, 2006. 522 [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 523 Addresses", RFC 4193, 2005. 525 [17] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix 526 Delegation", ID draft-ietf-nemo-prefix-delegation, August 2007. 528 [18] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", 529 RFC 3633, 2003. 531 Contributors 533 This document is the result of joint efforts, including those of the 534 following contributers, listed in alphabetical order: C. Adjih, C. 535 Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins, 536 A. Petrescu, P. Ruiz, P. Stupar, F. Templin, D. Thaler, K. Weniger. 538 Authors' Addresses 540 Emmanuel Baccelli 541 INRIA 543 Phone: +33 1 69 33 55 11 544 Email: Emmanuel.Baccelli@inria.fr 546 Kenichi Mase 547 Niigata University 549 Phone: +81 25 262 7446 550 Email: Mase@ie.niigata-u.ac.jp 552 Simone Ruffino 553 Telecom Italia 555 Phone: +39 011 228 7566 556 Email: Simone.Ruffino@telecomitalia.it 558 Shubhranshu Singh 559 Samsung 561 Phone: +82 31 280 9569 562 Email: Shubranshu@gmail.com 564 Full Copyright Statement 566 Copyright (C) The IETF Trust (2007). 568 This document is subject to the rights, licenses and restrictions 569 contained in BCP 78, and except as set forth therein, the authors 570 retain all their rights. 572 This document and the information contained herein are provided on an 573 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 574 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 575 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 576 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 577 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 578 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 580 Intellectual Property 582 The IETF takes no position regarding the validity or scope of any 583 Intellectual Property Rights or other rights that might be claimed to 584 pertain to the implementation or use of the technology described in 585 this document or the extent to which any license under such rights 586 might or might not be available; nor does it represent that it has 587 made any independent effort to identify any such rights. Information 588 on the procedures with respect to rights in RFC documents can be 589 found in BCP 78 and BCP 79. 591 Copies of IPR disclosures made to the IETF Secretariat and any 592 assurances of licenses to be made available, or the result of an 593 attempt made to obtain a general license or permission for the use of 594 such proprietary rights by implementers or users of this 595 specification can be obtained from the IETF on-line IPR repository at 596 http://www.ietf.org/ipr. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at 602 ietf-ipr@ietf.org. 604 Acknowledgment 606 Funding for the RFC Editor function is provided by the IETF 607 Administrative Support Activity (IASA).