idnits 2.17.1 draft-templin-autoconf-dhcp-08.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 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 884. 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 (June 29, 2007) is 6144 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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-03 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-05 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-05 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 S. Yi 5 Expires: December 31, 2007 Boeing Phantom Works 6 June 29, 2007 8 MANET Autoconfiguration 9 draft-templin-autoconf-dhcp-08.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 December 31, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 global- and/or local-scope IP 46 addresses/prefixes. 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 . . . . . . . 7 56 3.1.2. MNBR List Discovery . . . . . . . . . . . . . . . . . 7 57 3.1.3. Virtual Ethernet Interface Configuration . . . . . . . 8 58 3.1.4. MNBR Reachability Confirmation . . . . . . . . . . . . 9 59 3.1.5. Global-scope Address Autoconfiguration . . . . . . . . 9 60 3.1.6. Local-scope Address Autoconfiguration . . . . . . . . 10 61 3.1.7. Self-Generated IPv6 Interface Identifiers . . . . . . 11 62 3.1.8. Packet Forwarding and Default MNBR Selection . . . . . 11 63 3.2. MANET Border Router (MNBR) Operation . . . . . . . . . . . 12 64 3.3. DHCP Server Extensions . . . . . . . . . . . . . . . . . . 12 65 3.4. MLA Encapsulation . . . . . . . . . . . . . . . . . . . . 12 66 3.5. MANET Flooding . . . . . . . . . . . . . . . . . . . . . . 13 67 3.6. Changes to the Neighbor Discovery Model . . . . . . . . . 13 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Appendix A. IPv6 Neighbor Discovery (ND) and Duplicate 77 Address Detection (DAD) . . . . . . . . . . . . . . . 16 78 Appendix B. IPv6 StateLess Address AutoConfiguration (SLAAC) . . 17 79 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 Intellectual Property and Copyright Statements . . . . . . . . . . 20 83 1. Introduction 85 Mobile Ad-hoc Networks (MANETs) connect MANET Routers (MNRs) on links 86 with asymmetric reachability characteristics (see: [RFC2461], Section 87 2.2). MNRs participate in a routing protocol over MANET interfaces 88 to discover routes across the MANET using multiple forwarding hops if 89 necessary. MANETs may also connect to other networks including the 90 Internet via MANET Border Routers (MNBRs), and MNRs may be multiple 91 hops away from their nearest MNBR in some scenarios. A MANET may be 92 as large as an Autonomous System (AS) or as small as a single MNR 93 (and its attached networks). A MANET may contain other MANETs, and 94 may also be a subnetwork of a larger MANET. MNRs must have a means 95 to automatically provision global- and/or local-scope IP addresses/ 96 prefixes plus other configuration information. 98 Conceptually, a MNR embodies a router entity that connects its 99 attached networks to MANETs and/or other networks including the 100 Internet (see: Figure 1). The router entity also connects to an 101 imaginary shared link via a "virtual ethernet" interface configured 102 over its MANET interfaces (see: Figure 2 and Figure 3). An "opaque" 103 view of this virtual ethernet sees the MANET as a fully-connected 104 shared link that connects all MNRs, while a "transparent" view sees 105 the MANET as a multilink site. For each distinct MANET to which they 106 connect, MNRs discover a list of MNBRs that determines the MANET's 107 identity. An MNR (and its attached networks) is a "site" unto 108 itself, and a MANET is therefore a "site-of-sites". 110 MANETs that comprise homogeneous link types can configure the routing 111 protocol to operate as a sub-IP layer mechanism such that IP sees the 112 MANET as an ordinary shared link the same as for a (bridged) campus 113 LAN. In that case, a single IP hop is sufficient to traverse the 114 MANET. 116 MANETs that comprise heterogeneous link types must instead (or, in 117 addition) provide a routing service that operates as an IP layer 118 mechanism to accommodate media types with dissimilar Layer-2 address 119 formats and maximum transmission units (MTUs). In that case, 120 multiple IP hops may be necessary to traverse the MANET. 122 This document specifies mechanisms and operational practices for 123 MANET autoconfiguration. Operation using standard DHCP 124 [RFC2131][RFC3315][RFC3633] and neighbor discovery 125 [RFC1256][RFC2461][RFC2462] mechanisms is assumed unless otherwise 126 specified. Both IPv4 [RFC0791] and IPv6 [RFC2460] are discussed. 128 2. Terminology 130 The terminology in [I-D.ietf-autoconf-manetarch] and the normative 131 references apply; the following terms are defined within the scope of 132 this document: 134 subnetwork 135 the same as defined in [RFC3819]. 137 egress/ingress interface 138 the same as defined in ([RFC3753], Section 3). 140 MANET Interface 141 a MANET Router's attachment to an asymmetric reachability link 142 (see: [RFC2461], Section 2.2). A MANET interface is a "lateral" 143 interface, i.e., it is inherently neither an ingress nor egress 144 interface although it can sometimes exhibit characteristics of 145 both. 147 Mobile Ad-hoc Network (MANET) 148 a connected network region of MANET routers that maintain a 149 routing structure among themselves over MANET interfaces. A MANET 150 may be as large as an Autonomous System (AS) or as small as a 151 single MANET router, and may also be a subnetwork of a larger 152 MANET. A MANET router (and its attached networks) is a "site" 153 unto itself, and a MANET is therefore a "site-of-sites". (Note 154 that this document considers the terms "MANET" and "site" as 155 functional equivalents.) 157 Further information on the characteristics of MANETs can be found 158 in [RFC2501]. 160 MANET Router (MNR) 161 a node that participates in a routing protocol on its MANET 162 interface(s) and forwards packets on behalf of both other MNRs and 163 "downstream" networks attached on its ingress interfaces. A MNR 164 can also connect to "upstream" networks either directly on its 165 egress interfaces or indirectly via MNBRs. For the purpose of 166 this specification, an MNR comprises a router entity, one or more 167 host entities, and its attached ingress/egress/MANET interfaces 168 (see: Figure 1). 170 MANET Border Router (MNBR) 171 an MNR that connects a MANET to "upstream" networks (including the 172 Internet) over egress interfaces. 174 MANET Local Address (MLA) 175 an IP unicast address configured by an MNR that is unique within 176 the MANET; it is used as an identifier for operating the routing 177 protocol and may also be assigned to a MANET interface as a 178 locator for packet forwarding within the scope of the MANET. 180 virtual ethernet 181 an imaginary shared link that connects all MNRs in a MANET. MNRs 182 attach to the virtual ethernet via an interface that is configured 183 over underlying MANET interface(s) and presents both opaque and 184 transparent "portals" (see: Figure 2 and Figure 3). 186 The opaque portal encapsulates each IP packet in an outer IP 187 header then sends it on an underlying MANET interface such that 188 the TTL/HOP Limit in the inner IP header is not decremented as the 189 packet traverses the MANET, i.e., the opaque portal views the 190 MANET as a unified shared link. 192 The transparent portal sends each IP packet on an underlying MANET 193 interface without further encapsulation such that the TTL/Hop 194 Limit may be decremented as the packet traverses the MANET, i.e., 195 the transparent portal views the MANET as a multilink site. 197 Extended Neighbor Discovery (END) message 198 an IP Neighbor Discovery (ND) message [RFC1256] [RFC2461] 199 transmitted on the transparent portal of the MNR's virtual 200 ethernet interface with an MLA of the underlying MANET interface 201 as a source address and with destination address set to an MLA or 202 a site-scoped multicast address. The TTL/Hop Limit in END 203 messages may be decremented as the message traverses the MANET. 205 The following figure depicts the architectural model for a MANET 206 router: 208 Egress Interfaces (to Internet) 209 ^ ^ ^ 210 | | | 211 +------------------------+---+--------+----------+ 212 | Internal hosts | | | | M 213 | an routers | | .... | | A 214 | ,-. | +---+---+--------+---+ | N 215 | (H1 )---+ | | | E 216 | | `-' | | +------+--< T 217 | . | +---+ | | | | 218 | . +--|R1 |---+-----+ | | I 219 | . | +---+ | | Router +------+--< n 220 | | ,-. | | | . | t 221 | (H2 )---+ | Entity | . | e 222 | `-' | . | | . | r 223 | . | | . | f 224 | ,-. . | +------+--< a 225 | (Hn )---------+ | | c 226 | `-' +---+---+--------+---+ | e 227 | Ingress Interfaces | | .... | | s 228 | (to internal networks) | | | | 229 +------------------------+---+--------+----------+ 230 | | | 231 v v v 232 Ingress Interfaces (to external networks) 234 Figure 1: MANET Router 236 3. MANET Autoconfiguration 238 3.1. MANET Router (MNR) Operation 240 The following sections specify autoconfiguration mechanisms and/or 241 operational practices used by MNRs to support egress interfaces that 242 connect "upstream" (i.e., toward fixed Internet infrastructure), 243 ingress interfaces that connect "downstream" to internal and external 244 networks (i.e., away from fixed Internet infrastructure), and MANET 245 interfaces that connect the MNR "laterally" to other MNRs. Egress 246 interfaces have addresses assigned or validated by other devices, 247 ingress interface addresses are controlled by the MNR, and MANET 248 interface addresses are coordinated with other MNRs. MNRs engage in 249 the routing protocol on MANET interfaces, configure virtual ethernet 250 interfaces, and obtain global- and/or local-scope addresses/prefixes 251 using these mechanisms and practices. 253 3.1.1. MANET Local Address (MLA) Configuration 255 Upon joining a MANET, each MNR first configures an MLA used for 256 operating the routing protocol and/or for local communications within 257 the MANET. 259 IPv6 MLAs can be administratively assigned, dynamically configured 260 using DHCP[RFC3315], autoconfigured using IPv6 StateLess Address 261 AutoConfiguration (SLAAC) [RFC2462], or self-generated using IPv6 262 Unique Local Addresses (ULAs) [RFC4193][I-D.ietf-ipv6-ula-central]. 263 The MLAs include interface identifiers that are either managed for 264 uniqueness (see: [RFC4291], Appendix A) or self-generated using a 265 suitable pseudo-random interface identifier generation mechanism 266 (e.g., Cryptographically Generated Addresses (CGAs) [RFC3972], IPv6 267 privacy addresses [I-D.ietf-ipv6-privacy-addrs-v2], etc.). 269 IPv4 MLAs can be administratively assigned, dynamically configured 270 using DHCP [RFC2131] or self-generated using an unspecified IPv4 271 unique local address configuration mechanism. (Such a mechanism 272 could be considered as a site-scoped equivalent to IPv4 link-local 273 addresses [RFC3927].) 275 When there is no administratively assigned MLA, the choice of 276 attempting to dynamically configure an MLA using DHCP or self- 277 generate one using some other mechanism is up to the MNR. DHCP- 278 generated MLAs have the benefit of a "managed" avoidance of address 279 collisions, while self-generated MLAs must be monitored for 280 collisions with other nodes that might assign a duplicate. Note also 281 that DHCP service for MLA configuration may not be available in all 282 MANETs. 284 DHCP configuration of MLAs for both IPv4 and IPv6 requires relay 285 support from other MNRs that have already been autoconfigured within 286 the MANET. In particular, since a MNR presumably has no usable site- 287 scoped addresses before configuring an MLA, it must send its DHCP 288 requests to a link-scoped broadcast/multicast address and await a 289 (relayed) address delegation reply from a server. This means that 290 all MNRs should be prepared to act as DHCP relays on behalf of 291 neighboring MNRs that have recently joining the MANET, and relay any 292 link-scoped DHCP requests to either a site-scoped "All-DHCP-Servers" 293 address or to one or more unicast addresses. 295 3.1.2. MNBR List Discovery 297 After configuring MLAs, the MNR next engages in the routing 298 protocol(s) over its MANET interfaces and discovers the list of MNBRs 299 on the MANET. The list of MNBRs is discovered the same as for the 300 ISATAP Potential Router List (PRL) initialization procedure 301 ([RFC4214], Section 8.3.2); it also serves as an identifier for the 302 MANET. (If the list of MNBRs is NULL, an alternate token such as the 303 Layer-2 address of an ordinary MNR can serve as an identifier for the 304 MANET.) 306 3.1.3. Virtual Ethernet Interface Configuration 308 The MNR configures a virtual ethernet interface that connects all 309 MNRs in the MANET over the underlying MANET interfaces. 311 The opaque portal of the virtual ethernet interface configures a 312 link-local address that is assured to be unique among the virtual 313 interfaces of all MNRs in the MANET (e.g., an ISATAP link-local 314 address configured per ([RFC4214], Section 6.2) and derived from a 315 MANET interface's IPv4 MLA). IP packets sent via the opaque portal 316 are encapsulated in an outer IP header then submitted to ip_output() 317 for transmission on an underlying MANET interface. 319 The transparent portal of the virtual ethernet interface configures 320 no addresses itself, but rather provides IP with direct access to the 321 underlying MANET interfaces and their associated addresses. IP 322 packets sent via the transparent portal are transmitted 323 unencapsulated on an underlying MANET interface, but may include an 324 IPv4 source routing header (likewise IPv6 routing header) or a 325 subnetwork-specific encapsulation. 327 Figure 2 depicts the protocol stack model for the virtual ethernet 328 output routine, and Figure 3 depicts the corresponding model for the 329 virtual ethernet input routine: 331 +--------------------------------------------------+ | 332 | ip_output() | | 333 +--------------------------------------------------+ | 334 | virtual_ethernet_output() | | 335 | | 336 | _ transparent portal _ ___ opaque portal _____ | p 337 |/ \ / \| a 338 | - MANET intf already | - select MANET intf | c 339 | selected by ULP | - encapsulate in IP | k 340 | - insert routing hdr | - send to MANET intf | e 341 | (if necessary) | via ip_output() | t 342 | - send directly to +-------------------------+ s 343 | MANET intf | ip_output() | 344 +--------------+---------+----+-...-+--------------+ | 345 | MANET Intf 0 | MANET Intf 1 | ... | MANET Intf n | | 346 | (MLA 0) | (MLA 1) | ... | (MLA n) | | 347 +--------------+--------------+-...-+--------------+ v 348 Figure 2: virtual_ethernet_output() 350 +--------------------------------------------------+ ^ 351 | ip_input() | | 352 +--------------------------------------------------+ | 353 | virtual_ethernet_input() | 354 | | p 355 | _ transparent portal _ ___ opaque portal ____ | a 356 |/ \ / \| c 357 | - submit to ip_input() | - decapsulate packet | k 358 | | - submit to ip_input() | e 359 | +-------------------------+ t 360 | | ip_input() | s 361 +--------------+---------+----+-...-+--------------+ 362 | MANET Intf 0 | MANET Intf 1 | ... | MANET Intf n | | 363 | (MLA 0) | (MLA 1) | ... | (MLA n) | | 364 +--------------+--------------+-...-+--------------+ | 366 Figure 3: virtual_ethernet_input() 368 3.1.4. MNBR Reachability Confirmation 370 After the MNR configures a virtual ethernet interface, it can confirm 371 reachability of MNBRs and (in the case of IPv6) discover prefixes 372 associated with the MANET's virtual ethernet. (It can also discover 373 IPv6 prefixes through a MANET-specific out-of-band service discovery 374 protocol.) The MNR can confirm reachability by sending/receiving END 375 messages over the transparent portal, by sending/receiving ordinary 376 ND messages over the opaque portal, via reachability information 377 conveyed in the routing protocol itself, or through some other means 378 associated with the particular MANET subnetwork technology. 380 The MNR can then configure global- or local-scope addresses as 381 specified in the following sections: 383 3.1.5. Global-scope Address Autoconfiguration 385 After the MNR discovers MNBRs, it can configure global-scope 386 addresses/prefixes that are topologically correct for the MANET 387 according to either DHCP or IPv6 Stateless Address AutoConfiguration 388 (SLAAC) (but see Appendix B for further considerations on SLAAC). 389 When DHCP is used, a DHCP client associated with (one of) the MNR's 390 host entity(s) forwards a DHCP DISCOVER (DHCPv4) or Solicit (DHCPv6) 391 request to a DHCP relay associated with its router entity to request 392 IP address and/or prefix delegations. (In other words, the MNR acts 393 as both DHCP client and relay.) The relay function then forwards the 394 request to one or more MNBRs, to other known DHCP servers, or to a 395 site-scoped "All-DHCP-Servers" multicast address. 397 For DHCPv6, the MNR's relay function writes an address from the 398 appropriate virtual ethernet interface portal in the "peer-address" 399 field and also writes an address from the prefix associated with the 400 virtual ethernet in the "link-address" field (if a prefix is 401 available). The MNR can also use DHCP prefix delegation [RFC3633] to 402 obtain global-scope prefixes for assignment and/or further sub- 403 delegation on networks connected on its ingress interfaces. 405 For DHCPv4, the MNR's relay function writes an address from the 406 appropriate virtual ethernet interface portal in the 'giaddr' field 407 and also includes the address in a DHCPv4 MLA option (see: 408 Section 3.4). If necessary to identify the MNR's ingress interface, 409 the relay also includes a link selection sub-option [RFC3527] with an 410 address from the prefix associated with the MANET's virtual ethernet 411 (if a prefix is available). The MNR can also use a prefix delegation 412 mechanism [I-D.ietf-dhc-subnet-alloc] to obtain prefixes for further 413 assignment and/or further sub-delegation on networks connected on its 414 ingress interfaces. 416 The DHCP request will elicit a DHCP reply from a server with IP 417 address/prefix delegations. When addresses are delegated, the MNR 418 assigns the resulting addresses to an ingress interface, i.e., it 419 does *not* assign the addresses on the virtual ethernet interface or 420 an underlying MANET interface. When prefixes are delegated, the MNR 421 can assign and/or further sub-delegate them to networks connected on 422 its ingress interfaces. If the MANET subnetwork uses a proactive 423 routing protocol, the MNR can advertise the delegated addresses/ 424 prefixes into the routing protocol during the duration of the 425 delegation lifetimes. 427 The DHCP server ensures IP address/prefix delegations that are unique 428 within the MANET. By assigning these IP addresses/prefixes only on 429 ingress interfaces there is no requirement for the MNR to perform 430 Duplicate Address Detection (DAD) over its MANET interfaces or 431 virtual ethernet interface. See Appendix A for further DAD 432 considerations. 434 3.1.6. Local-scope Address Autoconfiguration 436 Independent of any global-scope addresses autoconfigured per 437 Section 3.1.5, MNR's can self-generate IPv6 Unique Local Address 438 (ULA) prefixes [RFC4193][I-D.ietf-ipv6-ula-central] and use them to 439 assign addresses/prefixes on networks connected on its ingress 440 interfaces. Note that in some scenarios a MNR may not require any 441 global-scope address/prefix assignments at all, and can use ULAs 442 instead. (This is particularly true for the use case of joining two 443 MANETs via either physical or virtual links.) 445 Self-generated local-scope addresses are portable and not relative to 446 the MNR's current MANET of attachment. The addresses can therefore 447 travel with the MNR as it moves to new MANETs. Self-generation of 448 local-scope addresses can therefore occur independently of any other 449 MNR autoconfiguration considerations. 451 3.1.7. Self-Generated IPv6 Interface Identifiers 453 MNR's can create self-generated IPv6 interface identifiers such as 454 specified for CGAs [RFC3972], IPv6 privacy address 455 [I-D.ietf-ipv6-privacy-addrs-v2], etc. 457 For global-scope address autoconfiguration (see: Section 3.1.5, the 458 MNR can propose self-generated address to the DHCPv6 server which 459 will delegate the address to the MNR for assignment on an ingress 460 interface if the proposed address is unique. 462 For local-scope address autoconfiguration (see: Section 3.1.6), the 463 MNR simply assigns the address to an ingress interface, since it is 464 the responsible delegation authority for its own local-scope 465 prefixes. 467 3.1.8. Packet Forwarding and Default MNBR Selection 469 After the MNR configures IP addresses/prefixes, it can forward IP 470 packets to on- and off-MANET destinations. Packets can be forwarded 471 to off-MANET destinations either by using any available MNBRs as 472 egress gateways or by selecting specific MNBRs. 474 For MANETs in which MNBRs can advertise a 'default' route that 475 propagates throughout the routing protocol, the MNR can forward IP 476 packets using the transparent virtual ethernet interface portal at 477 the expense of extra TTL (IPv4) or Hop Limit (IPv6) decrementation. 479 For MANETs in which the routing protocol cannot propagate a default 480 route, or when the MNR wishes to select a specific MNBR as the egress 481 gateway, the MNR can ensure that the packets will be forwarded 482 through a specific MNBR by either 1) forwarding the packets via the 483 opaque portal with an MLA for an MNBR as the destination address in 484 the outer IP header, or 2) forwarding the packets via the transparent 485 portal and inserting an IPv4 source routing header (likewise IPv6 486 routing header) or a subnetwork-specific encapsulation. 488 3.2. MANET Border Router (MNBR) Operation 490 MNBRs connect the MANET to upstream networks over its egress 491 interfaces. 493 MNBRs send/receive END messages on the virtual ethernet transparent 494 portal and/or ordinary ND messages on the opaque portal. When 495 stateful configuration is desired, MNBRs should advertise prefixes in 496 RA messages as not to be used for on-link determination or StateLess 497 Address AutoConfiguration (SLAAC) [RFC2462] by setting the 'A', 'L' 498 bits in Prefix Information Options to 0. (But, see: Appendix B for 499 further considerations on using SLAAC for MANET Autoconfiguration.) 501 MNBRs act as DHCP relays and/or servers for a MNR's DHCP requests/ 502 replies. For DHCPv4, when a MNBR acting as a relay forwards a DHCP 503 request that includes an MLA option, it writes its own address in the 504 'giaddr' field, i.e., it overwrites the value that was written into 505 'giaddr' by the MNR's relay function. 507 3.3. DHCP Server Extensions 509 No MANET autoconfiguration-specific extensions are required for 510 DHCPv6 servers. 512 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 513 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 514 copies the option into the corresponding DHCPv4 reply message(s). 515 Note that this extension is only required for DHCPv4 servers that 516 support global IPv4 address/prefix delegations for MNRs - see: 517 Section 3.1.5. 519 3.4. MLA Encapsulation 521 For DHCPv6, the MLA is encoded directly in the "peer-address" field 522 of DHCPv6 requests/replies. 524 For DHCPv4 delegation of global IPv4 addresses/prefixes, a new DHCPv4 525 option [RFC2132] called the 'MLA option' is required to encode an MLA 526 for DHCP transactions that will traverse a MNBR, i.e., so that the 527 MNBR has a MANET-relevant address to direct DHCPv4 replies to the 528 correct MNR, which may be multiple IP hops away. The format of the 529 DHCPv4 MLA option is given below: 531 Code Len Ether Type MLA 532 +-----+-----+-----+-----+-----+-----+--- 533 | TBD | n | type | a1 | a2 | ... 534 +-----+-----+-----+-----+-----+-----+--- 535 Code 536 a one-octet field that identifies the option type (see: 537 Section 4). 539 Len 540 a one-octet field that encodes the remaining option length. 542 Ether Type 543 a type value from the IANA "ethernet-numbers" registry. 545 MLA 546 a variable-length MANET Local Address (MLA). 548 3.5. MANET Flooding 550 When multicast service discovery is required, MANETs that operate 551 routing as an IP layer service must use a multicast flooding 552 mechanism (e.g., Simplified Multicast Forwarding (SMF) 553 [I-D.ietf-manet-smf]) so that site-scoped multicast messages will be 554 propagated across the MANET. 556 3.6. Changes to the Neighbor Discovery Model 558 Ordinary link-scoped ND messages work as-normal over the virtual 559 ethernet opaque portal, so ND operation over the opaque portal 560 requires no changes to the standard IP neighbor discovery protocols 561 specified in [RFC1256][RFC2461]. 563 END messages over the virtual ethernet transparent portal must use a 564 site-scoped unicast source address (i.e., an MLA) and an MLA or site- 565 scoped multicast destination address such that the messages may be 566 forwarded by a router and have their TTL/Hop Limit decremented on the 567 path. This means that END messages provide a site-scoped (and not 568 link-scoped) discovery service which represents a departure from the 569 link-scoped services specified in [RFC1256][RFC2461]. 571 4. IANA Considerations 573 A new DHCPv4 option code is requested for the DHCPv4 MLA Option in 574 the IANA "bootp-dhcp-parameters" registry (TBD, based on use case 575 analysis for global IPv4 address configuration per Section 3.1). 577 5. Security Considerations 579 Threats relating to MANET routing protocols also apply to this 580 document. 582 6. Related Work 584 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 585 program. The Naval Research Lab (NRL) Information Technology 586 Division uses DHCP in their MANET research testbeds. The virtual 587 ethernet model was proposed by Quang Nguyen under the guidance of Dr. 588 Lixia Zhang. Various IETF AUTOCONF working group proposals have 589 suggested similar mechanisms. 591 7. Acknowledgements 593 The following individuals gave direct and/or indirect input that was 594 essential to the work: Jari Arkko, Emmanuel Bacelli, James Bound, 595 Thomas Clausen, Joe Macker, Thomas Henderson, Bob Hinden, Thomas 596 Narten, Alexandru Petrescu, Jinmei Tatuya, Dave Thaler, and others in 597 the IETF AUTOCONF and MANET working groups. Many others have 598 provided guidance over the course of many years. 600 8. Contributors 602 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 603 of this document. 605 9. References 607 9.1. Normative References 609 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 610 September 1981. 612 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 613 September 1991. 615 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 616 RFC 2131, March 1997. 618 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 619 Extensions", RFC 2132, March 1997. 621 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 622 (IPv6) Specification", RFC 2460, December 1998. 624 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 625 Discovery for IP Version 6 (IPv6)", RFC 2461, 626 December 1998. 628 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 629 Autoconfiguration", RFC 2462, December 1998. 631 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 632 and M. Carney, "Dynamic Host Configuration Protocol for 633 IPv6 (DHCPv6)", RFC 3315, July 2003. 635 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 636 Host Configuration Protocol (DHCP) version 6", RFC 3633, 637 December 2003. 639 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 640 "Intra-Site Automatic Tunnel Addressing Protocol 641 (ISATAP)", RFC 4214, October 2005. 643 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 644 Architecture", RFC 4291, February 2006. 646 9.2. Informative References 648 [I-D.ietf-autoconf-manetarch] 649 Chakeres, I., "Mobile Ad hoc Network Architecture", 650 draft-ietf-autoconf-manetarch-03 (work in progress), 651 June 2007. 653 [I-D.ietf-dhc-subnet-alloc] 654 Johnson, R., "Subnet Allocation Option", 655 draft-ietf-dhc-subnet-alloc-05 (work in progress), 656 June 2007. 658 [I-D.ietf-ipv6-privacy-addrs-v2] 659 Narten, T., "Privacy Extensions for Stateless Address 660 Autoconfiguration in IPv6", 661 draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress), 662 October 2006. 664 [I-D.ietf-ipv6-ula-central] 665 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 666 Addresses", draft-ietf-ipv6-ula-central-02 (work in 667 progress), June 2007. 669 [I-D.ietf-manet-smf] 670 Macker, J., "Simplified Multicast Forwarding for MANET", 671 draft-ietf-manet-smf-05 (work in progress), June 2007. 673 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 674 (MANET): Routing Protocol Performance Issues and 675 Evaluation Considerations", RFC 2501, January 1999. 677 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 678 "Link Selection sub-option for the Relay Agent Information 679 Option for DHCPv4", RFC 3527, April 2003. 681 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 682 RFC 3753, June 2004. 684 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 685 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 686 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 687 RFC 3819, July 2004. 689 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 690 Configuration of IPv4 Link-Local Addresses", RFC 3927, 691 May 2005. 693 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 694 RFC 3972, March 2005. 696 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 697 Addresses", RFC 4193, October 2005. 699 Appendix A. IPv6 Neighbor Discovery (ND) and Duplicate Address 700 Detection (DAD) 702 In terms of ND, existing standards [RFC2461][RFC4291] require that a 703 node configure a link-local address on each of its IPv6-enabled 704 interfaces, but the primary requirement for link-locals seems to be 705 for the purpose of uniquely identifying routers on the link. It is 706 therefore for further study as to whether MNRs should send RAs on 707 MANET interfaces (or even configure link local addresses on MANET 708 interfaces at all), since the transparent view of the MANET appears 709 as a multilink peering point between distinct sites and not a unified 710 link. 712 In terms of DAD, pre-service DAD for an MLA assigned on a MANET 713 interface (such as specified in [RFC2462]) would require either 714 flooding the entire MANET or somehow discovering a link in the MANET 715 on which a node that configures a duplicate address is attached and 716 performing a localized DAD exchange on that link. But, the control 717 message overhead for such a MANET-wide DAD would be substantial and 718 prone to false-negatives due to packet loss and node mobility. An 719 alternative to pre-service DAD is to autoconfigure pseudo-random MLAs 720 on MANET interfaces and employ a passive in-service DAD (e.g., one 721 that monitors routing protocol messages for duplicate assignments). 722 Pseudo-random link-local addresses can be generated with mechanisms 723 such as CGAs, IPv6 privacy addresses, etc. with very small 724 probability of collision. But, IPv6 ULAs also provide an additional 725 40 pseudo-random bits in the IPv6 address prefix. 727 Statistical properties for pseudo-random address self-generation can 728 assure uniqueness for the MLAs assigned on a MNR's MANET interfaces, 729 and careful operational practices can assure uniqueness for global- 730 and local-scope addresses/prefixes. However, a passive in-service 731 DAD mechanism should still be used to detect duplicates that were 732 assigned through other means, e.g., manual configuration. 734 Appendix B. IPv6 StateLess Address AutoConfiguration (SLAAC) 736 For IPv6, the use of StateLess Address AutoConfiguration (SLAAC) 737 [RFC2462] could be indicated by prefix information options in END 738 and/or ordinary ND messages with the 'A' bit set to 1. MNRs that 739 receive such messages could then self-generate an address from the 740 prefix and assign it to the MANET's virtual ethernet interface, then 741 use a passive in-service DAD approach to detect duplicates within the 742 MANET. But, if the MANET partitions, DAD might not be able to 743 monitor the other partitions and address duplication could result. 744 Further study on DAD implications for SLAAC in MANETs is required. 746 Appendix C. Change Log 748 Changes from -07 to -08: 750 o changed terms "unenhanced" and "enhanced" to "transparent" and 751 "opaque". 753 o revised MANET Router diagram. 755 o introduced RFC3753 terminology for Mobile Router; ingress/egress 756 interface. 758 o changed abbreviations to "MNR" and "MNBR". 760 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 762 o rearranged Section 3.1. 764 o various minor text cleanups 766 Changes from -06 to -07: 768 o added MANET Router diagram. 770 o added new references 772 o various minor text cleanups 774 Changed from -05 to -06: 776 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 778 o minor changes to preserve generality 780 Changed from -04 to -05: 782 o introduced conceptual "virtual ethernet" model. 784 o support "raw" and "cooked" modes as equivalent access methods on 785 the virutal ethernet. 787 Changed from -03 to -04: 789 o introduced conceptual "imaginary shared link" as a representation 790 for a MANET. 792 o discussion of autonomous system and site abstractions for MANETs 794 o discussion of autoconfiguration of CGAs 796 o new appendix on IPv6 StateLess Address AutoConfiguration 798 Changes from -02 to -03: 800 o updated terminology based on RFC2461 "asymmetric reachability" 801 link type; IETF67 MANET Autoconf wg discussions. 803 o added new appendix on IPv6 Neighbor Discovery and Duplicate 804 Address Detection 806 o relaxed DHCP server deployment considerations allow DHCP servers 807 within the MANET itself 809 Changes from -01 to -02: 811 o minor updates for consistency with recent developments 813 Changes from -00 to -01: 815 o new text on DHCPv6 prefix delegation and multilink subnet 816 considerations. 818 o various editorial changes 820 Authors' Addresses 822 Fred L. Templin 823 Boeing Phantom Works 824 P.O. Box 3707 MC 7L-49 825 Seattle, WA 98124 826 USA 828 Email: fred.l.templin@boeing.com 830 Steven W. Russert 831 Boeing Phantom Works 832 P.O. Box 3707 MC 7L-49 833 Seattle, WA 98124 834 USA 836 Email: steven.w.russert@boeing.com 838 Seung Yi 839 Boeing Phantom Works 840 P.O. Box 3707 MC 7L-49 841 Seattle, WA 98124 842 USA 844 Email: seung.yi@boeing.com 846 Full Copyright Statement 848 Copyright (C) The IETF Trust (2007). 850 This document is subject to the rights, licenses and restrictions 851 contained in BCP 78, and except as set forth therein, the authors 852 retain all their rights. 854 This document and the information contained herein are provided on an 855 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 856 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 857 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 858 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 859 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 860 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 Intellectual Property 864 The IETF takes no position regarding the validity or scope of any 865 Intellectual Property Rights or other rights that might be claimed to 866 pertain to the implementation or use of the technology described in 867 this document or the extent to which any license under such rights 868 might or might not be available; nor does it represent that it has 869 made any independent effort to identify any such rights. Information 870 on the procedures with respect to rights in RFC documents can be 871 found in BCP 78 and BCP 79. 873 Copies of IPR disclosures made to the IETF Secretariat and any 874 assurances of licenses to be made available, or the result of an 875 attempt made to obtain a general license or permission for the use of 876 such proprietary rights by implementers or users of this 877 specification can be obtained from the IETF on-line IPR repository at 878 http://www.ietf.org/ipr. 880 The IETF invites any interested party to bring to its attention any 881 copyrights, patents or patent applications, or other proprietary 882 rights that may cover technology that may be required to implement 883 this standard. Please address the information to the IETF at 884 ietf-ipr@ietf.org. 886 Acknowledgment 888 Funding for the RFC Editor function is provided by the IETF 889 Administrative Support Activity (IASA).