idnits 2.17.1 draft-templin-autoconf-dhcp-21.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1290. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (November 17, 2008) is 5638 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: 'ENCAPS' is mentioned on line 157, but not defined == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1021, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-07 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-08 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Phantom Works 4 Intended status: Informational November 17, 2008 5 Expires: May 21, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-21.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 21, 2009. 35 Abstract 37 Enterprise networks connect routers over various link types, and may 38 also connect to provider networks and/or the global Internet. Nodes 39 in enterprise networks must have a way to automatically provision IP 40 addresses/prefixes and other information, and must also support post- 41 autoconfiguration operations even for highly-dynamic networks. This 42 document specifies a Virtual Enterprise Traversal (VET) abstraction 43 for autoconfiguration and operation of nodes in enterprise networks. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 7 50 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 8 51 4.1. Enterprise Interior Router (EIR) Autoconfiguration . . . . 9 52 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 10 53 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 10 54 4.2.2. Inner IP Address/Prefix Delegation and Maintenance . . 12 55 4.2.3. Portable Inner IP Addresses/Prefixes . . . . . . . . . 12 56 4.2.4. Enterprise-edge Interface Autoconfiguration . . . . . 13 57 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 13 58 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 13 59 5. Post-Autoconfiguration Operation . . . . . . . . . . . . . . . 14 60 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 14 61 5.2. DHCP Prefix Delegation Maintenance . . . . . . . . . . . . 14 62 5.3. IPv6 Address Mapping Service . . . . . . . . . . . . . . . 15 63 5.4. IPv6 EBR/EBG Router Discovery . . . . . . . . . . . . . . 15 64 5.5. Forwarding Packets to Destinations Outside of the 65 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 16 66 5.6. Source Address Verification . . . . . . . . . . . . . . . 17 67 5.7. Enterprise-Local Communications . . . . . . . . . . . . . 17 68 5.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17 69 5.9. Service Discovery . . . . . . . . . . . . . . . . . . . . 18 70 6. Enterprise Partitioning . . . . . . . . . . . . . . . . . . . 18 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 73 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 75 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 79 Appendix A. Duplicate Address Detection (DAD) Considerations . . 23 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 Intellectual Property and Copyright Statements . . . . . . . . . . 28 84 1. Introduction 86 Enterprise networks [RFC4852] connect routers over various link types 87 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 88 (MANETs) [RFC2501] can be considered as a challenging example of an 89 enterprise network, in that their topologies may change dynamically 90 over time and that they may employ little/no active management by a 91 centralized network administrative authority. These specialized 92 characteristics for MANETs require careful consideration, but the 93 same principles apply equally to other enterprise network scenarios. 95 This document specifies a Virtual Enterprise Traversal (VET) 96 abstraction for autoconfiguration and runtime operation of nodes in 97 enterprises, where addresses of different scopes may be assigned on 98 various types of interfaces with diverse properties. Both IPv4 99 [RFC0791] and IPv6 [RFC2460] are discussed within this context. The 100 use of standard DHCP [RFC2131][RFC3315] and neighbor discovery 101 [RFC0826][RFC4861] mechanisms is assumed unless otherwise specified. 103 Provider-edge Interfaces 104 x x x 105 | | | 106 +--------------------+---+--------+----------+ E 107 | | | | | n 108 | I | | .... | | t 109 | n +---+---+--------+---+ | e 110 | t | +--------+ /| | r 111 | e I x----+ | Host | I /*+------+--< p I 112 | r n | |Function| n|**| | r n 113 | n t | +--------+ t|**| | i t 114 | a e x----+ V e|**+------+--< s e 115 | l r . | E r|**| . | e r 116 | f . | T f|**| . | f 117 | V a . | +--------+ a|**| . | I a 118 | i c . | | Router | c|**| . | n c 119 | r e x----+ |Function| e \*+------+--< t e 120 | t s | +--------+ \| | e s 121 | u +---+---+--------+---+ | r 122 | a | | .... | | i 123 | l | | | | o 124 +--------------------+---+--------+----------+ r 125 | | | 126 x x x 127 Enterprise-edge Interfaces 129 Figure 1: Enterprise Router Architecture 131 Figure 1 above depicts the architectural model for an enterprise 132 router. As shown in the figure, an enterprise router may have a 133 variety of interface types including enterprise-edge, enterprise- 134 interior, provider-edge, internal-virtual, as well as VET interfaces 135 used for encapsulation of inner IP packets within outer IP headers. 136 The different types of interfaces are defined, and the 137 autoconfiguration mechanisms used for each type are specified. This 138 architecture applies equally for MANET routers, in which enterprise- 139 interior interfaces correspond to the wireless multihop radio 140 interfaces typically associated with MANETs. Out of scope for this 141 document is the autoconfiguration of provider interfaces, which must 142 be coordinated in a manner specific to the service provider's 143 network. 145 The VET specification represents a functional superset of 6over4 146 [RFC2529] and ISATAP [RFC5214], and further supports additional 147 encapsulations such as IPsec [RFC4301], SEAL [I-D.templin-seal], etc. 148 As a result, VET provides a map-and-encaps architecture using 149 IP-in-IP tunneling based on both forwarding table and mapping service 150 lookups (defined herein). 152 The VET principles can be either directly or indirectly traced to the 153 deliberations of the ROAD group in January 1992, and also to still 154 earlier works including NIMROD [RFC1753], the Catenet model for 155 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 156 the high-level architectural aspects of the ROAD group deliberations 157 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 158 IPNG". 160 VET is related to the present-day activites of the IETF autoconf, 161 dhc, ipv6, manet and v6ops working groups. 163 2. Terminology 165 The mechanisms within this document build upon the fundamental 166 principles of IP-within-IP encapsulation. The terms "inner" and 167 "outer" are used throughout this document to respectively refer to 168 the innermost IP {address, protocol, header, packet, etc.} *before* 169 encapsulation, and the outermost IP {address, protocol, header, 170 packet, etc.} *after* encapsulation. VET also supports the inclusion 171 of "mid-layer" encapsulations between the inner and outer layers, 172 including IPSec [RFC4301], the Subnetwork Encapsulation and 173 Adaptation Layer (SEAL) [I-D.templin-seal], etc. 175 The terminology in the normative references apply; the following 176 terms are defined within the scope of this document: 178 subnetwork 179 the same as defined in [RFC3819]. 181 enterprise 182 the same as defined in [RFC4852]. 184 site 185 a logical and/or physical grouping of interfaces that connect a 186 topological area less than or equal to the enterprise in scope. A 187 site within an enterprise can be considered as an enterprise unto 188 itself. 190 Mobile Ad-hoc Network (MANET) 191 a connected topology of mobile or fixed routers that maintain a 192 routing structure among themselves over MANET link types 193 [I-D.clausen-manet-linktype], where a wide variety of MANETs share 194 common properties with enterprise networks. Further information 195 on MANETs can be found in [RFC2501]. 197 enterprise/site/MANET 198 throughout the remainder of this document, the term "enterprise" 199 is used to collectively refer to any of enterprise/site/MANET, 200 i.e., the VET mechanisms and operational principles apply equally 201 to enterprises, sites and MANETs. 203 enterprise router 204 an Enterprise Interior Router, Enterprise Border Router, or 205 Enterprise Border Gateway. As depicted in Figure 1, an enterprise 206 router comprises a router function, a host function, one or more 207 enterprise-interior interfaces and zero or more internal virtual, 208 enterprise-edge, provider-edge and VET interfaces. 210 Enterprise Interior Router (EIR) 211 a fixed or mobile enterprise router that forwards packets over one 212 or more sets of enterprise-interior interface; each set connected 213 to a distinct enterprise. 215 Enterprise Border Router (EBR) 216 an EIR that connects edge networks to the enterprise, and/or 217 connects multiple enterprises together. An EBR configures a 218 seperate VET interface over each set of enterprise-interior 219 interfaces that connect the EBR to each distinct enterprise, i.e., 220 an EBR may configure mulitple VET interfaces - one for each 221 distinct enterprise. All EBRs are also EIRs. 223 Enterprise Border Gateway (EBG) 224 an EBR that either directly or indirectly connects the enterprise 225 to provider networks and can delegate addresses/prefixes to other 226 EBRs within the enterprise. All EBGs are also EBRs. 228 internal-virtual interface 229 a virtual interface that is a special case of either an 230 enterprise-edge or an enterprise-interior interface. Internal- 231 virtual interfaces that are also enterprise-edge interfaces are 232 often loopback interfaces of some form. Internal-virtual 233 interfaces that are also enterprise-interior interfaces are often 234 tunnel interfaces of some form configured over another enterprise- 235 interior interface. 237 enterprise-edge interface 238 an EBR's attachment to a link (e.g., an ethernet, a wireless 239 personal area network, etc.) on an arbitrarily-complex edge 240 network that the EBR connects to an enterprise and/or to provider 241 networks. 243 provider-edge interface 244 an EBR's attachment to the Internet, or to a provider network 245 outside of the enterprise via which the Internet can be reached. 247 enterprise-interior interface 248 a EIR's attachment to a link within an enterprise. An enterprise- 249 interior interface is "neutral" in its orientation, i.e., it is 250 inherently neither an enterprise-edge nor provider-edge interface. 251 In particular, a packet may need to be forwarded over several 252 enterprise-interior interfaces before it is forwarded via either 253 an enterprise-edge or provider-edge interface. 255 Enterprise Local Address (ELA) 256 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 257 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 258 is assigned to an enterprise-interior interface and unique within 259 the enterprise. ELAs are used as identifiers for operating the 260 routing protocol and/or locators for packet forwarding within the 261 scope of the enterprise; ELAs are also used as *outer* IP 262 addresses during encapsulation. 264 Virtual Enterprise Traversal (VET) 265 an abstraction that uses IP-in-IP encapsulation to span a multi- 266 link enterprise in a single (inner) IP hop. 268 VET interface 269 an EBR's Non-Broadcast, Multiple Access interface used for Virtual 270 Enterprise Traversal. The EBR configures a VET interface over a 271 set of underlying enterprise-interior interface(s) belonging to 272 the same enterprise. When there are multiple distinct enterprises 273 (each with their own distinct set of enterprise-interior 274 interfaces), the EBR configures a separate VET interface over each 275 set of enterprise-interior interfaces, i.e., the EBR configures 276 multiple VET interfaces. 278 The VET interface encapsulates each inner IP packet in any mid- 279 layer headers plus an outer IP header then forwards it on an 280 underlying enterprise-interior interface such that the TTL/Hop 281 Limit in the inner header is not decremented as the packet 282 traverses the enterprise. The VET interface presents an automatic 283 tunneling abstraction that represents the enterprise as a single 284 IP hop. 286 The following additional acronyms are used throughout the document: 288 CGA - Cryptographically Generated Address 289 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 290 FIB - Forwarding Information Base 291 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 292 ND - Neighbor Discovery 293 PIO - Prefix Information Option 294 PRL - Potential Router List 295 RIO - Route Information Option 296 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 297 SEAL - Subnetwork Encapsulation and Adaptation Layer 298 SLAAC - IPv6 StateLess Address AutoConfiguation 300 3. Enterprise Characteristics 302 Enterprises consist of links that are connected by enterprise routers 303 as depicted in Figure 1. All enterprise routers are also Enterprise 304 Interior Routers (EIRs), and typically participate in a routing 305 protocol over enterprise-interior interfaces to discover routes that 306 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 307 Border Routers (EBRs) are EIRs that connect edge networks and/or join 308 multiple enterprises together, while Enterprise Border Gateways 309 (EBGs) are EBRs that either directly or indirectly connect 310 enterprises to provider networks. 312 An enterprise may be as simple as a small collection of enterprise 313 routers (and their attached edge networks); an enterprise may also 314 contain other enterprises and/or be a subnetwork of a larger 315 enterprise. An enterprise may further encompass a set of branch 316 offices and/or nomadic hosts connected to a home office over one or 317 several service providers, e.g., through Virtual Private Network 318 (VPN) tunnels. 320 Enterprises that comprise link types with sufficiently similar 321 properties (e.g., Layer-2 (L2) address formats, maximum transmission 322 units (MTUs), etc.) can configure a sub-IP layer routing service such 323 that IP sees the enterprise as an ordinary shared link the same as 324 for a (bridged) campus LAN. In that case, a single IP hop is 325 sufficient to traverse the enterprise without IP layer encapsulation. 327 Enterprises that comprise link types with diverse properties and/or 328 configure multiple IP subnets must also provide a routing service 329 that operates as an IP layer mechanism. In that case, multiple IP 330 hops may be necessary to traverse the enterprise such that specific 331 autoconfiguration procedures are necessary to avoid multilink subnet 332 issues [RFC4903]. In particular, we describe herein the use of IP- 333 in-IP encapsulation to span the enterprise in a single (inner) IP hop 334 in order to avoid the multilink subnet issues that arise when 335 enterprise-interior interfaces are used directly by applications. 337 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 338 both a host function and router function. The host function supports 339 global-scoped communications over any of the enterprise router's non- 340 enterprise-interior interfaces according to the weak end system model 341 [RFC1122] and also supports enterprise-local-scoped communications 342 over its enterprise-interior interfaces. The router function 343 connects the enterprise router's attached edge networks to the 344 enterprise and/or connects the enterprise to other networks including 345 the Internet (see: Figure 1). 347 In addition to other interface types, EBRs configure VET interfaces 348 that view all other EBRs in an enterprise as single-hop neighbors, 349 where the enterprise can also appear as a single IP hop within 350 another enterprise. EBRs configure a separate VET interface for each 351 distinct enterprise to which they connect, and discover a list of 352 EBRs for each VET interface that can be used for forwarding packets 353 to off-enterprise destinations. The following sections present the 354 Virtual Enterprise Traversal approach. 356 4. Autoconfiguration 358 EIRs configure enterprise-interior interfaces. An EBR is an EIR that 359 also configures enterprise-edge and VET interfaces. An EBG is an EBR 360 that also either directly or indirectly connects the enterprise to a 361 provider network. EIRs, EBRs and EBGs configure themselves for 362 operation according to the following subsections: 364 4.1. Enterprise Interior Router (EIR) Autoconfiguration 366 EIRs configure enterprise-interior interfaces and engage in routing 367 protocols over those interfaces. 369 When an EIR joins an enterprise, it first configures a unique IPv6 370 link-local address on each enterprise-interior interface that 371 requires an IPv6 link-local capability and an IPv4 link-local address 372 on each enterprise-interior interface that requires an IPv4 link- 373 local capability. IPv6 link-local address generation mechanisms that 374 provide sufficient uniqueness include Cryptographically Generated 375 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 376 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 377 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 378 provide an IPv4 link-local address generation capability. 380 Next, the EIR configures an Enterprise Local Address (ELA) of the 381 outer IP protocol version on each of its enterprise-interior 382 interfaces and engages in any routing protocols on those interfaces. 383 The EIR can configure an ELA via explicit management, DHCP 384 autoconfiguration, pseudo-random self-generation from a suitably 385 large address pool, or through an alternate autoconfiguration 386 mechanism. In some enterprise use cases (e.g., highly dynamic 387 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 388 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 389 issues. 391 EIRs that configure ELAs using DHCP may require relay support from 392 other EIRs within the enterprise; the EIR can alternatively configure 393 both a DHCP client and relay that are connected, e.g., via a pair of 394 back-to-back connected ethernet interfaces, a tun/tap interface, a 395 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 396 do not already know the ELA of a server relay requests to the 397 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 398 relays that do not already know the ELA of a server relay requests to 399 the site-scoped IPv4 multicast group address TBD (see: Section 7). 400 DHCPv4 servers that delegate ELAs join the TBD multicast group and 401 service any DHCPv4 messages received for that group. 403 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 404 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 405 generation of ELAs for IPv4 can be from a large IPv4 private address 406 range [RFC1918][I-D.fuller-240space]. When self-generation is used 407 alone, the EIR must continuously monitor the ELAs for uniqueness, 408 e.g., by monitoring the routing protocol, but care must be taken in 409 the interaction of this monitoring with existing mechanisms. 411 A combined approach using both DHCP and self-generation is also 412 possible in which the EIR first self-generates a temporary ELA used 413 only for the purpose of procuring an actual ELA taken from a disjoint 414 addressing range. The EIR then assigns the temporary ELA to an 415 enterprise-interior interface, engages in the routing protocol and 416 performs a DHCP client/relay exchange using the temporary ELA as the 417 address of the relay. When the DHCP server delegates an actual ELA, 418 the EIR abandons the temporary ELA, assigns the actual ELA to the 419 enterprise-interior interface and re-engages in the routing protocol. 421 4.2. Enterprise Border Router (EBR) Autoconfiguration 423 EBRs are EIRs that configure enterprise-edge interfaces and also 424 configure VET interfaces over sets of underlying enterprise-interior 425 interfaces. Note that an EBR may connect to multiple distinct 426 enterprises, in which case it would configure multiple VET 427 interfaces. EBRs perform the following autoconfiguration operations: 429 4.2.1. VET Interface Autoconfiguration 431 VET interface autoconfiguration entails: 1) interface initialization, 432 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 433 address autoconfiguration. These functions are specified in the 434 following sections: 436 4.2.1.1. Interface Initialization 438 EBRs configure a VET interface over a set of underlying enterprise- 439 interior interfaces belonging to the same enterprise, where the VET 440 interface presents a virtual view of all EBRs in the enterprise as 441 single hop neighbors through the use of IP-in-IP encapsulation. 443 When IPv6 and IPv4 are used as the inner/outer protocols 444 (respectively), the EBR autoconfigures an ISATAP link-local address 445 ([RFC5214], Section 6.2) on the VET interface to support packet 446 forwarding and operation of the IPv6 neighbor discovery protocol. 447 The ISATAP link-local address embeds an IPv4 ELA assigned to an 448 underlying enterprise-interior interface, and need not be checked for 449 uniqueness since the IPv4 ELA itself was already determined to be 450 unique (see: Section 4.1). Link-local address configuration for 451 other inner/outer IP protocol combinations is through administrative 452 configuration or through an unspecified alternate method. 454 After the EBR configures a VET interface, it can communicate with 455 other EBRs as single-hop neighbors from the viewpoint of the inner IP 456 protocol (where discovery of other EBRs is discussed in Section 5.4). 457 The EBR can also confirm reachability of other EBRs through Neighbor 458 Discovery (ND) and/or DHCP exchanges over the VET interface, or 459 through other means such as information conveyed in the routing 460 protocol. 462 The EBR must be able to detect and recover from the loss of VET 463 interface neighbors due to, e.g., network partitions, node failures, 464 etc. Mechanisms specified outside of this document such as 465 monitoring the routing protocol, ND beaconing/polling, DHCP renewals/ 466 leasequeries, upper layer protocol hints of forward progress, 467 bidirectional forward detection, detection of network attachment, 468 etc. can be used according to the particular deployment scenario. 470 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 471 Identification 473 After the EBR configures its VET interfaces, it next discovers a list 474 of EBGs for each distinct enterprise to which it connects. The list 475 can be discovered through information conveyed in the routing 476 protocol and/or through the Potential Router List (PRL) discovery 477 mechanisms outlined in [RFC5214], Section 8.3.2. 479 In particular, whether or not routing information is available the 480 EBR can discover the list of EBGs by resolving an identifying name 481 for the enterprise using an enterprise local name resolution service 482 (e.g., and enterprise-wide DNS service, LLMNR [RFC4759], etc.). In 483 the absence of other identifying names, the EBR can resolve either 484 the hostname "6over4" or the FQDN "6over4.example.com" (i.e., if an 485 enterprise specific suffix "example.com" is known) for multicast 486 capable enterprises. For non-multicast enterprises, the EBR can 487 instead resolve the hostname "isatap" or the FQDN 488 "isatap.example.com". 490 Identifying names along with addresses of EBGs and/or the prefixes 491 they aggregate serve as an identifier for the enterprise. 493 4.2.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) 495 When IPv6 is used as the inner protocol, the EBR sends unicast IPv6 496 Router Solicitation (RS) messages over its VET interface(s) to 497 receive Router Advertisements (RAs) from EBGs. When the EBR receives 498 an RA containing Prefix Information Options (PIOs) with the 'A' and 499 'L' bits set to 1, it autoconfigures IPv6 addresses from the prefixes 500 using SLAAC and assigns them to the VET interface. (When IPv4 is 501 used as the outer IP protocol, the addresses are autoconfigured and 502 assigned as ISATAP addresses the same as specified in [RFC5214].) 504 The use of DHCPv6 for address configuration on VET interfaces is 505 undefined. 507 4.2.2. Inner IP Address/Prefix Delegation and Maintenance 509 EBRs acquire inner IP protocol addresses and/or prefix delegations 510 through autoconfiguration exchanges via EBGs over VET interfaces, as 511 discussed in the following sections: 513 4.2.2.1. IPv4 Addresses/Prefix Delegation 515 When IPv4 is used as the inner IP protocol, the EBR acquires IPv4 516 prefixes for sub-delegation and/or assignment on its enterprise-edge 517 interfaces. This could be via an unspecified automated prefix 518 delegation exchange, explicit management, etc. 520 4.2.2.2. IPv6 Addresses/Prefix Delegation 522 If the EBR receives an RA from an EBG that contains PIOs with the 'L' 523 bit set to 0, it can use the PIOs as hints of prefixes a DHCPv6 524 server reachable via the EBG may be willing to delegate (see: 525 Section 5.4). Whether or not such hints are available, the EBR 526 (acting as a requesting router) can use DHCPv6 prefix delegation 527 [RFC3633] over the VET interface to obtain IPv6 prefixes from the 528 server (acting as a delegating router). The EBR can then use the 529 delegated prefixes for sub-delegation on enterprise-edge networks 530 and/or assignment on its enterprise-edge interfaces. 532 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 533 exchange [RFC3315]. For example, to perform the 2-message exchange 534 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 535 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 536 relay (see: Section 4.1). The relay then forwards the message over 537 the VET interface to the server via the EBG. The forwarded Solicit 538 message will elicit a Reply from the server containing IPv6 prefix 539 delegations. 541 The EBR can also propose a specific prefix to the DHCPv6 server per 542 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 543 available. The server will check the proposed prefix for consistency 544 and uniqueness, then return it in the reply to the EBR if it was able 545 to perform the delegation. The EBR can use mechanisms such as CGAs 546 [RFC3972], IPv6 privacy address [RFC4941], etc. to self-generate 547 addresses in conjunction with prefix delegation. 549 4.2.3. Portable Inner IP Addresses/Prefixes 551 Independent of any inner IP address/prefix delegations (see: 552 Section 4.2.2), an EBR can also use portable IP addresses/prefixes 553 (e.g., taken from a home network) and/or self-configured IP 554 addresses/prefixes (e.g., IPv6 Unique Local Addresses (ULAs) 556 [RFC4193][I-D.ietf-ipv6-ula-central]). Indeed, the mechanisms 557 defined herein easily support portable addresses/prefixes for 558 enterprises that choose to use them. 560 The EBR can continue to use these addresses/prefixes as it travels 561 between visited enterprise networks as long as it coordinates in some 562 fashion with a mapping agent, prefix aggregation authority, etc. 563 EBRs can also sub-delegate portable (and other self-configured) 564 prefixes to requesting routers on networks connected on their 565 enterprise-edge interfaces as well as to EBRs in other enterprises. 567 4.2.4. Enterprise-edge Interface Autoconfiguration 569 After the EBR receives inner IP address/prefix delegations (see: 570 Section 4.2.2), it assigns them on enterprise-edge interfaces only; 571 it does not assign them on provider-edge, VET, or enterprise-interior 572 interfaces (see: [RFC3633], Section 12.1). 574 Similarly, the EBR can assign portable and/or self-configured 575 addresses/prefixes (see: Section 4.2.3) on enterprise-edge 576 interfaces. 578 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 580 EBGs are EBRs that connect an enterprise to a service provider either 581 directly via provider-edge interfaces or indirectly via another 582 enterprise. EBGs configure provider-edge interfaces in a manner that 583 is specific to its provider connections. EBGs should also configure 584 a DHCP relay/server that can service prefix delegation requests from 585 EBRs. 587 EBGs must arrange to add their enterprise-interior interface 588 addresses to the PRL (see: Section 4.2.1.2), and must maintain these 589 resource records in accordance with ([RFC5214], Section 9). 591 EBGs add their enterprise-interior interface addresses to the 592 hostname "isatap" and/or the FQDN "isatap.example.com"; EBGs that 593 connect to multicast-capable enterprises additionally add these 594 addresses to the hostname "6over4" and/or the FQDN 595 "6over4.example.com". 597 4.4. VET Host Autoconfiguration 599 Non-routing hosts that cannot be attached via an EBR's enterprise- 600 edge interface (e.g., nomadic laptops that connect to a home office 601 via a Virtual Private Network (VPN)) can instead be configured for 602 operation as a simple host connected to the VET interface. Such VET 603 hosts configure one or more VET interfaces over corresponding sets of 604 enterprise-interior interfaces exactly as for EBRs, but they do not 605 configure a router function nor provide packet forwarding services 606 for nodes on enterprise-edge interfaces. VET hosts can then send 607 packets to other hosts on the VET interface, or to off-enterprise 608 destinations via a next-hop EBR. 610 5. Post-Autoconfiguration Operation 612 The following sections discuss post-autoconfiguration operations: 614 5.1. Routing Protocol Participation 616 After an EIR has been autoconfigured, it participates in any routing 617 protocols over enterprise-interior interfaces and forwards outer IP 618 packets within the enterprise as for any ordinary router. 620 EBRs can additionally engage in any inner IP routing protocols over 621 enterprise-edge, provider-edge and VET interfaces, and can use those 622 interfaces for forwarding inner IP packets to off-enterprise 623 destinations. Note that these inner IP routing protocols are 624 separate and distinct from any enterprise-interior routing protocols. 626 5.2. DHCP Prefix Delegation Maintenance 628 When DHCP prefix delegation is used, the DHCP server ensures that the 629 delegations are unique and that the EBG's router function will 630 forward IP packets over the VET interface to the EBRs to which the 631 prefixes were delegated. The EBRs can then sub-delegate inner IP 632 prefixes to requesting routers on networks connected on their 633 enterprise-edge interfaces as well as to EBRs in other enterprises. 635 The DHCP prefix delegations remain active as long as the EBR 636 continues to issue renewals over the VET interface before lease 637 lifetimes expire. The lease lifetime also keeps the delegation state 638 active even if communications between the EBR and DHCP server are 639 disrupted for a period of time (e.g., due to an enterprise network 640 partition) before being reestablished (e.g., due to an enterprise 641 network merge). 643 Since the DHCP client and relay are co-resident on the same EBR, no 644 special coordination is necessary for the EBG to maintain routing 645 information. The EBG simply retains Forwarding Information Base 646 (FIB) entries that identify the EBR as the next-hop toward the prefix 647 over the VET interface. 649 5.3. IPv6 Address Mapping Service 651 EBRs in enterprises that are managed under a cooperative 652 administrative authority should use the enterprise name service 653 (e.g., the DNS [RFC1035]) as the IPv6 address mapping service. EBRs 654 in enterprises that are managed in a distributed fashion should 655 implement their own distributed name resolution service (e.g., LLMNR 656 [RFC4759]). 658 For each IPv6 prefix reachable via one of its enterprise edge 659 interfaces, the EBR publishes the prefix's IPv6 subnet router anycast 660 address [RFC4291] in the enterprise name service using the domain 661 name suffix 'isatap.example.com' and with an IPv6 address prefix 662 formatted the same as specified in ([RFC3596], Section 2.5). For 663 example, for the IPv6 prefix 2001:DB8::/64 the EBR publishes the IPv6 664 subnet router anycast address: 665 '0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.isatap 666 .example.com' in the enterprise name service. For publications 667 within the interdomain global DNS itself, the domain name suffix 668 'isatap.net' is used instead of 'isatap.example.com'. 670 The EBR includes in the publication IPv4 addresses (e.g., in DNS A 671 records) taken from the EBR's enterprise interior interfaces, and an 672 IPv6 link-local CGA address [RFC3972] (e.g., in DNS AAAA records) 673 that other nodes can use to uniquely identify the EBR. In 674 enterprises with a cooperative administrative authority, EBRs 675 coordinate their publications with an administrator and/or by using a 676 secure automated name service update mechanism (e.g., [RFC3007]). In 677 enterprises that are managed in a distributed fashion, EBRs publish 678 their IPv6 subnet router anycast addresses through direct responses 679 to distributed name resoultion service queries. 681 In this way, the name service itself becomes an extension of the 682 enterprise's PRL. 684 5.4. IPv6 EBR/EBG Router Discovery 686 EBGs follow the router and prefix discovery procedures specified in 687 ([RFC5214], Section 8.2). They send RAs over VET interfaces for 688 which they are gateways with PIOs for SLAAC, with the 'M' flag set to 689 0 and with the 'O' flag set to indicate whether "other" DHCP services 690 are available. EBGs can also include PIOs with the 'L' bit set to 0 691 and with a prefix such as 2001:DB8::/48 as a hint of an aggregated 692 prefix from which it is willing to delegate longer prefixes. 694 VET hosts and EBRs follow the router and prefix discovery procedures 695 specified in ([RFC5214], Section 8.3). They discover EBGs by 696 resolving the names "6over4.example.com" and/or "isatap.example.com"; 697 in some multicast-capable deployments, they can also derive hints of 698 EBG reachability via 'rasadv' advertisements [RASADV]. 700 VET hosts and EBRs discover the EBRs for specific IPv6 prefixes by 701 querying the name service for the IPv6 subnet router anycast address 702 corresponding to a packet's destination address. For example, for 703 the IPv6 destination address 2001:DB8:1:2::1 the VET host/EBR queries 704 the 'isatap.example.com' domain for the IPv6 subnet router anycast 705 address represented as: 706 '0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.isat 707 ap.example.com'. The name service query will return IPv4 addresses 708 (e.g., in DNS A records) that correspond to an EBR's enterprise 709 interior interfaces and an IPv6 link-local CGA address (e.g., in DNS 710 AAAA records) that the VET host/EBR can use to verify EBR/EBG address 711 ownership. 713 VET hosts and EBRs discover default router lifetimes, default router 714 preferences and more-specific routes [RFC4191] by sending an RS over 715 the VET interface using the link-local CGA address of the EBR/EBG as 716 the destination address. The EBR/EBG returns an RA using Secure 717 Neighbor Discovery (SEND) [RFC3971], with the CGA published in the 718 name service as the IPv6 link-local source address and with an IPv4 719 address taken from its enterprise interior addresses as the IPv4 720 address in the outer header. The VET host/EBR can then use SEND to 721 verify that the RA came from the correct EBR/EBG. 723 VET hosts and EBRs must only accept PIOs, M/O flag settings and 724 default router preferences in RAs that are received from EBGs (i.e., 725 and not from ordinary EBRs). 727 5.5. Forwarding Packets to Destinations Outside of the Enterprise 729 After default and/or more-specific routes are discovered, VET hosts 730 and EBRs can forward IP packets to off-enterprise destinations by 731 consulting the FIB to determine a specific EBR/EBG as the next-hop 732 router on the VET interface. When multiple next-hop routers are 733 available, VET hosts and EBRs can use default router preferences, 734 routing protocol information, traffic engineering configurations, 735 etc. to select the best exit router. When there is no FIB 736 information available, VET hosts and EBRs can discover the next-hop 737 EBR/EBG through the mechanisms specified in Section 5.4. 739 VET interfaces encapsulate inner IP packets in any mid-layer headers 740 followed by an outer IP header according to the specific 741 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 742 next submit the encapsulated packet to the outer IP forwarding engine 743 for transmission on an underlying enterprise-interior interface. For 744 forwarding to next-hop addresses over VET interfaces that use IPv6- 745 in-IPv4 encapsulation, VET hosts and EBRs determine the outer 746 destination address through static extraction of the IPv4 address 747 embedded in the next-hop ISATAP address. For other IP-in-IP 748 encapsulations, determination of the outer destination address is 749 through administrative configuration or through an unspecified 750 alternate method. 752 When a VET host/EBR sends packets to an EBG that has more 753 comprehensive FIB information, the EBG can issue ordinary ICMP 754 redirects over the VET interface as necessary. 756 5.6. Source Address Verification 758 VET hosts and EBRs must verify that the outer IP source address of a 759 packet received on a VET interface is correct for the inner IP source 760 address using the procedures specified in ([RFC5214], Section 7.3). 762 5.7. Enterprise-Local Communications 764 When permitted by policy, end systems that configure the endpoints of 765 enterprise-local communications can avoid VET interface encapsulation 766 by directly invoking the outer IP protocol using ELAs assigned to 767 their enterprise-interior interfaces. For example, when the outer 768 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 769 communications over their enterprise-interior interfaces without 770 using the VET interface. 772 5.8. Multicast 774 In multicast-capable deployments, EIRs provide an enterprise-wide 775 multicasting service such as Simplified Multicast Forwarding (SMF) 776 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 777 that outer IP multicast messages of site- or greater scope will be 778 propagated across the enterprise. For such deployments, VET hosts 779 and EBRs can also provide an inner IP multicast/broadcast capability 780 over their VET interfaces through mapping of the inner IP multicast 781 address space to the outer IP multicast address space. 783 VET hosts and EBRs encapsulate inner IP multicast messages sent over 784 the VET interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) 785 plus an outer IP header with a site-scoped outer IP multicast address 786 as the destination. For the case of IPv6 and IPv4 as the inner/outer 787 protocols (respectively), [RFC2529] provides mappings from the IPv6 788 multicast address space to the IPv4 multicast address space. For 789 other IP-in-IP encapsulations, mappings are established through 790 administrative configuration or through an unspecified alternate 791 method. 793 For multicast-capable enterprises, use of the inner IP multicast 794 service for operating the ND protocol over the VET interface is 795 available but should be used sparingly to minimize enterprise-wide 796 flooding. 798 5.9. Service Discovery 800 VET hosts and EBRs can peform enterprise-wide service discovery using 801 a suitable name-to-address resolution service. Examples of flooding- 802 based services include the use of LLMNR [RFC4759] over the VET 803 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 804 underlying enterprise-interior interface. More scalable and 805 efficient service discovery mechanisms are for further study. 807 6. Enterprise Partitioning 809 EBGs can physically partition an enterprise by configuring multiple 810 VET interfaces over multiple distinct sets of underlying interfaces. 811 In that case, each partition (i.e., each VET interface) must 812 configure its own distinct PRL zone (e.g., 'zone1.example.com', 813 'zone2.example.com', etc.). 815 EBGs can logically partition an enterprise using a single VET 816 interface by sending RAs with PIOs containing different IPv6 subnet 817 prefixes to nodes in different logical partitions. EBGs can identify 818 partitions, e.g., by examining IPv4 prefixes, observing the 819 interfaces over which RSs are received, etc. In that case, a single 820 PRL zone can cover all partitions. 822 7. IANA Considerations 824 A Site-Local Scope IPv4 multicast group (TBD) for DHCPv4 server 825 discovery is requested. The allocation should be taken from the 826 239.255.000.000-239.255.255.255 Site-Local Scope range in the IANA 827 'multicast-addresses' registry. 829 8. Security Considerations 831 Security considerations for MANETs are found in [RFC2501]. 833 Security considerations with tunneling that apply also to VET are 834 found in [RFC2529][RFC5214]. 836 9. Related Work 838 The authors acknowledge the work done by Brian Carpenter and Cyndi 839 Jung in [RFC2529] that introduced the concept of intra-site automatic 840 tunneling. This concept was later called: "Virtual Ethernet" and 841 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 842 As for this document, these architectural principles also follow from 843 earlier works articulated by the ROAD group deliberations of 1992. 845 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 846 program. The Naval Research Lab (NRL) Information Technology 847 Division uses DHCP in their MANET research testbeds. Various 848 proposals within the IETF have suggested similar mechanisms. 850 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 851 regarding tunneling mechanisms that may subvert security through 852 Network Address Translator (NAT) traversal. 854 An automated IPv4 prefix delegation mechanism is proposed in 855 [I-D.ietf-dhc-subnet-alloc]. 857 10. Acknowledgements 859 The following individuals gave direct and/or indirect input that was 860 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 861 Bound, Thomas Clausen, Joel Halpern, Bob Hinden, Joe Macker, Thomas 862 Narten, Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, 863 Ole Troan, Michaela Vanderveen and others in the IETF AUTOCONF and 864 MANET working groups. Many others have provided guidance over the 865 course of many years. 867 11. Contributors 869 The following individuals have contributed to this document: 871 Eric Fleischman (eric.fleischman@boeing.com) 872 Thomas Henderson (thomas.r.henderson@boeing.com) 873 Steven Russert (steven.w.russert@boeing.com) 874 Seung Yi (seung.yi@boeing.com) 876 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 877 of the document. 879 12. References 880 12.1. Normative References 882 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 883 September 1981. 885 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 886 converting network protocol addresses to 48.bit Ethernet 887 address for transmission on Ethernet hardware", STD 37, 888 RFC 826, November 1982. 890 [RFC1035] Mockapetris, P., "Domain names - implementation and 891 specification", STD 13, RFC 1035, November 1987. 893 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 894 RFC 2131, March 1997. 896 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 897 (IPv6) Specification", RFC 2460, December 1998. 899 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 900 Update", RFC 3007, November 2000. 902 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 903 and M. Carney, "Dynamic Host Configuration Protocol for 904 IPv6 (DHCPv6)", RFC 3315, July 2003. 906 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 907 "DNS Extensions to Support IP Version 6", RFC 3596, 908 October 2003. 910 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 911 Host Configuration Protocol (DHCP) version 6", RFC 3633, 912 December 2003. 914 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 915 Neighbor Discovery (SEND)", RFC 3971, March 2005. 917 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 918 RFC 3972, March 2005. 920 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 921 More-Specific Routes", RFC 4191, November 2005. 923 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 924 Architecture", RFC 4291, February 2006. 926 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 927 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 928 September 2007. 930 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 931 Address Autoconfiguration", RFC 4862, September 2007. 933 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 934 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 935 March 2008. 937 12.2. Informative References 939 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 940 Switching Networks", May 1974. 942 [I-D.cheshire-dnsext-multicastdns] 943 Cheshire, S. and M. Krochmal, "Multicast DNS", 944 draft-cheshire-dnsext-multicastdns-07 (work in progress), 945 September 2008. 947 [I-D.clausen-manet-linktype] 948 Clausen, T., "The MANET Link Type", 949 draft-clausen-manet-linktype-00 (work in progress), 950 October 2008. 952 [I-D.fuller-240space] 953 Fuller, V., "Reclassifying 240/4 as usable unicast address 954 space", draft-fuller-240space-02 (work in progress), 955 March 2008. 957 [I-D.ietf-autoconf-manetarch] 958 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 959 Network Architecture", draft-ietf-autoconf-manetarch-07 960 (work in progress), November 2007. 962 [I-D.ietf-dhc-subnet-alloc] 963 Johnson, R., "Subnet Allocation Option", 964 draft-ietf-dhc-subnet-alloc-07 (work in progress), 965 July 2008. 967 [I-D.ietf-ipv6-ula-central] 968 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 969 Addresses", draft-ietf-ipv6-ula-central-02 (work in 970 progress), June 2007. 972 [I-D.ietf-manet-smf] 973 Macker, J. and S. Team, "Simplified Multicast Forwarding 974 for MANET", draft-ietf-manet-smf-08 (work in progress), 975 November 2008. 977 [I-D.ietf-v6ops-tunnel-security-concerns] 978 Hoagland, J., Krishnan, S., and D. Thaler, "Security 979 Concerns With IP Tunneling", 980 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 981 progress), October 2008. 983 [I-D.templin-seal] 984 Templin, F., "The Subnetwork Encapsulation and Adaptation 985 Layer (SEAL)", draft-templin-seal-23 (work in progress), 986 August 2008. 988 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 989 July 1978. 991 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 992 Protocol Specification", October 2008. 994 [RFC1122] Braden, R., "Requirements for Internet Hosts - 995 Communication Layers", STD 3, RFC 1122, October 1989. 997 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 998 Routing and Addressing Architecture", RFC 1753, 999 December 1994. 1001 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1002 E. Lear, "Address Allocation for Private Internets", 1003 BCP 5, RFC 1918, February 1996. 1005 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1006 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1008 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1009 (MANET): Routing Protocol Performance Issues and 1010 Evaluation Considerations", RFC 2501, January 1999. 1012 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1013 Domains without Explicit Tunnels", RFC 2529, March 1999. 1015 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1016 February 2000. 1018 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1019 via IPv4 Clouds", RFC 3056, February 2001. 1021 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1022 RFC 3753, June 2004. 1024 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1025 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1026 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1027 RFC 3819, July 2004. 1029 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1030 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1031 May 2005. 1033 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1034 Addresses", RFC 4193, October 2005. 1036 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1037 Internet Protocol", RFC 4301, December 2005. 1039 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1040 Indicator Parameter for the "tel" URI", RFC 4759, 1041 December 2006. 1043 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1044 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1045 Focus", RFC 4852, April 2007. 1047 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1048 June 2007. 1050 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1051 Extensions for Stateless Address Autoconfiguration in 1052 IPv6", RFC 4941, September 2007. 1054 Appendix A. Duplicate Address Detection (DAD) Considerations 1056 A-priori uniqueness determination (also known as "pre-service DAD") 1057 for an ELA assigned on an enterprise-interior interface (such as 1058 specified in [RFC4862]) would require either flooding the entire 1059 enterprise or somehow discovering a link in the enterprise on which a 1060 node that configures a duplicate address is attached and performing a 1061 localized DAD exchange on that link. But, the control message 1062 overhead for such an enterprise-wide DAD would be substantial and 1063 prone to false-negatives due to packet loss and intermittent 1064 connectivity. An alternative to pre-service DAD is to autoconfigure 1065 pseudo-random ELAs on enterprise-interior interfaces and employ a 1066 passive in-service DAD (e.g., one that monitors routing protocol 1067 messages for duplicate assignments). 1069 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1070 CGAs, IPv6 privacy addresses, etc. with very small probability of 1071 collision. Pseudo-random IPv4 ELAs can be generated through random 1072 assignment from a suitably large IPv4 prefix space, e.g., the soon- 1073 to-be-reclassified 240/4 space [I-D.fuller-240space]. 1075 Consistent operational practices can assure uniqueness for EBG- 1076 aggregated addresses/prefixes, while statistical properties for 1077 pseudo-random address self-generation can assure uniqueness for the 1078 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 1079 ELA delegation authority should be used when available, while a 1080 passive in-service DAD mechanism should be used to detect ELA 1081 duplications when there is no ELA delegation authority. 1083 Appendix B. Change Log 1085 (Note to RFC editor - this section to be removed before publication 1086 as an RFC.) 1088 Changes from -20 to 21: 1090 o Enterprise partitioning. 1092 o Mapping and name service management. 1094 Changes from -18 to 20: 1096 o Added support for simple hosts. 1098 o Added EBG name service maintenace procedures 1100 o Added router and prefix maintenace procedures 1102 Changes from -17 to 18: 1104 o adjusted section headings to group autoconf operations under EIR/ 1105 EBR/EBG. 1107 o clarified M/O bits 1109 o clarified EBG roles 1111 Changes from -15 to 17: 1113 o title change to "Virtual Enterprise Traversal (VET)". 1115 o changed document focus from MANET-centric to the much-broader 1116 Enterprise-centric, where "Enterprise" is understood to also cover 1117 a wide range of MANET types. 1119 Changes from -14 to 15: 1121 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1123 o Address review comments 1125 Changes from -12 to 14: 1127 o title change to "The MANET Virtual Ethernet Abstraction". 1129 o Minor section rearrangement. 1131 o Clartifications on portable and self-configured prefixes. 1133 o Clarifications on DHCPv6 prefix delegation procedures. 1135 Changes from -11 to 12: 1137 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1139 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1140 delegation mechanism. 1142 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1144 o fixed editorials based on comments received. 1146 Changes from -10 to 11: 1148 o removed the transparent/opaque VET portal abstractions. 1150 o removed routing header as an option for MANET exit router 1151 selection. 1153 o included IPv6 SLAAC as an endorsed address configuration mechanism 1154 for the VET interface. 1156 Changes from -08 to -09: 1158 o Introduced the term "VET". 1160 o Changed address delegation language to speak of "MNBR-aggregated" 1161 instead of global/local. 1163 o Updated figures 1-3. 1165 o Explained why a MANET interface is "neutral". 1167 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1168 DHCPv4 servers; not relays. 1170 Changes from -07 to -08: 1172 o changed terms "unenhanced" and "enhanced" to "transparent" and 1173 "opaque". 1175 o revised MANET Router diagram. 1177 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1178 interface. 1180 o changed abbreviations to "MNR" and "MNBR". 1182 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1184 o rearranged Section 3.1. 1186 o various minor text cleanups 1188 Changes from -06 to -07: 1190 o added MANET Router diagram. 1192 o added new references 1194 o various minor text cleanups 1196 Changed from -05 to -06: 1198 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1200 o minor changes to preserve generality 1202 Changed from -04 to -05: 1204 o introduced conceptual "virtual ethernet" model. 1206 o support "raw" and "cooked" modes as equivalent access methods on 1207 the virutal ethernet. 1209 Changed from -03 to -04: 1211 o introduced conceptual "imaginary shared link" as a representation 1212 for a MANET. 1214 o discussion of autonomous system and site abstractions for MANETs 1216 o discussion of autoconfiguration of CGAs 1218 o new appendix on IPv6 StateLess Address AutoConfiguration 1220 Changes from -02 to -03: 1222 o updated terminology based on RFC2461 "asymmetric reachability" 1223 link type; IETF67 MANET Autoconf wg discussions. 1225 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1226 Address Detection 1228 o relaxed DHCP server deployment considerations allow DHCP servers 1229 within the MANET itself 1231 Changes from -01 to -02: 1233 o minor updates for consistency with recent developments 1235 Changes from -00 to -01: 1237 o new text on DHCPv6 prefix delegation and multilink subnet 1238 considerations. 1240 o various editorial changes 1242 Author's Address 1244 Fred L. Templin (editor) 1245 Boeing Phantom Works 1246 P.O. Box 3707 MC 7L-49 1247 Seattle, WA 98124 1248 USA 1250 Email: fltemplin@acm.org 1252 Full Copyright Statement 1254 Copyright (C) The IETF Trust (2008). 1256 This document is subject to the rights, licenses and restrictions 1257 contained in BCP 78, and except as set forth therein, the authors 1258 retain all their rights. 1260 This document and the information contained herein are provided on an 1261 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1262 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1263 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1264 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1265 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1266 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1268 Intellectual Property 1270 The IETF takes no position regarding the validity or scope of any 1271 Intellectual Property Rights or other rights that might be claimed to 1272 pertain to the implementation or use of the technology described in 1273 this document or the extent to which any license under such rights 1274 might or might not be available; nor does it represent that it has 1275 made any independent effort to identify any such rights. Information 1276 on the procedures with respect to rights in RFC documents can be 1277 found in BCP 78 and BCP 79. 1279 Copies of IPR disclosures made to the IETF Secretariat and any 1280 assurances of licenses to be made available, or the result of an 1281 attempt made to obtain a general license or permission for the use of 1282 such proprietary rights by implementers or users of this 1283 specification can be obtained from the IETF on-line IPR repository at 1284 http://www.ietf.org/ipr. 1286 The IETF invites any interested party to bring to its attention any 1287 copyrights, patents or patent applications, or other proprietary 1288 rights that may cover technology that may be required to implement 1289 this standard. Please address the information to the IETF at 1290 ietf-ipr@ietf.org.