idnits 2.17.1 draft-templin-autoconf-dhcp-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 606. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1, 2007) is 6293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.thaler-autoconf-multisubnet-manets' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 425, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-03 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft S. Russert 4 Intended status: Informational I. Chakeres 5 Expires: August 5, 2007 S. Yi 6 Boeing Phantom Works 7 February 1, 2007 9 MANET Autoconfiguration 10 draft-templin-autoconf-dhcp-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 5, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 Mobile Ad-hoc Networks (MANETs) consist of routers operating over 44 wireless channels and may or may not connect to other networks. 45 Routers in MANETs that connect to the Internet must have a way to 46 automatically provision globally routable and unique IP addresses/ 47 prefixes. This document specifies mechanisms for MANET 48 autoconfiguration. Both IPv4 and IPv6 are discussed. 50 1. Introduction 52 Mobile Ad-hoc Networks (MANETs) comprise links with asymmetric 53 reachability link characteristics (see: [RFC2461], Section 2.2) that 54 connect MANET Routers (MRs). MRs participate in a routing protocol 55 such that packets can be forwarded via multiple hops across the MANET 56 if necessary. MANETs may connect to other networks via MANET Border 57 Routers (MBRs), and MRs may be multiple IP hops away from their 58 nearest MBR in some scenarios. A MANET may be as large as an 59 Autonomous System (AS) or as small as an individual site, and may 60 contain other MANETs and/or fixed networks. MRs with hosts on 61 downstream-attached links that require global Internet access must 62 have a means to automatically provision global IP addresses/prefixes 63 and/or other configuration information. 65 Conceptually, MRs comprise a router entity and a host entity that are 66 connected via a virtual point-to-point VLAN (e.g., a loopback 67 interface) configured over an imaginary shared link for the MANET. 68 The imaginary shared link provides a conceptual model of a fully- 69 connected shared link to which all MRs attach, and has an associated 70 identifier (e.g., a prefix associated with the imaginary shared link) 71 that "names" the MANET. An MR (and its downstream-attached links) is 72 a "site" unto itself, and a MANET is therefore a "site-of-sites". 74 MANETs that comprise homogeneous link types can configure the routing 75 protocol to operate as a sub-IP layer mechanism such that IP (i.e., 76 Layer-3) sees the MANET as an ordinary shared link the same as for a 77 (bridged) campus LAN. In that case, a single IP hop is sufficient to 78 traverse the MANET. 80 MANETs that comprise heterogeneous link types must configure the 81 routing protocol to operate as a Layer-3 mechanism such that routing 82 protocol operation is based on MANET-Local Addresses (MLAs) or other 83 Layer-3 identifiers that are unique within the MANET to avoid issues 84 associated with bridging media types with dissimilar Layer-2 address 85 formats and maximum transmission units (MTUs). In that case, 86 multiple IP hops may be necessary to traverse the MANET. 88 This document specifies mechanisms and operational practices for 89 MANET autoconfiguration. Operation using standard BOOTP/DHCP 90 [RFC0951][RFC2131][RFC3315][RFC3633] and neighbor discovery 91 [RFC0826][RFC1256][RFC2461][RFC2462] mechanisms is assumed unless 92 otherwise specified. Both IPv4 [RFC0791] and IPv6 [RFC2460] are 93 discussed. 95 2. Terminology 97 The terminology in the normative references apply; the following 98 terms are defined within the scope of this document: 100 Mobile Ad-hoc Network (MANET) 101 a connected network region that comprises MANET routers that 102 maintain a routing structure among themselves in a relatively 103 arbitrary fashion over links with asymmetric reachability 104 characteristics (see: [RFC2461], Section 2.2). MANETs may be 105 large as an Autonomous System (AS) or as small as an individual 106 site. Further information on the characteristics of MANETs can be 107 found in [RFC2501]. 109 MANET Interface 110 a MANET router's attachment to a link within the MANET. 112 MANET Router (MR) 113 a node that participates in a routing protocol over its MANET 114 interface(s) and forwards packets on behalf of its downstream- 115 attached nodes and other MRs. Conceptually, an MR comprises a 116 router entity and a host entity connected via a virtual point-to- 117 point VLAN (e.g., a loopback interface) configured over an 118 imaginary shared link for the MANET. An MR (and its downstream- 119 attached links) is a "site" unto itself, and a MANET is therefore 120 a "site-of-sites". For the purpose of this specification, an MR's 121 host entity configures a DHCP client and its router entity 122 configures a DHCP relay. 124 MANET Border Router (MBR) 125 an MR that connects the MANET to other networks. For the purpose 126 of this specification, MBRs are assumed to configure a DHCP relay 127 and/or a DHCP server. 129 MANET Local Address (MLA) 130 a Layer-3 unicast address/prefix configured by an MR that is used 131 for intra-MANET communications, i.e., routable only within the 132 scope of the MANET. For IPv6, Unique Local Addresses (ULAs) 133 [RFC4193][I-D.jelger-autoconf-mla] provide a natural MLA 134 mechanism. 136 Extended Router Advertisement/Solicitation (ERA/ERS) 137 an IP Router Advertisement/Solicitation (RA/RS) message [RFC1256] 138 [RFC2461] with an MLA source address and with destination address 139 set to an MLA or a site-scoped multicast address that spans the 140 MANET via a broadcast/multicast flooding mechanism (see: 141 Section 3.5). Unlike ordinary RA/RS messages, ERA/ERS messages 142 use a non-link-local source address and may travel multiple IP 143 hops. 145 3. MANET Autoconfiguration 147 The following sections specify autoconfiguration mechanisms and 148 operational practices that allow MRs to participate in the routing 149 protocol and obtain addresses/prefixes for Intra-MANET and global 150 Internet communications. 152 3.1. MANET Router (MR) Operation 154 Each MR configures MLAs on each of its MANET interfaces. For IPv6, 155 MLAs are generated using Unique Local Addresses 156 [RFC4193][I-D.jelger-autoconf-mla] with interface identifiers that 157 are either managed for uniqueness (e.g., per [RFC4291], Appendix A) 158 or self-generated using a suitable random interface identifier 159 generation mechanism that is compatible with EUI-64 format (e.g., 160 Cryptographically Generated Addresses (CGAs) [RFC3972]). For IPv4, 161 MLAs are generated using a corresponding unique local address 162 configuration mechanism. 164 Each MR next engages in the routing protocol and discovers an 165 identifier for the MANET. The identifier could be an IP prefix, a 166 DNS Fully-Qualified Domain Name (FQDN), an IEEE MAC address, etc. but 167 in any case provides a name for the MANET. MRs can discover this 168 identifier by receiving ERAs that contain a prefix associated with 169 the imaginary shared link (see: Section 3.2), via an out-of-band 170 service discovery protocol, via information conveyed in the routing 171 protocol itself, or through some other means associated with the 172 particular link technology. 174 After a MR discovers an identifier for the MANET, the DHCP client 175 associated with its host function sends a DHCP DISCOVER (DHCPv4) or 176 Solicit (DHCPv6) request across the virtual interface to the DHCP 177 relay associated with its router function to request global IP 178 address and/or prefix delegations (see also: Section 3.6). The relay 179 function then forwards the request to or more MBRs, to other known 180 DHCP servers, or to a site-scoped "All-DHCP-Servers" multicast 181 address. 183 For DHCPv4, the MR's relay function writes an MLA from the outgoing 184 MANET interface (i.e., the relay's upstream-attached interface) in 185 the 'giaddr' field and also includes the MLA in a DHCPv4 MLA option 186 (see: Section 3.4). If necessary to identify the downstream-attached 187 virtual interface, the relay also includes a link selection sub- 188 option [RFC3527] with an address from the prefix associated with the 189 MANET's imaginary shared link (if such a prefix is available). 191 For DHCPv6, the MR's relay function writes an MLA from the outgoing 192 MANET interface in the "peer-address" field and also writes an 193 address from the prefix associated with the MANET's imaginary shared 194 link in the "link-address" field (if such a prefix is available). 195 The MR can also use DHCP prefix delegation [RFC3633] to obtain 196 prefixes for further sub-delegation to nodes on its downstream- 197 attached links. 199 The DHCP request will elicit a DHCP reply from a server with IP 200 address/prefix delegations. When addresses are delegated, the MR 201 assigns the resulting addresses to the virtual interface that 202 connects its host and router functions, i.e., the addresses are *not* 203 assigned on the upstream MANET interface. When prefixes are 204 delegated, the MR can assign and/or further sub-delegate the prefixes 205 to its downstream-attached links, including physical links and 206 virtual links of the MR itself. If the MANET uses a proactive 207 routing protocol, the MR advertises the delegated addresses/prefixes 208 into the routing protocol during the duration of the delegation 209 lifetimes. 211 The DHCP server ensures unique IP address/prefix delegations. By 212 assigning global IP addresses/prefixes only on downstream-attached 213 interfaces (and not the upstream MANET interface) there is no 214 requirement for the MR to perform Duplicate Address Detection (DAD) 215 for global addresses on the MANET interface. See Appendix A for 216 further DAD considerations. 218 After the MR configures global IP addresses/prefixes, it can send IP 219 packets with global IP source addresses to off-MANET destinations 220 using any of the MBRs as egress gateways. For MANETs in which MBRs 221 can advertise a 'default' route that propagates throughout the 222 routing protocol, the MR can send the IP packets without 223 encapsulation at the expense of extra TTL (IPv4) or Hop Limit (IPv6) 224 decrementation. For MANETs in which the routing protocol cannot 225 propagate a default route, the MR either: a) encapsulates IP packets 226 with an MLA for an MBR as the destination address in the outer header 227 (i.e., tunnels the packets to the MBR), or b) inserts an IPv4 source 228 routing header (likewise IPv6 routing header) to ensure that the 229 packets will be forwarded through an MBR. 231 3.2. MANET Border Router Operation 233 MBRs can send periodic and/or solicited ERAs associated with the 234 imaginary shared link for the MANET on their attached MANET links. 235 For IPv6, MBRs can advertise prefixes in ERAs that MRs can consider 236 as an identifier for the MANET. Such prefixes should be advertised 237 as not to be used for on-link determination or StateLess Address 238 AutoConfiguration (SLAAC) [RFC2462] by setting the 'A', 'L' bits in 239 Prefix Information Options to 0. (See: Appendix B for further 240 considerations on using SLAAC for MANET Autoconfiguration.) 242 MBRs act as BOOTP/DHCP relays and/or servers for a MR's DHCP 243 requests/replies. For DHCPv4, when a MBR acting as a relay forwards 244 a DHCP request that includes an MLA option, it writes its own address 245 in the 'giaddr' field, i.e., it overwrites the value that was written 246 into 'giaddr' by the MR's relay function. 248 For MANETs in which MRs cannot proactively advertise delegated 249 addresses/prefixes via the routing protocol, the MBR creates a tunnel 250 for each DHCP reply message it processes pertaining to address/prefix 251 delegation with the tunnel's destination address set to the MLA for 252 the MR encoded in the DHCPv4 MLA option or the DHCPv6 "peer-address" 253 field (see: Section 3.4). The MBR then creates entries in its IP 254 forwarding table that point to the tunnel for each delegated IP 255 address/prefix and relays the reply to the MLA for the MR. 257 For MANETs in which MRs will advertise delegated addresses/prefixes 258 via the routing protocol, tunneling from the MBR is not required 259 since standard IP routing within the MANET will direct packets to the 260 correct MR. 262 3.3. DHCP Server Extensions 264 No MANET autoconfiguration-specific extensions are required for 265 DHCPv6 servers. 267 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 268 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 269 copies the option into the corresponding DHCPv4 reply message(s). 271 3.4. MLA Encapsulation 273 For DHCPv6, the MLA is encoded directly in the "peer-address" field 274 of DHCPv6 requests/replies. 276 For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is 277 required to encode an MLA for DHCP transactions that will traverse a 278 MBR, i.e., so that the MBR has a MANET-relevant address to direct 279 DHCPv4 replies to the correct MR, which may be multiple Layer-3 hops 280 away. The format of the DHCPv4 MLA option is given below: 282 Code Len Ether Type MLA 283 +-----+-----+-----+-----+-----+-----+--- 284 | TBD | n | type | a1 | a2 | ... 285 +-----+-----+-----+-----+-----+-----+--- 286 Code 287 a one-octet field that identifies the option type (see: 288 Section 5). 290 Len 291 a one-octet field that encodes the remaining option length. 293 Ether Type 294 a type value from the IANA "ethernet-numbers" registry. 296 MLA 297 a variable-length MANET Local Address (MLA). 299 3.5. MANET Flooding 301 When multicast service discovery is required, Layer-3 MANETs that 302 implement this specification must use a MANET flooding mechanism 303 (e.g., Simplified Multicast Forwarding (SMF) [I-D.ietf-manet-smf]) so 304 that site-scoped multicast messages can be propagated across multiple 305 Layer-3 hops. 307 3.6. Self-Generated Addresses 309 MR's can self-generate an address (e.g., an IPv6 Cryptographically- 310 Generated Address (CGA) [RFC3972]) then propose the address to the 311 DHCP server. If the DHCP server determines that the self-generated 312 address is unique and can be assigned to MR's virtual interface 313 configured over the imaginary shared link, it will delegate the 314 address for the MR's use. 316 4. Operation with Multiple MBRs 318 For a set of MANETs and MBRs that attach to the same backbone 319 network, MRs can retain their global IP address/prefix delegations as 320 they move if the backbone network participates with the MBRs and MRs 321 in a localized mobility management scheme, e.g., see: 322 [I-D.templin-autoconf-netlmm-dhcp]. 324 For a set of MBRs that attach to different backbone networks and/or 325 serve different global IP prefixes from within the same network, MRs 326 must configure new global IP addresses/prefixes as they change 327 between different MBRs unless inter-MBR tunnels and routing protocol 328 exchanges are supported, e.g., see: 329 [I-D.templin-autoconf-netlmm-dhcp], Appendix A. 331 Global mobility management mechanisms for MRs that configure new 332 global IP addresses/prefixes as they move between different MBRs are 333 beyond the scope of this document. 335 5. IANA Considerations 337 A new DHCP option code is requested for the DHCP MLA Option in the 338 IANA "bootp-dhcp-parameters" registry. 340 6. Security Considerations 342 Threats relating to MANET routing protocols also apply to this 343 document. 345 7. Related Work 347 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 348 program. Various IETF AUTOCONF working group proposals have 349 suggested similar mechanisms for address configuration. 351 8. Acknowledgements 353 The Naval Research Lab (NRL) Information Technology Division uses 354 DHCP in their MANET research testbeds. Many of the ideas on this 355 document originated from IETF AUTOCONF working group discussions on 356 various aspects of autoconfiguration for MANETs. 358 Thomas Henderson provided valuable input; Jinmei Tatuya reminded that 359 address duplication can occur when multiple mechanisms (i.e. manual 360 configuration, stateless and DHCP) are used within the same network. 362 9. References 364 9.1. Normative References 366 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 367 September 1981. 369 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 370 converting network protocol addresses to 48.bit Ethernet 371 address for transmission on Ethernet hardware", STD 37, 372 RFC 826, November 1982. 374 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 375 September 1985. 377 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 378 September 1991. 380 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 381 RFC 2131, March 1997. 383 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 384 Extensions", RFC 2132, March 1997. 386 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 387 (IPv6) Specification", RFC 2460, December 1998. 389 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 390 Discovery for IP Version 6 (IPv6)", RFC 2461, 391 December 1998. 393 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 394 Autoconfiguration", RFC 2462, December 1998. 396 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 397 and M. Carney, "Dynamic Host Configuration Protocol for 398 IPv6 (DHCPv6)", RFC 3315, July 2003. 400 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 401 Host Configuration Protocol (DHCP) version 6", RFC 3633, 402 December 2003. 404 9.2. Informative References 406 [I-D.ietf-manet-smf] 407 Macker, J., "Simplified Multicast Forwarding for MANET", 408 draft-ietf-manet-smf-03 (work in progress), October 2006. 410 [I-D.jelger-autoconf-mla] 411 Jelger, C., "MANET Local IPv6 Addresses", 412 draft-jelger-autoconf-mla-01 (work in progress), 413 October 2006. 415 [I-D.templin-autoconf-netlmm-dhcp] 416 Templin, F., "Network Localized Mobility Management using 417 DHCP", draft-templin-autoconf-netlmm-dhcp-04 (work in 418 progress), October 2006. 420 [I-D.thaler-autoconf-multisubnet-manets] 421 Thaler, D., "Multi-Subnet MANETs", 422 draft-thaler-autoconf-multisubnet-manets-00 (work in 423 progress), February 2006. 425 [I-D.thaler-intarea-multilink-subnet-issues] 426 Thaler, D., "Issues With Protocols Proposing Multilink 427 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 428 (work in progress), March 2006. 430 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 431 (MANET): Routing Protocol Performance Issues and 432 Evaluation Considerations", RFC 2501, January 1999. 434 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 435 "Link Selection sub-option for the Relay Agent Information 436 Option for DHCPv4", RFC 3527, April 2003. 438 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 439 RFC 3972, March 2005. 441 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 442 Addresses", RFC 4193, October 2005. 444 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 4291, February 2006. 447 Appendix A. IPv6 Neighbor Discovery and Duplicate Address Detection 449 IPv6 Neighbor Discovery (ND) and Duplicate Address Detection (DAD) 450 for MANETs is for further study. 452 In terms of ND, [RFC2461][RFC4291] require that a node configure a 453 link-local address on each of its IPv6-enabled interfaces, and the 454 primary requirement for link-locals seems to be for the purpose of 455 uniquely identifying routers on the link. But, it is for further 456 study as to whether MRs should send RAs on MANET links at all, since 457 the MANET is a peering point between distinct sites and not the link 458 of a single site with a clear set of serving routers and dependent 459 end-hosts. In particular, since MANET interfaces configure MLAs 460 which already provide a statistically-unique identifier, link-local 461 addresses may be of little/no value on MANET interfaces and hence 462 strict enforcement of link-local address uniqueness may not be 463 necessary 465 In terms of DAD, pre-service DAD on a MANET link (such as specified 466 in [RFC2462]) would require either flooding the entire MANET or 467 somehow discovering a targeted region of the MANET on which a node 468 that configures a duplicate address resides and sending a directed 469 DAD message toward that region. But, the control message overhead 470 for such a MANET-wide DAD would be substantial and prone to false- 471 negatives due to packet loss. Note also that link-local addresses 472 using Cryptographically Generated Addresses (CGAs) [RFC3972] provide 473 random generation only in 59 bits of the lower 64 bits of the IPv6 474 address, while MLAs using CGAs also use 40/56 bits of random 475 generation in the upper 64 bits of the IPv6 address. Since such MLAs 476 are highly unlikely to collide, pre-service DAD can be avoided and a 477 passive in-service DAD (e.g., one that monitors routing protocol 478 messages) can be used instead. 480 Statistical properties can assure uniqueness for the MLAs assigned on 481 a MR's MANET interfaces, and careful operational practices can assure 482 uniqueness for the global addresses/prefixes assigned on a MR's 483 downstream-attached links (since the DHCP server assures unique 484 assignments). However, a passive in-service DAD mechanism should 485 still be used to detect duplicates that were assigned via other 486 means, e.g., manual configuration. 488 Appendix B. IPv6 StateLess Address AutoConfiguration (SLAAC) 490 The use of StateLess Address AutoConfiguration (SLAAC) [RFC2462] 491 could be indicated by prefix information options in ERAs with the 'A' 492 bit set to 1. MRs that receive such ERAs could then self-generate an 493 address from the prefix and assign it to the virtual interface 494 configured over the imaginary shared link for the MANET, then use a 495 passive in-service DAD approach to detect duplicates within the 496 MANET. But, if the MANET partitions, DAD might not be able to 497 monitor the routing exchanges occurring in other partitions and 498 address duplication could result. 500 Appendix C. Change Log 502 Changed from -03 to -04: 504 o introduced conceptual "imaginary shared link" as a representation 505 for a MANET. 507 o discussion of autonomous system and site abstractions for MANETs 509 o discussion of autoconfiguration of CGAs 511 o new appendix on IPv6 StateLess Address AutoConfiguration 513 Changes from -02 to -03: 515 o updated terminology based on RFC2461 "asymmetric reachability" 516 link type; IETF67 MANET Autoconf wg discussions. 518 o added new appendix on IPv6 Neighbor Discovery and Duplicate 519 Address Detection 521 o relaxed DHCP server deployment considerations allow DHCP servers 522 within the MANET itself 524 Changes from -01 to -02: 526 o minor updates for consistency with recent developments 528 Changes from -00 to -01: 530 o new text on DHCPv6 prefix delegation and multilink subnet 531 considerations. 533 o various editorial changes 535 Authors' Addresses 537 Fred L. Templin 538 Boeing Phantom Works 539 P.O. Box 3707 MC 7L-49 540 Seattle, WA 98124 541 USA 543 Email: fred.l.templin@boeing.com 545 Steven W. Russert 546 Boeing Phantom Works 547 P.O. Box 3707 MC 7L-49 548 Seattle, WA 98124 549 USA 551 Email: steven.w.russert@boeing.com 553 Ian D. Chakeres 554 Boeing Phantom Works 555 P.O. Box 3707 MC 7L-49 556 Seattle, WA 98124 557 USA 559 Email: ian.chakeres@gmail.com 560 Seung Yi 561 Boeing Phantom Works 562 P.O. Box 3707 MC 7L-49 563 Seattle, WA 98124 564 USA 566 Email: seung.yi@boeing.com 568 Full Copyright Statement 570 Copyright (C) The IETF Trust (2007). 572 This document is subject to the rights, licenses and restrictions 573 contained in BCP 78, and except as set forth therein, the authors 574 retain all their rights. 576 This document and the information contained herein are provided on an 577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 579 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 580 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 581 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 584 Intellectual Property 586 The IETF takes no position regarding the validity or scope of any 587 Intellectual Property Rights or other rights that might be claimed to 588 pertain to the implementation or use of the technology described in 589 this document or the extent to which any license under such rights 590 might or might not be available; nor does it represent that it has 591 made any independent effort to identify any such rights. Information 592 on the procedures with respect to rights in RFC documents can be 593 found in BCP 78 and BCP 79. 595 Copies of IPR disclosures made to the IETF Secretariat and any 596 assurances of licenses to be made available, or the result of an 597 attempt made to obtain a general license or permission for the use of 598 such proprietary rights by implementers or users of this 599 specification can be obtained from the IETF on-line IPR repository at 600 http://www.ietf.org/ipr. 602 The IETF invites any interested party to bring to its attention any 603 copyrights, patents or patent applications, or other proprietary 604 rights that may cover technology that may be required to implement 605 this standard. Please address the information to the IETF at 606 ietf-ipr@ietf.org. 608 Acknowledgment 610 Funding for the RFC Editor function is provided by the IETF 611 Administrative Support Activity (IASA).