idnits 2.17.1 draft-templin-autoconf-dhcp-05.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 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 625. 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 7, 2007) is 6282 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 433, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 438, 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) ** Obsolete normative reference: RFC 4214 (Obsoleted by RFC 5214) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-03 Summary: 7 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 11, 2007 S. Yi 6 Boeing Phantom Works 7 February 7, 2007 9 MANET Autoconfiguration 10 draft-templin-autoconf-dhcp-05.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 11, 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 links and may or may not connect to other networks. Routers 45 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 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 interface configured over an 67 imaginary shared link for the MANET. The imaginary shared link 68 provides the conceptual model of a fully-connected shared link to 69 which all MRs attach (i.e., a "virtual ethernet") that is identified 70 by the set of MBRs in the MANET. An MR (and its downstream-attached 71 links) is a "site" unto itself, and a MANET is therefore a "site-of- 72 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 an underlying link within the 111 MANET. 113 virtual ethernet 114 an imaginary shared link that connects all MRs in a MANET. A MR's 115 interface to the virtual ethernet is configured over the 116 underlying MANET interface(s) and has both "raw" and "cooked" 117 access methods. Packets sent using the raw access method are 118 transmitted on the underlying MANET interface without further 119 encapsulation and may require multiple Layer 3 hops to traverse 120 the MANET, i.e., the raw access method sees the MANET as a 121 multilink site. Packets sent using the cooked access method are 122 encapsulated in an outer IP header such that all MRs appear to be 123 single-hop neighbors at Layer 3, i.e., the cooked access method 124 sees the MANET as a unified link. 126 MANET Router (MR) 127 a node that participates in a routing protocol over its MANET 128 interface(s) and forwards packets on behalf of its downstream- 129 attached nodes and other MRs. Conceptually, an MR comprises a 130 router entity and a host entity connected via a virtual point-to- 131 point interface configured over the MANET's virtual ethernet. An 132 MR (and its downstream-attached links) is a "site" unto itself, 133 and a MANET is therefore a "site-of-sites". For the purpose of 134 this specification, an MR's host entity configures a DHCP client 135 and its router entity configures a DHCP relay. 137 MANET Border Router (MBR) 138 an MR that connects the MANET to other networks. For the purpose 139 of this specification, MBRs are assumed to configure a DHCP relay 140 and/or a DHCP server. 142 MANET Local Address (MLA) 143 a Layer-3 unicast address/prefix configured by an MR that is used 144 for intra-MANET communications, i.e., routable only within the 145 scope of the MANET. For IPv6, Unique Local Addresses (ULAs) 146 [RFC4193][I-D.jelger-autoconf-mla] provide a natural MLA 147 mechanism. 149 Extended Router Advertisement/Solicitation (ERA/ERS) 150 an IP Router Advertisement/Solicitation (RA/RS) message [RFC1256] 151 [RFC2461] associated with the MANET's virtual ethernet and 152 transmitted according to one of the two virtual ethernet access 153 methods (both methods are considered as functional equivalents): 155 In the "raw" access method, ERA/ERS messages are transmitted 156 unencapsulated over the underlying MANET link as for ordinary 157 RA/RS, except with an MLA source address and with destination 158 address set to an MLA or a site-scoped multicast address. 160 In the "cooked" access method, ERA/ERS messages are constructed by 161 encapsulating ordinary RA/RS in an outer IP header then 162 transmitted over the underlying MANET link, e.g., as specified for 163 ISATAP [RFC4214]. 165 3. MANET Autoconfiguration 167 The following sections specify autoconfiguration mechanisms and 168 operational practices that allow MRs to participate in the routing 169 protocol and obtain addresses/prefixes for Intra-MANET and global 170 Internet communications. 172 3.1. MANET Router (MR) Operation 174 Each MR configures MLAs on each of its MANET interfaces. For IPv6, 175 MLAs are generated using Unique Local Addresses 176 [RFC4193][I-D.jelger-autoconf-mla] with interface identifiers that 177 are either managed for uniqueness (e.g., per [RFC4291], Appendix A) 178 or self-generated using a suitable random interface identifier 179 generation mechanism that is compatible with EUI-64 format (e.g., 180 Cryptographically Generated Addresses (CGAs) [RFC3972]). For IPv4, 181 MLAs are generated using a corresponding unique local address 182 configuration mechanism. 184 Each MR next engages in the routing protocol and discovers the set of 185 MBRs that identify the virtual ethernet that connects all MRs. The 186 set of MBRs is discovered the same as for the ISATAP Potential Router 187 List (PRL) initialization procedure (see: [RFC4214], Sections 8.3.2 188 and 9); if the set of MBRs is NULL, an alternate identifier (e.g., 189 the IEEE MAC address of an ordinary MR) can instead be used to 190 provide a name for the MANET. MRs can then confirm reachability of 191 MBRs (and, in the case of IPv6, discover prefixes associated with the 192 MANET's virtual ethernet) by sending ERSs and/or receiving ERAs, via 193 an out-of-band service discovery protocol, via information conveyed 194 in the routing protocol itself, or through some other means 195 associated with the particular link technology. 197 After a MR discovers MBRs, the DHCP client associated with its host 198 function forwards a DHCP DISCOVER (DHCPv4) or Solicit (DHCPv6) 199 request to the DHCP relay associated with its router function to 200 request global IP address and/or prefix delegations (see also: 201 Section 3.6). The relay function then forwards the request to one or 202 more MBRs, to other known DHCP servers, or to a site-scoped "All- 203 DHCP-Servers" multicast address. 205 For DHCPv4, the MR's relay function writes an MLA from the MANET 206 interface over which it will forward the request in the 'giaddr' 207 field and also includes the MLA in a DHCPv4 MLA option (see: 208 Section 3.4). If necessary to identify the MR's downstream-attached 209 host function, the relay also includes a link selection sub-option 210 [RFC3527] with an address from the prefix associated with the virtual 211 ethernet (if a prefix is available). 213 For DHCPv6, the MR's relay function writes an MLA from the outgoing 214 MANET interface in the "peer-address" field and also writes an 215 address from the prefix associated with the virtual ethernet in the 216 "link-address" field (if a prefix is available). The MR can also use 217 DHCP prefix delegation [RFC3633] to obtain prefixes for further sub- 218 delegation to nodes on its downstream-attached links. 220 The DHCP request will elicit a DHCP reply from a server with IP 221 address/prefix delegations. When addresses are delegated, the MR 222 assigns the resulting addresses to the virtual point-to-point 223 interface that connects its host and router functions, i.e., the 224 addresses are *not* assigned on the upstream MANET interface. When 225 prefixes are delegated, the MR can assign and/or further sub-delegate 226 the prefixes to its downstream-attached links, including physical 227 links and virtual links of the MR itself. If the MANET uses a 228 proactive routing protocol, the MR can advertise the delegated 229 addresses/prefixes into the routing protocol during the duration of 230 the delegation lifetimes. 232 The DHCP server ensures unique IP address/prefix delegations. By 233 assigning global IP addresses/prefixes only on downstream-attached 234 interfaces (and not the upstream MANET interface) there is no 235 requirement for the MR to perform Duplicate Address Detection (DAD) 236 for global addresses on its MANET interfaces. See Appendix A for 237 further DAD considerations. 239 After the MR configures global IP addresses/prefixes, it can send IP 240 packets with global IP source addresses to off-MANET destinations 241 either by using any available MBRs as egress gateways or by selecting 242 specific MBRs on a per-packet basis. For MANETs in which MBRs can 243 advertise a 'default' route that propagates throughout the routing 244 protocol, the MR can send IP packets without encapsulation using the 245 virtual ethernet "raw" access method at the expense of extra TTL 246 (IPv4) or Hop Limit (IPv6) decrementation. For MANETs in which the 247 routing protocol cannot propagate a default route, or when the MR 248 wishes to select as specific MBR as the egress gateway, the MR can 249 either: a) send packets using the virtual ethernet "cooked" access 250 method with an MLA for an MBR as the destination address in the outer 251 header (i.e., tunnels the packets to the MBR), or b) send packets 252 using the "raw" access method with an IPv4 source routing header 253 (likewise IPv6 routing header) to ensure that the packets will be 254 forwarded through a specific MBR. 256 3.2. MANET Border Router Operation 258 MBRs send periodic and/or solicited ERAs which (for IPv6) can include 259 prefixes associated with the MANET's virtual ethernet. Such prefixes 260 should be advertised as not to be used for on-link determination or 261 StateLess Address AutoConfiguration (SLAAC) [RFC2462] by setting the 262 'A', 'L' bits in Prefix Information Options to 0. (See: Appendix B 263 for further considerations on using SLAAC for MANET 264 Autoconfiguration.) 266 MBRs act as BOOTP/DHCP relays and/or servers for a MR's DHCP 267 requests/replies. For DHCPv4, when a MBR acting as a relay forwards 268 a DHCP request that includes an MLA option, it writes its own address 269 in the 'giaddr' field, i.e., it overwrites the value that was written 270 into 'giaddr' by the MR's relay function. 272 3.3. DHCP Server Extensions 274 No MANET autoconfiguration-specific extensions are required for 275 DHCPv6 servers. 277 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 278 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 279 copies the option into the corresponding DHCPv4 reply message(s). 281 3.4. MLA Encapsulation 283 For DHCPv6, the MLA is encoded directly in the "peer-address" field 284 of DHCPv6 requests/replies. 286 For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is 287 required to encode an MLA for DHCP transactions that will traverse a 288 MBR, i.e., so that the MBR has a MANET-relevant address to direct 289 DHCPv4 replies to the correct MR, which may be multiple Layer-3 hops 290 away. The format of the DHCPv4 MLA option is given below: 292 Code Len Ether Type MLA 293 +-----+-----+-----+-----+-----+-----+--- 294 | TBD | n | type | a1 | a2 | ... 295 +-----+-----+-----+-----+-----+-----+--- 297 Code 298 a one-octet field that identifies the option type (see: 299 Section 5). 301 Len 302 a one-octet field that encodes the remaining option length. 304 Ether Type 305 a type value from the IANA "ethernet-numbers" registry. 307 MLA 308 a variable-length MANET Local Address (MLA). 310 3.5. MANET Flooding 312 When multicast service discovery is required, Layer-3 MANETs that 313 implement this specification must use a MANET flooding mechanism 314 (e.g., Simplified Multicast Forwarding (SMF) [I-D.ietf-manet-smf]) so 315 that site-scoped multicast messages can be propagated across multiple 316 Layer-3 hops. 318 3.6. Self-Generated Addresses 320 MR's can self-generate an address (e.g., an IPv6 Cryptographically- 321 Generated Address (CGA) [RFC3972]) then propose the address to the 322 DHCP server. If the DHCP server determines that the self-generated 323 address is unique, it will delegate the address for the MR's use. 325 4. Operation with Multiple MBRs 327 For a set of MANETs and MBRs that attach to the same backbone 328 network, MRs can retain their global IP address/prefix delegations as 329 they move if the backbone network participates with the MBRs and MRs 330 in a localized mobility management scheme, e.g., see: 331 [I-D.templin-autoconf-netlmm-dhcp]. 333 For a set of MBRs that attach to different backbone networks and/or 334 serve different global IP prefixes from within the same network, MRs 335 must configure new global IP addresses/prefixes as they change 336 between different MBRs unless inter-MBR tunnels and routing protocol 337 exchanges are supported, e.g., see: 338 [I-D.templin-autoconf-netlmm-dhcp], Appendix A. 340 Global mobility management mechanisms for MRs that configure new 341 global IP addresses/prefixes as they move between different MBRs are 342 beyond the scope of this document. 344 5. IANA Considerations 346 A new DHCP option code is requested for the DHCP MLA Option in the 347 IANA "bootp-dhcp-parameters" registry. 349 6. Security Considerations 351 Threats relating to MANET routing protocols also apply to this 352 document. 354 7. Related Work 356 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 357 program. The virtual ethernet model was proposed by Quang Nguyen 358 under the guidance of Dr. Lixia Zhang. Various IETF AUTOCONF working 359 group proposals have suggested similar mechanisms. 361 8. Acknowledgements 363 The Naval Research Lab (NRL) Information Technology Division uses 364 DHCP in their MANET research testbeds. Many of the ideas on this 365 document originated from IETF AUTOCONF working group discussions on 366 various aspects of autoconfiguration for MANETs. 368 Thomas Henderson provided valuable input; Jinmei Tatuya reminded that 369 address duplication can occur when multiple mechanisms (i.e. manual 370 configuration, stateless and DHCP) are used within the same network. 372 9. References 373 9.1. Normative References 375 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 376 September 1981. 378 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 379 converting network protocol addresses to 48.bit Ethernet 380 address for transmission on Ethernet hardware", STD 37, 381 RFC 826, November 1982. 383 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 384 September 1985. 386 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 387 September 1991. 389 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 390 RFC 2131, March 1997. 392 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 393 Extensions", RFC 2132, March 1997. 395 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 396 (IPv6) Specification", RFC 2460, December 1998. 398 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 399 Discovery for IP Version 6 (IPv6)", RFC 2461, 400 December 1998. 402 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 403 Autoconfiguration", RFC 2462, December 1998. 405 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 406 and M. Carney, "Dynamic Host Configuration Protocol for 407 IPv6 (DHCPv6)", RFC 3315, July 2003. 409 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 410 Host Configuration Protocol (DHCP) version 6", RFC 3633, 411 December 2003. 413 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 414 "Intra-Site Automatic Tunnel Addressing Protocol 415 (ISATAP)", RFC 4214, October 2005. 417 9.2. Informative References 419 [I-D.ietf-manet-smf] 420 Macker, J., "Simplified Multicast Forwarding for MANET", 421 draft-ietf-manet-smf-03 (work in progress), October 2006. 423 [I-D.jelger-autoconf-mla] 424 Jelger, C., "MANET Local IPv6 Addresses", 425 draft-jelger-autoconf-mla-01 (work in progress), 426 October 2006. 428 [I-D.templin-autoconf-netlmm-dhcp] 429 Templin, F., "Network Localized Mobility Management using 430 DHCP", draft-templin-autoconf-netlmm-dhcp-04 (work in 431 progress), October 2006. 433 [I-D.thaler-autoconf-multisubnet-manets] 434 Thaler, D., "Multi-Subnet MANETs", 435 draft-thaler-autoconf-multisubnet-manets-00 (work in 436 progress), February 2006. 438 [I-D.thaler-intarea-multilink-subnet-issues] 439 Thaler, D., "Issues With Protocols Proposing Multilink 440 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 441 (work in progress), March 2006. 443 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 444 (MANET): Routing Protocol Performance Issues and 445 Evaluation Considerations", RFC 2501, January 1999. 447 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 448 "Link Selection sub-option for the Relay Agent Information 449 Option for DHCPv4", RFC 3527, April 2003. 451 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 452 RFC 3972, March 2005. 454 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 455 Addresses", RFC 4193, October 2005. 457 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 458 Architecture", RFC 4291, February 2006. 460 Appendix A. IPv6 Neighbor Discovery (ND) and Duplicate Address 461 Detection (DAD) 463 In terms of ND, [RFC2461][RFC4291] require that a node configure a 464 link-local address on each of its IPv6-enabled interfaces, and the 465 primary requirement for link-locals seems to be for the purpose of 466 uniquely identifying routers on the link. But, it is for further 467 study as to whether MRs should send RAs on MANET interfaces at all, 468 since the MANET is a peering point between distinct sites and not the 469 link of a single site with a clear set of serving routers and 470 dependent end-hosts. In particular, since MANET interfaces configure 471 MLAs which already provide a statistically-unique identifier, the use 472 link-local addresses may only be practical for environments in which 473 link-local address assignments are specifically managed for 474 uniqueness, e.g., ISATAP link-local addresses [RFC4214]. 476 In terms of DAD, pre-service DAD for an address assigned on a MANET 477 link (such as specified in [RFC2462]) would require either flooding 478 the entire MANET or somehow discovering a targeted region of the 479 MANET on which a node that configures a duplicate address resides and 480 sending a directed DAD message toward that region. But, the control 481 message overhead for such a MANET-wide DAD would be substantial and 482 prone to false-negatives due to packet loss. Note also that link- 483 local addresses using Cryptographically Generated Addresses (CGAs) 484 [RFC3972] provide random generation only in 59 bits of the lower 64 485 bits of the IPv6 address, while MLAs using CGAs also use 40/56 bits 486 of random generation in the upper 64 bits of the IPv6 address. Since 487 such MLAs are highly unlikely to collide, pre-service DAD can be 488 avoided and a passive in-service DAD (e.g., one that monitors routing 489 protocol messages) can be used instead. 491 Statistical properties can assure uniqueness for the MLAs assigned on 492 a MR's MANET interfaces, and careful operational practices can assure 493 uniqueness for the global addresses/prefixes assigned on a MR's 494 downstream-attached links (since the DHCP server assures unique 495 assignments). However, a passive in-service DAD mechanism should 496 still be used to detect duplicates that were assigned via other 497 means, e.g., manual configuration. 499 Appendix B. IPv6 StateLess Address AutoConfiguration (SLAAC) 501 For IPv6, the use of StateLess Address AutoConfiguration (SLAAC) 502 [RFC2462] could be indicated by prefix information options in ERAs 503 with the 'A' bit set to 1. MRs that receive such ERAs could then 504 self-generate an address from the prefix and assign it to the virtual 505 point-to-point interface configured over the MANET's virtual 506 ethernet, then use a passive in-service DAD approach to detect 507 duplicates within the MANET. But, if the MANET partitions, DAD might 508 not be able to monitor the routing exchanges occurring in other 509 partitions and address duplication could result. 511 Appendix C. Change Log 513 Changed from -04 to -05: 515 o introduced conceptual "virtual ethernet" model. 517 o support "raw" and "cooked" modes as equivalent access methods on 518 the virutal ethernet. 520 Changed from -03 to -04: 522 o introduced conceptual "imaginary shared link" as a representation 523 for a MANET. 525 o discussion of autonomous system and site abstractions for MANETs 527 o discussion of autoconfiguration of CGAs 529 o new appendix on IPv6 StateLess Address AutoConfiguration 531 Changes from -02 to -03: 533 o updated terminology based on RFC2461 "asymmetric reachability" 534 link type; IETF67 MANET Autoconf wg discussions. 536 o added new appendix on IPv6 Neighbor Discovery and Duplicate 537 Address Detection 539 o relaxed DHCP server deployment considerations allow DHCP servers 540 within the MANET itself 542 Changes from -01 to -02: 544 o minor updates for consistency with recent developments 546 Changes from -00 to -01: 548 o new text on DHCPv6 prefix delegation and multilink subnet 549 considerations. 551 o various editorial changes 553 Authors' Addresses 555 Fred L. Templin 556 Boeing Phantom Works 557 P.O. Box 3707 MC 7L-49 558 Seattle, WA 98124 559 USA 561 Email: fred.l.templin@boeing.com 563 Steven W. Russert 564 Boeing Phantom Works 565 P.O. Box 3707 MC 7L-49 566 Seattle, WA 98124 567 USA 569 Email: steven.w.russert@boeing.com 571 Ian D. Chakeres 572 Boeing Phantom Works 573 P.O. Box 3707 MC 7L-49 574 Seattle, WA 98124 575 USA 577 Email: ian.chakeres@gmail.com 579 Seung Yi 580 Boeing Phantom Works 581 P.O. Box 3707 MC 7L-49 582 Seattle, WA 98124 583 USA 585 Email: seung.yi@boeing.com 587 Full Copyright Statement 589 Copyright (C) The IETF Trust (2007). 591 This document is subject to the rights, licenses and restrictions 592 contained in BCP 78, and except as set forth therein, the authors 593 retain all their rights. 595 This document and the information contained herein are provided on an 596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 598 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 599 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 600 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 603 Intellectual Property 605 The IETF takes no position regarding the validity or scope of any 606 Intellectual Property Rights or other rights that might be claimed to 607 pertain to the implementation or use of the technology described in 608 this document or the extent to which any license under such rights 609 might or might not be available; nor does it represent that it has 610 made any independent effort to identify any such rights. Information 611 on the procedures with respect to rights in RFC documents can be 612 found in BCP 78 and BCP 79. 614 Copies of IPR disclosures made to the IETF Secretariat and any 615 assurances of licenses to be made available, or the result of an 616 attempt made to obtain a general license or permission for the use of 617 such proprietary rights by implementers or users of this 618 specification can be obtained from the IETF on-line IPR repository at 619 http://www.ietf.org/ipr. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights that may cover technology that may be required to implement 624 this standard. Please address the information to the IETF at 625 ietf-ipr@ietf.org. 627 Acknowledgment 629 Funding for the RFC Editor function is provided by the IETF 630 Administrative Support Activity (IASA).