idnits 2.17.1 draft-templin-autoconf-dhcp-07.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 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 818. 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 (March 2, 2007) is 6263 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 603, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 608, 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 (-07) exists of draft-ietf-autoconf-manetarch-00 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-03 Summary: 7 errors (**), 0 flaws (~~), 5 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: September 3, 2007 S. Yi 6 Boeing Phantom Works 7 March 2, 2007 9 MANET Autoconfiguration 10 draft-templin-autoconf-dhcp-07.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 September 3, 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 multihop wireless links, and may or may not connect to other networks 45 and/or the Internet. Routers in MANETs must have a way to 46 automatically provision local and global-use IP addresses/prefixes. 47 This document specifies mechanisms for MANET autoconfiguration. Both 48 IPv4 and IPv6 are discussed. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. MANET Autoconfiguration . . . . . . . . . . . . . . . . . . . 6 55 3.1. MANET Router (MR) Operation . . . . . . . . . . . . . . . 6 56 3.2. MANET Border Router Operation . . . . . . . . . . . . . . 9 57 3.3. DHCP Server Extensions . . . . . . . . . . . . . . . . . . 9 58 3.4. MLA Encapsulation . . . . . . . . . . . . . . . . . . . . 10 59 3.5. MANET Flooding . . . . . . . . . . . . . . . . . . . . . . 10 60 3.6. Self-Generated Addresses . . . . . . . . . . . . . . . . . 10 61 3.7. Changes to the Neighbor Discovery Model . . . . . . . . . 11 62 4. Operation with Multiple MBRs . . . . . . . . . . . . . . . . . 11 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Appendix A. IPv6 Neighbor Discovery (ND) and Duplicate 71 Address Detection (DAD) . . . . . . . . . . . . . . . 14 72 Appendix B. IPv6 StateLess Address AutoConfiguration (SLAAC) . . 15 73 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Intellectual Property and Copyright Statements . . . . . . . . . . 18 77 1. Introduction 79 Mobile Ad-hoc Networks (MANETs) comprise links with asymmetric 80 reachability characteristics (see: [RFC2461], Section 2.2) that 81 connect MANET Routers (MRs). MRs participate in a routing protocol 82 to discover routes for forwarding packets across the MANET using 83 multiple Layer-2 and/or Layer-3 hops if necessary. MANETs may 84 connect to other networks via MANET Border Routers (MBRs), and MRs 85 may be multiple IP hops away from their nearest MBR in some 86 scenarios. A MANET may be as large as an Autonomous System (AS) or 87 as small as an individual site. A MANET may contain other MANETs 88 and/or fixed networks, and a MANET may also be a subnetwork of a 89 larger site. MRs that connect downstream-attached links must have a 90 means to automatically provision local and global-use IP addresses/ 91 prefixes and/or other configuration information. 93 Conceptually, MRs embody a router entity linked to one or more host 94 entities by virtual point-to-point interfaces (see: Figure 1). The 95 router entity also connects to an imaginary shared link (i.e., a 96 "virtual ethernet") that connects all MRs in the MANET (see: Figure 2 97 and Figure 3). An "enhanced" view of this virtual ethernet sees the 98 MANET as a fully-connected shared link that connects all MRs, while 99 an "unenhanced" view sees the MANET as a multilink site. For each 100 MANET to which they connect, MRs discover a list of MBRs; this list 101 determines the MANET's identity. An MR (and its downstream-attached 102 links) is a "site" unto itself, and a MANET is therefore a "site-of- 103 sites". 105 MANETs that comprise homogeneous link types can configure the routing 106 protocol to operate as a sub-IP layer mechanism such that IP (i.e., 107 Layer-3) sees the MANET as an ordinary shared link the same as for a 108 (bridged) campus LAN. In that case, a single IP hop is sufficient to 109 traverse the MANET. 111 MANETs that comprise heterogeneous link types must instead (or, in 112 addition) provide a routing service that operates as a Layer-3 113 mechanism based on MANET-local Addresses (MLAs) or other identifiers 114 that are unique within the MANET to avoid issues associated with 115 bridging media types with dissimilar Layer-2 address formats and 116 maximum transmission units (MTUs). In that case, multiple IP hops 117 may be necessary to traverse the MANET. 119 This document specifies mechanisms and operational practices for 120 MANET autoconfiguration. Operation using standard BOOTP/DHCP 121 [RFC0951][RFC2131][RFC3315][RFC3633] and neighbor discovery 122 [RFC0826][RFC1256][RFC2461][RFC2462] mechanisms is assumed unless 123 otherwise specified. Both IPv4 [RFC0791] and IPv6 [RFC2460] are 124 discussed. 126 2. Terminology 128 The terminology in [I-D.ietf-autoconf-manetarch] and the normative 129 references apply; the following terms are defined within the scope of 130 this document: 132 Mobile Ad-hoc Network (MANET) 133 a connected network region that comprises MANET routers that 134 maintain a routing structure among themselves over links with 135 asymmetric reachability characteristics (see: [RFC2461], Section 136 2.2). A MANET may be as large as an Autonomous System (AS) or as 137 small as an individual site, and may also be a subnetwork of a 138 larger site. A MANET router (and its downstream-attached links) 139 is a "site" unto itself, and a MANET is therefore a "site-of- 140 sites". Further information on the characteristics of MANETs can 141 be found in [RFC2501]. 143 MANET Router (MR) 144 a node that participates in a routing protocol over its MANET 145 interface(s) and forwards packets on behalf of both other MRs and 146 nodes on its other attached links. Conceptually, an MR embodies a 147 router entity linked to one or more host entities by virtual 148 point-to-point interfaces, plus any other physical or virtual 149 interfaces connected to other links (see: Figure 1). For the 150 purpose of this specification, an MR's host entity configures a 151 DHCP client and its router entity configures a DHCP relay. 153 MANET Border Router (MBR) 154 an MR that connects the MANET to other networks. For the purpose 155 of this specification, MBRs are assumed to configure a DHCP relay 156 and/or a DHCP server. 158 MANET Local Address (MLA) 159 a Layer-3 unicast address configured by an MR that is unique 160 within the MANET; it is used as an identifier for operating the 161 routing protocol and may also be assigned to a MANET interface as 162 a locator for packet forwarding within the scope of the MANET. 163 For IPv6, Unique Local Addresses (ULAs) 164 [RFC4193][I-D.jelger-autoconf-mla] provide a natural MLA 165 mechanism. 167 MANET Interface 168 a MR's attachment to a link in a MANET. 170 virtual ethernet 171 an imaginary shared link that connects the MRs in a MANET. MRs 172 attach to the virtual ethernet via an interface configured over 173 underlying MANET interface(s) that provides both enhanced and 174 unenhanced "portals" (see: Figure 2 and Figure 3). 176 The enhanced portal encapsulates each IP packet in an outer IP 177 header then sends it on an underlying MANET interface such that 178 the TTL/HOP Limit in the inner IP header is not decremented as the 179 packet traverses the MANET, i.e., the enhanced portal views the 180 MANET as a unified shared link. 182 The unenhanced portal sends each IP packet on an underlying MANET 183 interface without further encapsulation such that the TTL/Hop 184 Limit may be decremented as the packet traverses the MANET, i.e., 185 the unenhanced portal views the MANET as a multilink site. 187 Extended Neighbor Discovery (END) message 188 an IP Neighbor Discovery (ND) message [RFC1256] [RFC2461] 189 transmitted on the unenhanced portal of the MR's virtual ethernet 190 interface with an MLA of the underlying MANET interface as a 191 source address and the destination address set to an MLA or a 192 site-scoped multicast address. The TTL/Hop Limit in END messages 193 may be decremented as the message traverses the MANET. 195 The following figure depicts the architectural model for a MANET 196 router: 198 \ | / \ | / \ | / 199 \|/ \|/ \|/ 200 | | .... | 201 +-------+-------+-----------+--------+ 202 | | | | | 203 D I | | MANET|Interfaces | | U I 204 o n | +---+-------+-----------+---+ | p n 205 w t <--+---+ +----+--> s t 206 n e | | | | t e 207 s r <--+---+ Router Entity +----+--> r r 208 t f . | . | | . | . e f 209 r a . | . | | . | . a a 210 e c . | . +---+-------+-----------+---+ . | . m c 211 a e | |Virtual|P2P Intf's | | e 212 m s | ,-+-. ,-+-. ,-+-. | s 213 | /Host \ /Host \ /Host \ | 214 | (Entity |Entity )...(Entity ) | 215 | \ 1 / \ 2 / \ n / | 216 | `---' `---' `---' | 217 +------------------------------------+ 219 Figure 1: MANET Router 221 3. MANET Autoconfiguration 223 The following sections specify autoconfiguration mechanisms and 224 operational practices that allow MRs to participate in the routing 225 protocol and obtain addresses/prefixes for Intra-MANET and global 226 Internet communications. 228 3.1. MANET Router (MR) Operation 230 Each MR configures MLAs used for operating the routing protocol 231 and/or for assignment on MANET interfaces. For IPv6 MANET 232 interfaces, MLAs are generated using Unique Local Addresses 233 [RFC4193][I-D.jelger-autoconf-mla] with interface identifiers that 234 are either managed for uniqueness (e.g., per [RFC4291], Appendix A) 235 or self-generated using a suitable random interface identifier 236 generation mechanism that is compatible with EUI-64 format (e.g., 237 Cryptographically Generated Addresses (CGAs) [RFC3972], IPv6 privacy 238 addresses [I-D.ietf-ipv6-privacy-addrs-v2], etc.). For IPv4, MLAs 239 are generated using a corresponding unique local address 240 configuration mechanism. (Such a mechanism could be considered as a 241 site-scoped equivalent to IPv4 link-local addresses [RFC3927].) 243 The MR next engages in the routing protocol over its MANET interfaces 244 and discovers the list(s) of MBRs that identify the MANET(s). The 245 list of MBRs is discovered the same as for the ISATAP Potential 246 Router List (PRL) initialization procedure [RFC4214]. One mechanism 247 that can be used is Fully-Qualified Domainname (FQDN) lookup for an 248 FQDN associated with the MANET (e.g., "isatap.example.com") using 249 standard DNS, LLMNR [RFC4795], or node information queries [RFC4620]. 250 Other mechanisms include information learned from the routing 251 protocol, a DHCP option, a DHCP vendor-specific option, or an 252 unspecified alternate method. If the list of MBRs is NULL, an 253 alternate token (such as the IEEE MAC address of an ordinary MR) is 254 used as an identifier for the MANET. 256 For each MANET to which it attaches, the MR also configures a virtual 257 ethernet interface over the underlying MANET interfaces connected to 258 the MANET. The enhanced portal of the virtual ethernet interface 259 presents an opaque view to IP, and configures a link-local address 260 that is assured to be unique among the virtual interfaces of all MRs 261 in the MANET. IP packets sent via the enhanced portal are 262 encapsulated in an outer IP header then submitted to ip_output() for 263 transmission on an underlying MANET interface. The unenhanced portal 264 of the virtual ethernet interface presents a transparent view to IP, 265 and provides direct access to the underlying MANET interfaces and 266 their associated addresses. IP packets sent via the unenhanced 267 portal are transmitted unencapsulated on an underlying MANET 268 interface, but may include an IPv4 source routing header (likewise 269 IPv6 routing header) or a subnetwork-specific encapsulation. 271 Figure 2 shows the protocol stack model for the virtual ethernet 272 output routine, and Figure 3 shows the corresponding model for the 273 virtual ethernet input routine: 275 +--------------------------------------------------+ | 276 | ip_output() | | 277 +--------------------------------------------------+ | 278 | virtual_ethernet_output() | | 279 | | 280 | _ unenhanced portal __ __ enhanced portal ___ | p 281 |/ \ / \| a 282 | - MANET intf already | - select MANET intf | c 283 | selected by ULP | - encapsulate in IP | k 284 | - insert routing hdr | - send to MANET intf | e 285 | (if necessary) | via ip_output() | t 286 | - send directly to +-------------------------+ s 287 | MANET intf | ip_output() | 288 +--------------+---------+----+-...-+--------------+ | 289 | MANET Intf 0 | MANET Intf 1 | ... | MANET Intf n | | 290 | (MLA 0) | (MLA 1) | ... | (MLA n) | | 291 +--------------+--------------+-...-+--------------+ v 293 Figure 2: virtual_ethernet_output() 295 +--------------------------------------------------+ ^ 296 | ip_input() | | 297 +--------------------------------------------------+ | 298 | virtual_ethernet_input() | 299 | | p 300 | _ unenhanced portal __ __ enhanced portal ___ | a 301 |/ \ / \| c 302 | - submit to ip_input() | - decapsulate packet | k 303 | | - submit to ip_input() | e 304 | +-------------------------+ t 305 | | ip_input() | s 306 +--------------+---------+----+-...-+--------------+ 307 | MANET Intf 0 | MANET Intf 1 | ... | MANET Intf n | | 308 | (MLA 0) | (MLA 1) | ... | (MLA n) | | 309 +--------------+--------------+-...-+--------------+ | 311 Figure 3: virtual_ethernet_input() 313 After the MR configures the virtual ethernet interface, it can 314 confirm reachability of MBRs and (in the case of IPv6) discover 315 prefixes associated with the MANET's virtual ethernet. It can 316 confirm reachability by sending/receiving END messages over the 317 unenhanced portal, by sending/receiving ordinary ND messages over the 318 enhanced portal, via information conveyed in the routing protocol 319 itself, or through some other means associated with the particular 320 link technology. For IPv6, prefixes can also be discovered through 321 an out-of-band service discovery protocol. 323 After the MR discovers MBRs, it can configure addresses/prefixes 324 according to either DHCP or IPv6 Stateless Address AutoConfiguration 325 (SLAAC) (but see Appendix B for further considerations on SLAAC). 326 When DHCP is used, the DHCP client associated with (one of) the MR's 327 host entity(s) forwards a DHCP DISCOVER (DHCPv4) or Solicit (DHCPv6) 328 request to the DHCP relay associated with its router entity to 329 request global IP address and/or prefix delegations (see also: 330 Section 3.6). The relay function then forwards the request to one or 331 more MBRs, to other known DHCP servers, or to a site-scoped "All- 332 DHCP-Servers" multicast address. 334 For DHCPv6, the MR's relay function writes an address from the 335 appropriate virtual ethernet interface portal in the "peer-address" 336 field and also writes an address from the prefix associated with the 337 virtual ethernet in the "link-address" field (if a prefix is 338 available). The MR can also use DHCP prefix delegation [RFC3633] to 339 obtain prefixes for assignment and/or further sub-delegation on its 340 downstream-attached links. 342 For DHCPv4, the MR's relay function writes an address from the 343 appropriate virtual ethernet interface portal in the 'giaddr' field 344 and also includes the address in a DHCPv4 MLA option (see: 345 Section 3.4). If necessary to identify the MR's downstream-attached 346 link, the relay also includes a link selection sub-option [RFC3527] 347 with an address from the prefix associated with the virtual ethernet 348 (if a prefix is available). The MR can also use a suitable prefix 349 delegation mechanism to obtain prefixes for further assignment and/or 350 further sub-delegation on its downstream-attached links. 352 The DHCP request will elicit a DHCP reply from a server with IP 353 address/prefix delegations. When addresses are delegated, the MR 354 assigns the resulting addresses to the virtual point-to-point 355 interface that connects its host and router entities, i.e., the 356 addresses are *not* assigned on the virtual ethernet interface or an 357 underlying MANET interface. When prefixes are delegated, the MR can 358 assign and/or further sub-delegate the prefixes to its downstream- 359 attached links. If the MANET uses a proactive routing protocol, the 360 MR can advertise the delegated addresses/prefixes into the routing 361 protocol during the duration of the delegation lifetimes. 363 The DHCP server ensures unique IP address/prefix delegations. By 364 assigning global IP addresses/prefixes only on downstream-attached 365 interfaces there is no requirement for the MR to perform Duplicate 366 Address Detection (DAD) over its virtual ethernet interface. See 367 Appendix A for further DAD considerations. 369 After the MR configures global IP addresses/prefixes, it can send IP 370 packets with global IP source addresses to on- and off-MANET 371 destinations. Packets can be sent to off-MANET destinations either 372 by using any available MBRs as egress gateways or by selecting 373 specific MBRs on a per-packet basis. For MANETs in which MBRs can 374 advertise a 'default' route that propagates throughout the routing 375 protocol, the MR can send IP packets using the unenhanced virtual 376 ethernet interface portal at the expense of extra TTL (IPv4) or Hop 377 Limit (IPv6) decrementation. For MANETs in which the routing 378 protocol cannot propagate a default route, or when the MR wishes to 379 select a specific MBR as the egress gateway, the MR can ensure that 380 the packets will be forwarded through a specific MBR by either 1) 381 sending the packets via the enhanced portal with an MLA for an MBR as 382 the destination address in the outer IP header, or 2) sending the 383 packets via the unenhanced portal and inserting an IPv4 source 384 routing header (likewise IPv6 routing header) or a subnetwork- 385 specific encapsulation. 387 3.2. MANET Border Router Operation 389 MBRs connect the MANET to other networks via their upstream-attached 390 interfaces or via MANET interfaces connected to other MANETs. 392 MBRs send END messages on the virtual ethernet unenhanced port and/or 393 ordinary ND messages on the enhanced port. When stateful 394 configuration is desired, prefixes advertised in RA messages should 395 be advertised as not to be used for on-link determination or 396 StateLess Address AutoConfiguration (SLAAC) [RFC2462] by setting the 397 'A', 'L' bits in Prefix Information Options to 0. (But, see: 398 Appendix B for further considerations on using SLAAC for MANET 399 Autoconfiguration.) 401 MBRs act as BOOTP/DHCP relays and/or servers for a MR's DHCP 402 requests/replies. For DHCPv4, when a MBR acting as a relay forwards 403 a DHCP request that includes an MLA option, it writes its own address 404 in the 'giaddr' field, i.e., it overwrites the value that was written 405 into 'giaddr' by the MR's relay function. 407 3.3. DHCP Server Extensions 409 No MANET autoconfiguration-specific extensions are required for 410 DHCPv6 servers. 412 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 413 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 414 copies the option into the corresponding DHCPv4 reply message(s). 416 3.4. MLA Encapsulation 418 For DHCPv6, the MLA is encoded directly in the "peer-address" field 419 of DHCPv6 requests/replies. 421 For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is 422 required to encode an MLA for DHCP transactions that will traverse a 423 MBR, i.e., so that the MBR has a MANET-relevant address to direct 424 DHCPv4 replies to the correct MR, which may be multiple Layer-3 hops 425 away. The format of the DHCPv4 MLA option is given below: 427 Code Len Ether Type MLA 428 +-----+-----+-----+-----+-----+-----+--- 429 | TBD | n | type | a1 | a2 | ... 430 +-----+-----+-----+-----+-----+-----+--- 432 Code 433 a one-octet field that identifies the option type (see: 434 Section 5). 436 Len 437 a one-octet field that encodes the remaining option length. 439 Ether Type 440 a type value from the IANA "ethernet-numbers" registry. 442 MLA 443 a variable-length MANET Local Address (MLA). 445 3.5. MANET Flooding 447 When multicast service discovery is required, Layer-3 MANETs that 448 implement this specification must use a MANET flooding mechanism 449 (e.g., Simplified Multicast Forwarding (SMF) [I-D.ietf-manet-smf]) so 450 that site-scoped multicast messages can be propagated across multiple 451 Layer-3 hops. 453 3.6. Self-Generated Addresses 455 MR's can self-generate an address (e.g., an IPv6 CGA [RFC3972], an 456 IPv6 privacy address [I-D.ietf-ipv6-privacy-addrs-v2], etc.) then 457 propose the address to the DHCP server. If the DHCP server 458 determines that the self-generated address is unique, it will 459 delegate the address for the MR's use. 461 3.7. Changes to the Neighbor Discovery Model 463 Ordinary link-scoped ND messages work as-normal over the virtual 464 ethernet enhanced port, so ND operation over the enhanced port 465 requires no changes to the standard IP neighbor discovery protocols 466 specified in [RFC1256][RFC2461]. 468 END messages over the virtual ethernet unenhanced port must use a 469 site-scoped unicast source address (i.e., an MLA) and an MLA or site- 470 scoped multicast destination address such that the messages may be 471 forwarded by a router and have their TTL/Hop Limit decremented on the 472 path. This means that END messages provide a site-scoped (and not 473 link-scoped) discovery service which represents a departure from the 474 link-scoped services specified in [RFC1256][RFC2461]. 476 4. Operation with Multiple MBRs 478 For a set of MANETs and MBRs that attach to the same backbone 479 network, MRs can retain their global IP address/prefix delegations as 480 they move if the backbone network participates with the MBRs and MRs 481 in a localized mobility management scheme, e.g., see: 482 [I-D.templin-autoconf-netlmm-dhcp]. 484 For a set of MANETs and MBRs that attach to different backbone 485 networks and/or serve different global IP prefixes from within the 486 same network, MRs must configure new global IP addresses/prefixes as 487 they change between different MBRs unless inter-MBR tunnels and 488 routing protocol exchanges are supported, e.g., see: 489 [I-D.russert-netlmm-hmap]. 491 Global mobility management mechanisms for MRs that configure new 492 global IP addresses/prefixes as they move between different MBRs are 493 beyond the scope of this document. 495 5. IANA Considerations 497 A new DHCP option code is requested for the DHCP MLA Option in the 498 IANA "bootp-dhcp-parameters" registry. 500 6. Security Considerations 502 Threats relating to MANET routing protocols also apply to this 503 document. 505 7. Related Work 507 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 508 program. The virtual ethernet model was proposed by Quang Nguyen 509 under the guidance of Dr. Lixia Zhang. Various IETF AUTOCONF working 510 group proposals have suggested similar mechanisms. 512 8. Acknowledgements 514 The following individuals gave direct and/or indirect input that was 515 essential to the work: Jari Arkko, Emmanuel Bacelli, James Bound, 516 Thomas Clausen, Joe Macker, Thomas Henderson, Bob Hinden, Thomas 517 Narten, Alexandru Petrescu, Jinmei Tatuya, Dave Thaler, and others in 518 the IETF AUTOCONF and MANET working groups. Many others have 519 provided guidance over the course of many years. 521 The Naval Research Lab (NRL) Information Technology Division uses 522 DHCP in their MANET research testbeds. 524 9. References 526 9.1. Normative References 528 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 529 September 1981. 531 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 532 converting network protocol addresses to 48.bit Ethernet 533 address for transmission on Ethernet hardware", STD 37, 534 RFC 826, November 1982. 536 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 537 September 1985. 539 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 540 September 1991. 542 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 543 RFC 2131, March 1997. 545 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 546 Extensions", RFC 2132, March 1997. 548 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 549 (IPv6) Specification", RFC 2460, December 1998. 551 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 552 Discovery for IP Version 6 (IPv6)", RFC 2461, 553 December 1998. 555 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 556 Autoconfiguration", RFC 2462, December 1998. 558 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 559 and M. Carney, "Dynamic Host Configuration Protocol for 560 IPv6 (DHCPv6)", RFC 3315, July 2003. 562 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 563 Host Configuration Protocol (DHCP) version 6", RFC 3633, 564 December 2003. 566 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 567 "Intra-Site Automatic Tunnel Addressing Protocol 568 (ISATAP)", RFC 4214, October 2005. 570 9.2. Informative References 572 [I-D.ietf-autoconf-manetarch] 573 Chakeres, I., "Mobile Ad hoc Network Architecture", 574 draft-ietf-autoconf-manetarch-00 (work in progress), 575 February 2007. 577 [I-D.ietf-ipv6-privacy-addrs-v2] 578 Narten, T., "Privacy Extensions for Stateless Address 579 Autoconfiguration in IPv6", 580 draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress), 581 October 2006. 583 [I-D.ietf-manet-smf] 584 Macker, J., "Simplified Multicast Forwarding for MANET", 585 draft-ietf-manet-smf-03 (work in progress), October 2006. 587 [I-D.jelger-autoconf-mla] 588 Jelger, C., "MANET Local IPv6 Addresses", 589 draft-jelger-autoconf-mla-01 (work in progress), 590 October 2006. 592 [I-D.russert-netlmm-hmap] 593 Russert, S. and F. Templin, "Hierarchical Mobility Anchor 594 Points (HMAPs) for Network Localized Mobility Mangement 595 (NETLMM)", draft-russert-netlmm-hmap-00 (work in 596 progress), February 2007. 598 [I-D.templin-autoconf-netlmm-dhcp] 599 Templin, F., "Network Localized Mobility Management using 600 DHCP", draft-templin-autoconf-netlmm-dhcp-04 (work in 601 progress), October 2006. 603 [I-D.thaler-autoconf-multisubnet-manets] 604 Thaler, D., "Multi-Subnet MANETs", 605 draft-thaler-autoconf-multisubnet-manets-00 (work in 606 progress), February 2006. 608 [I-D.thaler-intarea-multilink-subnet-issues] 609 Thaler, D., "Issues With Protocols Proposing Multilink 610 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 611 (work in progress), March 2006. 613 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 614 (MANET): Routing Protocol Performance Issues and 615 Evaluation Considerations", RFC 2501, January 1999. 617 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 618 "Link Selection sub-option for the Relay Agent Information 619 Option for DHCPv4", RFC 3527, April 2003. 621 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 622 Configuration of IPv4 Link-Local Addresses", RFC 3927, 623 May 2005. 625 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 626 RFC 3972, March 2005. 628 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 629 Addresses", RFC 4193, October 2005. 631 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 632 Architecture", RFC 4291, February 2006. 634 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 635 Queries", RFC 4620, August 2006. 637 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 638 Multicast Name Resolution (LLMNR)", RFC 4795, 639 January 2007. 641 Appendix A. IPv6 Neighbor Discovery (ND) and Duplicate Address 642 Detection (DAD) 644 In terms of ND, existing standards [RFC2461][RFC4291] require that a 645 node configure a link-local address on each of its IPv6-enabled 646 interfaces, but the primary requirement for link-locals seems to be 647 for the purpose of uniquely identifying routers on the link. It is 648 therefore for further study as to whether MRs should send RAs on 649 MANET interfaces (or even configure link local addresses on MANET 650 interfaces at all), since the unenhanced view of the MANET is as a 651 multilink peering point between distinct sites and not a unified 652 link. 654 In terms of DAD, pre-service DAD for an MLA assigned on a MANET 655 interface (such as specified in [RFC2462]) would require either 656 flooding the entire MANET or somehow discovering a link in the MANET 657 on which a node that configures a duplicate address is attached, and 658 performing a (remote) DAD exchange on that link. But, the control 659 message overhead for such a MANET-wide DAD would be substantial and 660 prone to false-negatives due to packet loss and node mobility. An 661 alternative to pre-service DAD is to autoconfigure pseudo-random MLAs 662 on MANET interfaces and employ a passive in-service DAD (e.g., one 663 that monitors routing protocol messages for duplicate assignments). 664 Pseudo-random link-local addresses can be generated with mechanisms 665 such as CGAs, IPv6 privacy addresses, etc., but ULAs provide an 666 additional 40/56 pseudo-random bits in the IPv6 address prefix. 668 Statistical properties can assure uniqueness for the MLAs assigned on 669 a MR's MANET interfaces, and careful operational practices can assure 670 uniqueness for the global addresses/prefixes assigned on a MR's 671 downstream-attached links (since the DHCP server assures unique 672 assignments). However, a passive in-service DAD mechanism should 673 still be used to detect duplicates that were assigned via other 674 means, e.g., manual configuration. 676 Appendix B. IPv6 StateLess Address AutoConfiguration (SLAAC) 678 For IPv6, the use of StateLess Address AutoConfiguration (SLAAC) 679 [RFC2462] could be indicated by prefix information options in END 680 and/or ordinary ND messages with the 'A' bit set to 1. MRs that 681 receive such messages could then self-generate an address from the 682 prefix and assign it to the virtual point-to-point interface 683 associated with the MANET's virtual ethernet, then use a passive in- 684 service DAD approach to detect duplicates within the MANET. But, if 685 the MANET partitions, DAD might not be able to monitor the routing 686 exchanges occurring in other partitions and address duplication could 687 result. Further study on DAD implications for SLAAC in MANETs is 688 required. 690 Appendix C. Change Log 692 Changes from -06 to -07: 694 o added MANET Router diagram. 696 o added new references 698 o various minor text cleanups 700 Changed from -05 to -06: 702 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 704 o minor changes to preserve generality 706 Changed from -04 to -05: 708 o introduced conceptual "virtual ethernet" model. 710 o support "raw" and "cooked" modes as equivalent access methods on 711 the virutal ethernet. 713 Changed from -03 to -04: 715 o introduced conceptual "imaginary shared link" as a representation 716 for a MANET. 718 o discussion of autonomous system and site abstractions for MANETs 720 o discussion of autoconfiguration of CGAs 722 o new appendix on IPv6 StateLess Address AutoConfiguration 724 Changes from -02 to -03: 726 o updated terminology based on RFC2461 "asymmetric reachability" 727 link type; IETF67 MANET Autoconf wg discussions. 729 o added new appendix on IPv6 Neighbor Discovery and Duplicate 730 Address Detection 732 o relaxed DHCP server deployment considerations allow DHCP servers 733 within the MANET itself 735 Changes from -01 to -02: 737 o minor updates for consistency with recent developments 739 Changes from -00 to -01: 741 o new text on DHCPv6 prefix delegation and multilink subnet 742 considerations. 744 o various editorial changes 746 Authors' Addresses 748 Fred L. Templin 749 Boeing Phantom Works 750 P.O. Box 3707 MC 7L-49 751 Seattle, WA 98124 752 USA 754 Email: fred.l.templin@boeing.com 756 Steven W. Russert 757 Boeing Phantom Works 758 P.O. Box 3707 MC 7L-49 759 Seattle, WA 98124 760 USA 762 Email: steven.w.russert@boeing.com 764 Ian D. Chakeres 765 Boeing Phantom Works 766 P.O. Box 3707 MC 7L-49 767 Seattle, WA 98124 768 USA 770 Email: ian.chakeres@gmail.com 772 Seung Yi 773 Boeing Phantom Works 774 P.O. Box 3707 MC 7L-49 775 Seattle, WA 98124 776 USA 778 Email: seung.yi@boeing.com 780 Full Copyright Statement 782 Copyright (C) The IETF Trust (2007). 784 This document is subject to the rights, licenses and restrictions 785 contained in BCP 78, and except as set forth therein, the authors 786 retain all their rights. 788 This document and the information contained herein are provided on an 789 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 790 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 791 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 792 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 793 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 794 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 796 Intellectual Property 798 The IETF takes no position regarding the validity or scope of any 799 Intellectual Property Rights or other rights that might be claimed to 800 pertain to the implementation or use of the technology described in 801 this document or the extent to which any license under such rights 802 might or might not be available; nor does it represent that it has 803 made any independent effort to identify any such rights. Information 804 on the procedures with respect to rights in RFC documents can be 805 found in BCP 78 and BCP 79. 807 Copies of IPR disclosures made to the IETF Secretariat and any 808 assurances of licenses to be made available, or the result of an 809 attempt made to obtain a general license or permission for the use of 810 such proprietary rights by implementers or users of this 811 specification can be obtained from the IETF on-line IPR repository at 812 http://www.ietf.org/ipr. 814 The IETF invites any interested party to bring to its attention any 815 copyrights, patents or patent applications, or other proprietary 816 rights that may cover technology that may be required to implement 817 this standard. Please address the information to the IETF at 818 ietf-ipr@ietf.org. 820 Acknowledgment 822 Funding for the RFC Editor function is provided by the IETF 823 Administrative Support Activity (IASA).