idnits 2.17.1 draft-templin-autoconf-dhcp-11.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 803. 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 4, 2008) is 5925 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3056' is mentioned on line 329, but not defined == Unused Reference: 'RFC2132' is defined on line 512, 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 (-02) exists of draft-fuller-240space-00 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-06 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-06 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 S. Yi 5 Expires: August 7, 2008 Boeing Phantom Works 6 February 4, 2008 8 MANET Autoconfiguration 9 draft-templin-autoconf-dhcp-11.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Mobile Ad-hoc Networks (MANETs) connect routers on links with 43 asymmetric reachability characteristics, and may also connect to 44 other networks including the Internet. Routers in MANETs must have a 45 way to automatically provision IP addresses/prefixes and other 46 information. This document specifies mechanisms for MANET 47 autoconfiguration; both IPv4 and IPv6 are discussed. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. MANET Autoconfiguration . . . . . . . . . . . . . . . . . . . 6 54 3.1. MANET Router (MNR) Operation . . . . . . . . . . . . . . . 6 55 3.1.1. MANET Local Address (MLA) Configuration . . . . . . . 6 56 3.1.2. MNBR List Discovery . . . . . . . . . . . . . . . . . 7 57 3.1.3. VET Interface Configuration . . . . . . . . . . . . . 7 58 3.1.4. Reachability Confirmation . . . . . . . . . . . . . . 7 59 3.1.5. MNBR-Aggregated Address/Prefix Autoconfiguration . . . 8 60 3.1.6. Nomadic IPv6 Prefixes . . . . . . . . . . . . . . . . 9 61 3.1.7. Self-Generated IPv6 Interface Identifiers . . . . . . 9 62 3.1.8. Forwarding Packets to Off-MANET Destinations . . . . . 10 63 3.2. MANET Border Router (MNBR) Operation . . . . . . . . . . . 10 64 3.3. MANET Flooding . . . . . . . . . . . . . . . . . . . . . . 10 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Appendix A. Duplicate Address Detection (DAD) Considerations . . 14 74 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 18 78 1. Introduction 80 Mobile Ad-hoc Networks (MANETs) connect MANET Routers (MNRs) on links 81 with asymmetric reachability characteristics (see: [RFC2461], Section 82 2.2). MNRs may participate in a routing protocol over MANET 83 interfaces to discover routes across the MANET using multiple Layer-2 84 or Layer-3 forwarding hops if necessary. MANETs may also connect to 85 other networks including the Internet via MANET Border Routers 86 (MNBRs), and MNRs may be multiple hops away from their nearest MNBR 87 in some scenarios. A MANET may be as simple as a small collection of 88 MNRs (and their attached networks); a MANET may also contain other 89 MANETs and/or be a subnetwork of a larger MANET. 91 MANETs that comprise homogeneous link types can configure the routing 92 protocol to operate as a sub-IP layer mechanism such that IP sees the 93 MANET as an ordinary shared link the same as for a (bridged) campus 94 LAN. In that case, a single IP hop is sufficient to traverse the 95 MANET without IP layer encapsulation. 97 MANETs that comprise heterogeneous link types must instead (or, in 98 addition) provide a routing service that operates as an IP layer 99 mechanism to accommodate media types with dissimilar Layer-2 address 100 formats and maximum transmission units (MTUs). In that case, 101 multiple IP hops may be necessary to traverse the MANET such that 102 specialized autoconfiguration procedures are necessary to avoid 103 multilink subnet issues [RFC4903]. In particular, we describe herein 104 the use of a virtualized link that spans the MANET, to avoid the 105 multilink subnet issues that arise when MANET interfaces are used 106 directly by applications. 108 Conceptually, a MNR embodies a router entity that connects its 109 attached networks to MANETs and/or other networks including the 110 Internet (see: Figure 1). The router entity also connects to an 111 imaginary Virtual Ethernet (VET) that sees the MANET as a fully- 112 connected shared link. For each distinct MANET to which they 113 connect, MNRs discover a list of MNBRs that determines the MANET's 114 identity. An MNR (and its attached networks) is a "site" unto 115 itself, therefore a MANET is a "site-of-sites". 117 This document specifies mechanisms and operational practices for 118 MANET autoconfiguration with multilink subnet avoidance. Operation 119 using standard DHCP 120 [RFC2131][I-D.ietf-dhc-subnet-alloc][RFC3315][RFC3633] and neighbor 121 discovery [RFC1256][RFC2461][RFC2462] mechanisms is assumed unless 122 otherwise specified. Both IPv4 [RFC0791] and IPv6 [RFC2460] are 123 discussed. 125 2. Terminology 127 The terminology in [I-D.ietf-autoconf-manetarch] and the normative 128 references apply. The following terms are defined within the scope 129 of this document: 131 subnetwork 132 the same as defined in [RFC3819]. 134 egress/ingress interface 135 the same as defined in ([RFC3753], Section 3). Note that in some 136 MANET scenarios, an interface may dynamically switch from being an 137 ingress interface to being an egress interface, and vice-versa. 139 Mobile Ad-hoc Network (MANET) 140 a connected network region of MANET routers that maintain a 141 routing structure among themselves over asymmetric reachability 142 links (see: [RFC2461], Section 2.2). A MANET may be as simple as 143 a small collection of MNRs (and their attached networks); a MANET 144 may also contain other MANETs and/or be a subnetwork of a larger 145 MANET. A MANET router (and its attached networks) is a site unto 146 itself, and a MANET is therefore a site-of-sites. 148 Further information on the characteristics of MANETs can be found 149 in [RFC2501]. 151 MANET Router (MNR) 152 a mobile router that forwards packets on behalf of both other MNRs 153 over its MANET interfaces and networks attached on its ingress 154 interfaces. A MNR can also forward packets to other networks 155 either directly via its egress interfaces or indirectly via an 156 MNBR. For the purpose of this specification, an MNR comprises a 157 router entity, one or more host entities, and its attached 158 ingress/egress/MANET interfaces (see: Figure 1). 160 MANET Border Router (MNBR) 161 an MNR that connects a MANET to other networks, including the 162 Internet. MNBRs that configure egress interfaces can delegate 163 addresses/prefixes to other MNRs. 165 MANET Interface 166 a MANET Router's attachment to a link in a MANET. A MANET 167 interface is "neutral" in its orientation, i.e., it is inherently 168 neither egress nor ingress. In particular, a packet may need to 169 traverse several MANET interfaces before it is forwarded via 170 either an egress or ingress interface. 172 MANET Local Address (MLA) 173 an address configured by an MNR that is unique within the MANET; 174 it is used as an identifier for operating the routing protocol and 175 may also be assigned to a MANET interface as a locator for packet 176 forwarding within the scope of the MANET. 178 Virtual Ethernet (VET) 179 an imaginary shared link that connects all MNRs in a MANET. 181 VET interface 182 a MNR's attachment to a VET. Each VET interface is configured 183 over a set of underlying MANET interface(s) belonging to the same 184 MANET. The VET interface encapsulates each IP packet in an outer 185 IP header then forwards it over an underlying MANET interface such 186 that the TTL/HOP Limit in the inner IP header is not decremented 187 as the packet traverses the MANET, i.e., the VET interface views 188 the MANET as a unified shared link and presents an automatic 189 tunneling abstraction. 191 The following figure depicts the architectural model for a MANET 192 router: 193 Egress Interfaces (to Internet) 194 x x x 195 | | | 196 +------------------------+---+--------+----------+ 197 | Internal hosts | | | | M 198 | and routers | | .... | | A 199 | ,-. | +---+---+--------+---+ | N 200 | (H1 )---+ | /| | E 201 | | `-' | | I /*+------+--< T 202 | . | +---+ | | n|**| | 203 | . +--|R1 |---+-----+ t|**| | I 204 | . | +---+ | | Router V e|**+------+--< n 205 | | ,-. | | E r|**| . | t 206 | (H2 )---+ | Entity T f|**| . | e 207 | `-' | . | a|**| . | r 208 | . | c|**| . | f 209 | ,-. . | e \*+------+--< a 210 | (Hn )---------+ \| | c 211 | `-' +---+---+--------+---+ | e 212 | Ingress Interfaces | | .... | | s 213 | (to internal networks) | | | | 214 +------------------------+---+--------+----------+ 215 | | | 216 x x x 217 Ingress Interfaces (to attached networks) 219 Figure 1: MANET Router 221 3. MANET Autoconfiguration 223 3.1. MANET Router (MNR) Operation 225 MNRs configure egress interfaces that connect "upstream" toward fixed 226 Internet infrastructure, ingress interfaces that connect "downstream" 227 toward attached networks, and both MANET and VET interfaces that are 228 "neutral" in the sense that the packets they forward may need to 229 traverse several MANET hops before they are forwarded via either an 230 egress or ingress interface. MNRs also engage in the routing 231 protocol over their MANET interfaces, and obtain addresses/prefixes 232 and other autoconfiguration information using the mechanisms and 233 operational practices specified in the following sections: 235 3.1.1. MANET Local Address (MLA) Configuration 237 Upon joining a MANET, each MNR first configures MANET Local Addresses 238 (MLAs) that it will use for operating the routing protocol and/or 239 assignment to MANET interfaces. 241 IPv4 MLAs can be manually configured, administratively assigned, 242 autoconfigured using DHCP or self-generated using a suitable pseudo- 243 random IPv4 unique local address autoconfiguration mechanism. Such a 244 mechanism could be considered as a site-scoped equivalent to IPv4 245 link-local addresses [RFC3927], and could delegate addresses out of a 246 suitably large IPv4 prefix space such as the soon-to-be-reclassified 247 240/4 space [I-D.fuller-240space]. 249 IPv6 MLAs can be manually configured, administratively assigned, 250 autoconfigured using DHCP, autoconfigured using IPv6 StateLess 251 Address AutoConfiguration (SLAAC) [RFC2462], or self-generated using 252 IPv6 Unique Local Addresses (ULAs) 253 [RFC4193][I-D.ietf-ipv6-ula-central]. IPv6 MLAs include interface 254 identifiers that are either managed for uniqueness (e.g., see: 255 [RFC4291], Appendix A) or self-generated using a suitable pseudo- 256 random interface identifier generation mechanism (e.g., 257 Cryptographically Generated Addresses (CGAs) [RFC3972], IPv6 privacy 258 addresses [I-D.ietf-ipv6-privacy-addrs-v2], etc.). 260 When there is no manually/administratively assigned MLA, the choice 261 of autoconfiguring an MLA using DHCP or self-generating one using 262 some other mechanism is up to the MNR and may depend on the 263 particular MANET deployment scenario. DHCP-generated MLAs have the 264 benefit of a "managed" avoidance of address collisions, while self- 265 generated MLAs must be monitored for collisions with other nodes that 266 might assign a duplicate. 268 Since a MNR initially has no non-link-local addresses, DHCP 269 configuration of MLAs may require relay support from other MNRs that 270 have already been autoconfigured within the MANET. This means that 271 MNRs with assigned MLAs should be prepared to relay another MNR's 272 DHCP requests, e.g. to a site-scoped multicast address, to a unicast 273 address(es), etc. 275 3.1.2. MNBR List Discovery 277 After configuring MLAs, the MNR next engages in any routing 278 protocol(s) over its MANET interfaces and discovers the list of MNBRs 279 (if any) on the MANET. The list of MNBRs can be discovered through 280 routing protocol information, or through an alternate discovery 281 mechanism, e.g., per [RFC4214], Section 8.3.2. 283 Identifying names/values for one or more MNBRs, and/or a set of 284 address prefixes that they aggregate, serve as an identifier for the 285 MANET. 287 3.1.3. VET Interface Configuration 289 The MNR configures a VET interface over a set of underlying MANET 290 interfaces that represents a unified shared link for the MANET. The 291 VET interface autoconfigures a link-local address, e.g., an ISATAP 292 link-local address ([RFC4214], Section 6.2) derived from an IPv4 MLA 293 assigned to an underlying MANET interface, an IPv4 link local 294 address[RFC3927], etc.. IP packets sent via the VET interface are 295 encapsulated in an outer IP header then submitted to the IP 296 forwarding engine for transmission on an underlying MANET interface. 298 Considerations for setting the VET interface Maximum Transmission 299 Unit (MTU) are discussed in [RFC4213]. 301 3.1.4. Reachability Confirmation 303 After the MNR configures a VET interface, it can confirm reachability 304 of MNRs/MNBRs and (in the case of IPv6) discover prefixes associated 305 with the VET. The MNR can confirm reachability by sending/receiving 306 ordinary ND messages and/or issuing DHCP requests over the VET 307 interface. It can also confirm reachability through information 308 conveyed in the routing protocol itself, or through some other means 309 associated with the particular MANET subnetwork technology. 311 Out of scope for this document are specific mitigations for the loss 312 of MNRs/MNBRs due to e.g., network partitions, node failures, etc. 313 Mechanisms such as routing protocol information, bidirectional 314 forward detection, detection of network attachment, neighbor 315 discovery hints of forward progress, short beaconing/polling 316 intervals, etc. are candidates for further study. 318 3.1.5. MNBR-Aggregated Address/Prefix Autoconfiguration 320 After the MNR discovers MNBRs, it can acquire MNBR-aggregated 321 addresses/prefixes using either IPv6 Stateless Address 322 AutoConfiguration (SLAAC) or DHCP. These addresses/prefixes are 323 delegated by specific MNBRs, and may be: 325 o global-scope and provider aggregated 327 o global-scope and provider-independent 329 o global-scope and 6to4 [RFC3056] 331 o unique-local scope and centrally administrated 333 o unique-local scope and locally assigned 335 o other non-link-local scope 337 The following subsections discuss IPv6 SLAAC and DHCP address/prefix 338 autoconfiguration considerations: 340 3.1.5.1. IPv6 SLAAC 342 For IPv6, MNRs can autoconfigure addresses on the VET interface based 343 on Prefix Information Options in received RAs, i.e., the same as for 344 ordinary IPv6 links (see: Section 3.2). 346 3.1.5.2. DHCP Address/Prefix Autoconfiguration 348 When DHCP is used, a DHCP client associated with the MNR's host 349 entity forwards a DHCP DISCOVER (DHCPv4) or Solicit (DHCPv6) request 350 to a DHCP relay associated with its router entity to request IP 351 address/prefix delegations for assignment on ingress interfaces 352 (i.e., the MNR acts as both DHCP client and relay). The relay 353 function then forwards the request to the unicast addresses of one or 354 more MNBRs, to a site-scoped multicast address, or to another known 355 DHCP server within the MANET. 357 For DHCPv6, the MNR's relay function writes an address from the VET 358 interface in the "peer-address" field and also writes an address from 359 the prefix associated with the VET in the "link-address" field (if a 360 prefix is available). The MNR can also (or, instead) use DHCPv6 361 prefix delegation [RFC3633] to obtain addresses/prefixes via MNBRs 362 for assignment and/or further sub-delegation on networks connected on 363 its ingress interfaces. (Note that the MNR can obtain /128 prefixes 364 using DHCP prefix delegation the same as for any IPv6 prefix.) 365 For DHCPv4, the MNR's relay function writes an address from a MANET 366 interface in the 'giaddr' field. If necessary to identify the MNR's 367 ingress interface, the relay also includes a link selection sub- 368 option [RFC3527] with an address from the prefix associated with the 369 VET (if a prefix is available). The MNR can also (or, instead) use 370 DHCPv4 prefix delegation [I-D.ietf-dhc-subnet-alloc] to obtain 371 addresses/prefixes via MNBRs for further assignment and/or further 372 sub-delegation on networks connected on its ingress interfaces. 373 (Note that the MNR can obtain /32 prefixes using DHCP prefix 374 delegation the same as for any IPv4 prefix.) 376 The DHCP request will elicit a DHCP reply from a server with IP 377 address/prefix delegations that are aggregated by one or more MNBRs. 378 When addresses are delegated, the MNR assigns the resulting addresses 379 to an ingress interface, i.e., it does not assign the addresses on 380 the VET interface or an underlying MANET interface. When prefixes 381 are delegated, the MNR can assign and/or further sub-delegate them to 382 networks connected on its ingress interfaces. 384 The DHCP server ensures IP address/prefix delegations that are unique 385 within the MANET. By assigning these IP addresses/prefixes only on 386 ingress interfaces there is no requirement for the MNR to perform 387 Duplicate Address Detection (DAD) for them over its MANET and VET 388 interfaces (but see Appendix A for further DAD considerations). 390 3.1.6. Nomadic IPv6 Prefixes 392 Independent of any MNBR-aggregated addresses/prefixes (see: 393 Section 3.1.5), MNRs can self-generate IPv6 Unique Local Address 394 (ULA) prefixes [RFC4193][I-D.ietf-ipv6-ula-central] and sub-delegate 395 them on networks connected on their ingress interfaces. Similarly, a 396 MNR can carry IPv6 prefixes (e.g., taken from a home network) as it 397 travels between MANETs as long it coordinates in some fashion with a 398 prefix aggregation authority. 400 Such nomadic-use IPv6 prefixes are not aggregated, redistributed or 401 advertised by MNBRs and can therefore travel with the MNR as it moves 402 to new MANETs and/or configures peering arrangements with MNRs in 403 other MANETs. Generation of nomadic IPv6 prefixes can therefore 404 occur independently of any other MNR autoconfiguration 405 considerations. 407 3.1.7. Self-Generated IPv6 Interface Identifiers 409 MNR's can self-generate IPv6 interface identifiers such as specified 410 for CGAs [RFC3972], IPv6 privacy address 411 [I-D.ietf-ipv6-privacy-addrs-v2], etc. 413 For MNBR-aggregated address/prefix autoconfiguration (see: 414 Section 3.1.5), the MNR can propose a self-generated address to the 415 DHCPv6 server which will delegate the address to the MNR for 416 assignment on an ingress interface if the proposed address is unique. 418 3.1.8. Forwarding Packets to Off-MANET Destinations 420 MNRs use the VET interface to forward IP packets to off-MANET 421 destinations. 423 For IPv6, MNRs can discover default router preferences and more- 424 specific routes per [RFC4191] by sending unicast Router Solicitations 425 over the VET interface to elicit Router Advertisements from MNBRs. 426 MNRs/MNBRs should therefore include default router preferences and/or 427 more-specific routes in their Router Advertisements. 429 Once default routers and/or more-specific routes are discovered, the 430 MNR can forward the packets via the VET interface with an MLA for an 431 MNR/MNBR as the destination in the outer IP header. When multiple 432 MNR/MNBRs are available as next-hop routers on the VET interface, the 433 MNR can use default router preferences, traffic engineering 434 configurations, etc. to select the best exit router. 436 3.2. MANET Border Router (MNBR) Operation 438 MNBRs connect networks on ingress interfaces to the MANET, and may 439 also connect the MANET to other networks that lead toward the 440 Internet over egress interfaces. This latter category of MNBRs can 441 also delegate addresses/prefixes to other MNRs on the MANET. 443 MNBRs send ordinary ND messages such as IPv6 RA messages with Route 444 Information Options [RFC4191] to other MNRs over the VET interface. 445 MNBRs that delegate addresses/prefixes for the MANET can also include 446 link specific parameters, default router lifetimes, default router 447 preferences, and Prefix Information Options for SLAAC on the VET 448 interface in the IPv6 RA messages they send. 450 For DHCPv6, MNBRs that delegate addresses/prefixes act as DHCP relays 451 and/or servers for DHCP requests/replies. (For DHCPv4, MNBRs may 452 only act as DHCP servers, since the MLA address in the 'giaddr' field 453 is not routable outside the scope of the MANET.) 455 3.3. MANET Flooding 457 MANETs that operate routing as an IP layer service should deploy a 458 multicast flooding service (e.g., Simplified Multicast Forwarding 459 (SMF) [I-D.ietf-manet-smf]) so that site-scoped multicast messages 460 will be propagated across the MANET. 462 4. IANA Considerations 464 A site-scoped IPv4 multicast group for: "All-MANET-Routers", or: 465 "All-Site-Routers" is requested, e.g., to support MANET flooding for 466 site-scoped service discovery (see: Section 3.3). 468 5. Security Considerations 470 Threats relating to MANET routing protocols also apply to this 471 document. 473 6. Related Work 475 The authors acknowledge the work done by Brian Carpenter and Cyndi 476 Jung in [RFC2529] that introduced the concept of intra-site automatic 477 tunneling. This concept was later called: "Virtual Ethernet" and 478 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 480 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 481 program. The Naval Research Lab (NRL) Information Technology 482 Division uses DHCP in their MANET research testbeds. Various IETF 483 AUTOCONF working group proposals have suggested similar mechanisms. 485 7. Acknowledgements 487 The following individuals gave direct and/or indirect input that was 488 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 489 Bound, Thomas Clausen, Eric Fleischman, Bob Hinden, Joe Macker, 490 Thomas Narten, Alexandru Petrescu, Jinmei Tatuya, Dave Thaler, and 491 others in the IETF AUTOCONF and MANET working groups. Many others 492 have provided guidance over the course of many years. 494 8. Contributors 496 Thomas Henderson (thomas.r.henderson@boeing.com) contributed to this 497 document. Ian Chakeres (ian.chakeres@gmail.com) contributed to 498 earlier versions of the document. 500 9. References 501 9.1. Normative References 503 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 504 September 1981. 506 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 507 September 1991. 509 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 510 RFC 2131, March 1997. 512 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 513 Extensions", RFC 2132, March 1997. 515 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 516 (IPv6) Specification", RFC 2460, December 1998. 518 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 519 Discovery for IP Version 6 (IPv6)", RFC 2461, 520 December 1998. 522 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 523 Autoconfiguration", RFC 2462, December 1998. 525 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 526 and M. Carney, "Dynamic Host Configuration Protocol for 527 IPv6 (DHCPv6)", RFC 3315, July 2003. 529 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 530 Host Configuration Protocol (DHCP) version 6", RFC 3633, 531 December 2003. 533 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 534 More-Specific Routes", RFC 4191, November 2005. 536 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 537 for IPv6 Hosts and Routers", RFC 4213, October 2005. 539 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 540 "Intra-Site Automatic Tunnel Addressing Protocol 541 (ISATAP)", RFC 4214, October 2005. 543 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 544 Architecture", RFC 4291, February 2006. 546 9.2. Informative References 548 [I-D.fuller-240space] 549 Fuller, V., "Reclassifying 240/4 as usable unicast address 550 space", draft-fuller-240space-00 (work in progress), 551 September 2007. 553 [I-D.ietf-autoconf-manetarch] 554 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 555 Network Architecture", draft-ietf-autoconf-manetarch-07 556 (work in progress), November 2007. 558 [I-D.ietf-dhc-subnet-alloc] 559 Johnson, R., "Subnet Allocation Option", 560 draft-ietf-dhc-subnet-alloc-06 (work in progress), 561 November 2007. 563 [I-D.ietf-ipv6-privacy-addrs-v2] 564 Narten, T., "Privacy Extensions for Stateless Address 565 Autoconfiguration in IPv6", 566 draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress), 567 October 2006. 569 [I-D.ietf-ipv6-ula-central] 570 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 571 Addresses", draft-ietf-ipv6-ula-central-02 (work in 572 progress), June 2007. 574 [I-D.ietf-manet-smf] 575 Macker, J. and S. Team, "Simplified Multicast Forwarding 576 for MANET", draft-ietf-manet-smf-06 (work in progress), 577 November 2007. 579 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 580 (MANET): Routing Protocol Performance Issues and 581 Evaluation Considerations", RFC 2501, January 1999. 583 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 584 Domains without Explicit Tunnels", RFC 2529, March 1999. 586 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 587 "Link Selection sub-option for the Relay Agent Information 588 Option for DHCPv4", RFC 3527, April 2003. 590 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 591 RFC 3753, June 2004. 593 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 594 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 595 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 596 RFC 3819, July 2004. 598 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 599 Configuration of IPv4 Link-Local Addresses", RFC 3927, 600 May 2005. 602 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 603 RFC 3972, March 2005. 605 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 606 Addresses", RFC 4193, October 2005. 608 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 609 June 2007. 611 Appendix A. Duplicate Address Detection (DAD) Considerations 613 Pre-service DAD for an MLA assigned on a MANET interface (such as 614 specified in [RFC2462]) would require either flooding the entire 615 MANET or somehow discovering a link in the MANET on which a node that 616 configures a duplicate address is attached and performing a localized 617 DAD exchange on that link. But, the control message overhead for 618 such a MANET-wide DAD would be substantial and prone to false- 619 negatives due to packet loss and node mobility. An alternative to 620 pre-service DAD is to autoconfigure pseudo-random MLAs on MANET 621 interfaces and employ a passive in-service DAD (e.g., one that 622 monitors routing protocol messages for duplicate assignments). 624 Pseudo-random IPv6 MLAs can be generated with mechanisms such as 625 CGAs, IPv6 privacy addresses, etc. with very small probability of 626 collision (but, IPv6 ULAs also provide an additional 40 pseudo-random 627 bits in the prefix). Pseudo-random IPv4 MLAs can be generated 628 through random assignment from a suitably large IPv4 prefix space, 629 e.g., the soon-to-be-reclassified 240/4 space [I-D.fuller-240space]. 631 Statistical properties for pseudo-random address self-generation can 632 assure uniqueness for the MLAs assigned on a MNR's MANET interfaces, 633 and consistent operational practices can assure uniqueness for MNBR- 634 aggregated addresses/prefixes. However, a passive in-service DAD 635 mechanism should still be used to detect duplicates that were 636 assigned through other means, e.g., manual configuration. 638 Appendix B. Change Log 640 (Note to RFC editor - this section to be removed before publication 641 as an RFC.) 643 Changes from -10 to 11: 645 o removed the transparent/opaque VET portal abstractions. 647 o removed routing header as an option for MANET exit router 648 selection. 650 o included IPv6 SLAAC as an endorsed address configuration mechanism 651 for the VET interface. 653 Changes from -08 to -09: 655 o Introduced the term "VET". 657 o Changed address delegation language to speak of "MNBR-aggregated" 658 instead of global/local. 660 o Updated figures 1-3. 662 o Explained why a MANET interface is "neutral". 664 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 665 DHCPv4 servers; not relays. 667 Changes from -07 to -08: 669 o changed terms "unenhanced" and "enhanced" to "transparent" and 670 "opaque". 672 o revised MANET Router diagram. 674 o introduced RFC3753 terminology for Mobile Router; ingress/egress 675 interface. 677 o changed abbreviations to "MNR" and "MNBR". 679 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 681 o rearranged Section 3.1. 683 o various minor text cleanups 685 Changes from -06 to -07: 687 o added MANET Router diagram. 689 o added new references 691 o various minor text cleanups 693 Changed from -05 to -06: 695 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 697 o minor changes to preserve generality 699 Changed from -04 to -05: 701 o introduced conceptual "virtual ethernet" model. 703 o support "raw" and "cooked" modes as equivalent access methods on 704 the virutal ethernet. 706 Changed from -03 to -04: 708 o introduced conceptual "imaginary shared link" as a representation 709 for a MANET. 711 o discussion of autonomous system and site abstractions for MANETs 713 o discussion of autoconfiguration of CGAs 715 o new appendix on IPv6 StateLess Address AutoConfiguration 717 Changes from -02 to -03: 719 o updated terminology based on RFC2461 "asymmetric reachability" 720 link type; IETF67 MANET Autoconf wg discussions. 722 o added new appendix on IPv6 Neighbor Discovery and Duplicate 723 Address Detection 725 o relaxed DHCP server deployment considerations allow DHCP servers 726 within the MANET itself 728 Changes from -01 to -02: 730 o minor updates for consistency with recent developments 732 Changes from -00 to -01: 734 o new text on DHCPv6 prefix delegation and multilink subnet 735 considerations. 737 o various editorial changes 739 Authors' Addresses 741 Fred L. Templin 742 Boeing Phantom Works 743 P.O. Box 3707 MC 7L-49 744 Seattle, WA 98124 745 USA 747 Email: fltemplin@acm.org 749 Steven W. Russert 750 Boeing Phantom Works 751 P.O. Box 3707 MC 7L-49 752 Seattle, WA 98124 753 USA 755 Email: steven.w.russert@boeing.com 757 Seung Yi 758 Boeing Phantom Works 759 P.O. Box 3707 MC 7L-49 760 Seattle, WA 98124 761 USA 763 Email: seung.yi@boeing.com 765 Full Copyright Statement 767 Copyright (C) The IETF Trust (2008). 769 This document is subject to the rights, licenses and restrictions 770 contained in BCP 78, and except as set forth therein, the authors 771 retain all their rights. 773 This document and the information contained herein are provided on an 774 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 775 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 776 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 777 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 778 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 779 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 781 Intellectual Property 783 The IETF takes no position regarding the validity or scope of any 784 Intellectual Property Rights or other rights that might be claimed to 785 pertain to the implementation or use of the technology described in 786 this document or the extent to which any license under such rights 787 might or might not be available; nor does it represent that it has 788 made any independent effort to identify any such rights. Information 789 on the procedures with respect to rights in RFC documents can be 790 found in BCP 78 and BCP 79. 792 Copies of IPR disclosures made to the IETF Secretariat and any 793 assurances of licenses to be made available, or the result of an 794 attempt made to obtain a general license or permission for the use of 795 such proprietary rights by implementers or users of this 796 specification can be obtained from the IETF on-line IPR repository at 797 http://www.ietf.org/ipr. 799 The IETF invites any interested party to bring to its attention any 800 copyrights, patents or patent applications, or other proprietary 801 rights that may cover technology that may be required to implement 802 this standard. Please address the information to the IETF at 803 ietf-ipr@ietf.org. 805 Acknowledgment 807 Funding for the RFC Editor function is provided by the IETF 808 Administrative Support Activity (IASA).