idnits 2.17.1 draft-templin-autoconf-dhcp-22.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 1324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1348. 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 726: '... MUST NOT accept them from ordinary ...' 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 (December 5, 2008) is 5619 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 158, but not defined == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1076, 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: 5 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 December 5, 2008 5 Expires: June 8, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-22.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 June 8, 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 Prefix Mapping . . . . . . . . . . . . . . . . . . . 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. Securing VET with SEAL . . . . . . . . . . . . . . . . . . . . 18 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 76 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 79 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 80 Appendix A. Duplicate Address Detection (DAD) Considerations . . 24 81 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 83 Intellectual Property and Copyright Statements . . . . . . . . . . 29 85 1. Introduction 87 Enterprise networks [RFC4852] connect routers over various link types 88 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 89 (MANETs) [RFC2501] can be considered as a challenging example of an 90 enterprise network, in that their topologies may change dynamically 91 over time and that they may employ little/no active management by a 92 centralized network administrative authority. These specialized 93 characteristics for MANETs require careful consideration, but the 94 same principles apply equally to other enterprise network scenarios. 96 This document specifies a Virtual Enterprise Traversal (VET) 97 abstraction for autoconfiguration and runtime operation of nodes in 98 enterprises, where addresses of different scopes may be assigned on 99 various types of interfaces with diverse properties. Both IPv4 100 [RFC0791] and IPv6 [RFC2460] are discussed within this context. The 101 use of standard DHCP [RFC2131][RFC3315] and neighbor discovery 102 [RFC0826][RFC4861] mechanisms is assumed unless otherwise specified. 104 Provider-edge Interfaces 105 x x x 106 | | | 107 +--------------------+---+--------+----------+ E 108 | | | | | n 109 | I | | .... | | t 110 | n +---+---+--------+---+ | e 111 | t | +--------+ /| | r 112 | e I x----+ | Host | I /*+------+--< p I 113 | r n | |Function| n|**| | r n 114 | n t | +--------+ t|**| | i t 115 | a e x----+ V e|**+------+--< s e 116 | l r . | E r|**| . | e r 117 | f . | T f|**| . | f 118 | V a . | +--------+ a|**| . | I a 119 | i c . | | Router | c|**| . | n c 120 | r e x----+ |Function| e \*+------+--< t e 121 | t s | +--------+ \| | e s 122 | u +---+---+--------+---+ | r 123 | a | | .... | | i 124 | l | | | | o 125 +--------------------+---+--------+----------+ r 126 | | | 127 x x x 128 Enterprise-edge Interfaces 130 Figure 1: Enterprise Router Architecture 132 Figure 1 above depicts the architectural model for an enterprise 133 router. As shown in the figure, an enterprise router may have a 134 variety of interface types including enterprise-edge, enterprise- 135 interior, provider-edge, internal-virtual, as well as VET interfaces 136 used for encapsulation of inner IP packets within outer IP headers. 137 The different types of interfaces are defined, and the 138 autoconfiguration mechanisms used for each type are specified. This 139 architecture applies equally for MANET routers, in which enterprise- 140 interior interfaces correspond to the wireless multihop radio 141 interfaces typically associated with MANETs. Out of scope for this 142 document is the autoconfiguration of provider interfaces, which must 143 be coordinated in a manner specific to the service provider's 144 network. 146 The VET specification represents a functional superset of 6over4 147 [RFC2529] and ISATAP [RFC5214], and further supports additional 148 encapsulations such as IPsec [RFC4301], SEAL [I-D.templin-seal], etc. 149 As a result, VET provides a map-and-encaps architecture using 150 IP-in-IP tunneling based on both forwarding table and mapping service 151 lookups (defined herein). 153 The VET principles can be either directly or indirectly traced to the 154 deliberations of the ROAD group in January 1992, and also to still 155 earlier works including NIMROD [RFC1753], the Catenet model for 156 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 157 the high-level architectural aspects of the ROAD group deliberations 158 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 159 IPNG". 161 VET is related to the present-day activites of the IETF autoconf, 162 dhc, ipv6, manet and v6ops working groups. 164 2. Terminology 166 The mechanisms within this document build upon the fundamental 167 principles of IP-within-IP encapsulation. The terms "inner" and 168 "outer" are used throughout this document to respectively refer to 169 the innermost IP {address, protocol, header, packet, etc.} *before* 170 encapsulation, and the outermost IP {address, protocol, header, 171 packet, etc.} *after* encapsulation. VET also supports the inclusion 172 of "mid-layer" encapsulations between the inner and outer layers, 173 including IPSec [RFC4301], the Subnetwork Encapsulation and 174 Adaptation Layer (SEAL) [I-D.templin-seal], etc. 176 The terminology in the normative references apply; the following 177 terms are defined within the scope of this document: 179 subnetwork 180 the same as defined in [RFC3819]. 182 enterprise 183 the same as defined in [RFC4852]. 185 site 186 a logical and/or physical grouping of interfaces that connect a 187 topological area less than or equal to the enterprise in scope. A 188 site within an enterprise can be considered as an enterprise unto 189 itself. 191 Mobile Ad-hoc Network (MANET) 192 a connected topology of mobile or fixed routers that maintain a 193 routing structure among themselves over MANET link types 194 [I-D.clausen-manet-linktype], where a wide variety of MANETs share 195 common properties with enterprise networks. Further information 196 on MANETs can be found in [RFC2501]. 198 enterprise/site/MANET 199 throughout the remainder of this document, the term "enterprise" 200 is used to collectively refer to any of enterprise/site/MANET, 201 i.e., the VET mechanisms and operational principles apply equally 202 to enterprises, sites and MANETs. 204 enterprise router 205 an Enterprise Interior Router, Enterprise Border Router, or 206 Enterprise Border Gateway. As depicted in Figure 1, an enterprise 207 router comprises a router function, a host function, one or more 208 enterprise-interior interfaces and zero or more internal virtual, 209 enterprise-edge, provider-edge and VET interfaces. 211 Enterprise Interior Router (EIR) 212 a fixed or mobile enterprise router that forwards packets over one 213 or more sets of enterprise-interior interface; each set connected 214 to a distinct enterprise. 216 Enterprise Border Router (EBR) 217 an EIR that connects edge networks to the enterprise, and/or 218 connects multiple enterprises together. An EBR configures a 219 seperate VET interface over each set of enterprise-interior 220 interfaces that connect the EBR to each distinct enterprise, i.e., 221 an EBR may configure mulitple VET interfaces - one for each 222 distinct enterprise. All EBRs are also EIRs. 224 Enterprise Border Gateway (EBG) 225 an EBR that either directly or indirectly connects the enterprise 226 to provider networks and can delegate addresses/prefixes to other 227 EBRs within the enterprise. All EBGs are also EBRs. 229 internal-virtual interface 230 a virtual interface that is a special case of either an 231 enterprise-edge or an enterprise-interior interface. Internal- 232 virtual interfaces that are also enterprise-edge interfaces are 233 often loopback interfaces of some form. Internal-virtual 234 interfaces that are also enterprise-interior interfaces are often 235 tunnel interfaces of some form configured over another enterprise- 236 interior interface. 238 enterprise-edge interface 239 an EBR's attachment to a link (e.g., an ethernet, a wireless 240 personal area network, etc.) on an arbitrarily-complex edge 241 network that the EBR connects to an enterprise and/or to provider 242 networks. 244 provider-edge interface 245 an EBR's attachment to the Internet, or to a provider network 246 outside of the enterprise via which the Internet can be reached. 248 enterprise-interior interface 249 a EIR's attachment to a link within an enterprise. An enterprise- 250 interior interface is "neutral" in its orientation, i.e., it is 251 inherently neither an enterprise-edge nor provider-edge interface. 252 In particular, a packet may need to be forwarded over several 253 enterprise-interior interfaces before it is forwarded via either 254 an enterprise-edge or provider-edge interface. 256 Enterprise Local Address (ELA) 257 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 258 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 259 is assigned to an enterprise-interior interface and unique within 260 the enterprise. ELAs are used as identifiers for operating the 261 routing protocol and/or locators for packet forwarding within the 262 scope of the enterprise; ELAs are also used as *outer* IP 263 addresses during encapsulation. 265 Virtual Enterprise Traversal (VET) 266 an abstraction that uses IP-in-IP encapsulation to span a multi- 267 link enterprise in a single (inner) IP hop. 269 VET interface 270 an EBR's Non-Broadcast, Multiple Access interface used for Virtual 271 Enterprise Traversal. The EBR configures a VET interface over a 272 set of underlying enterprise-interior interface(s) belonging to 273 the same enterprise. When there are multiple distinct enterprises 274 (each with their own distinct set of enterprise-interior 275 interfaces), the EBR configures a separate VET interface over each 276 set of enterprise-interior interfaces, i.e., the EBR configures 277 multiple VET interfaces. 279 The VET interface encapsulates each inner IP packet in any mid- 280 layer headers plus an outer IP header then forwards it on an 281 underlying enterprise-interior interface such that the TTL/Hop 282 Limit in the inner header is not decremented as the packet 283 traverses the enterprise. The VET interface presents an automatic 284 tunneling abstraction that represents the enterprise as a single 285 IP hop. 287 The following additional acronyms are used throughout the document: 289 CGA - Cryptographically Generated Address 290 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 291 FIB - Forwarding Information Base 292 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 293 ND - Neighbor Discovery 294 PIO - Prefix Information Option 295 PRL - Potential Router List 296 RIO - Route Information Option 297 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 298 SEAL - Subnetwork Encapsulation and Adaptation Layer 299 SLAAC - IPv6 StateLess Address AutoConfiguation 301 3. Enterprise Characteristics 303 Enterprises consist of links that are connected by enterprise routers 304 as depicted in Figure 1. All enterprise routers are also Enterprise 305 Interior Routers (EIRs), and typically participate in a routing 306 protocol over enterprise-interior interfaces to discover routes that 307 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 308 Border Routers (EBRs) are EIRs that connect edge networks and/or join 309 multiple enterprises together, while Enterprise Border Gateways 310 (EBGs) are EBRs that either directly or indirectly connect 311 enterprises to provider networks. 313 An enterprise may be as simple as a small collection of enterprise 314 routers (and their attached edge networks); an enterprise may also 315 contain other enterprises and/or be a subnetwork of a larger 316 enterprise. An enterprise may further encompass a set of branch 317 offices and/or nomadic hosts connected to a home office over one or 318 several service providers, e.g., through Virtual Private Network 319 (VPN) tunnels. 321 Enterprises that comprise link types with sufficiently similar 322 properties (e.g., Layer-2 (L2) address formats, maximum transmission 323 units (MTUs), etc.) can configure a sub-IP layer routing service such 324 that IP sees the enterprise as an ordinary shared link the same as 325 for a (bridged) campus LAN. In that case, a single IP hop is 326 sufficient to traverse the enterprise without IP layer encapsulation. 328 Enterprises that comprise link types with diverse properties and/or 329 configure multiple IP subnets must also provide a routing service 330 that operates as an IP layer mechanism. In that case, multiple IP 331 hops may be necessary to traverse the enterprise such that specific 332 autoconfiguration procedures are necessary to avoid multilink subnet 333 issues [RFC4903]. In particular, we describe herein the use of IP- 334 in-IP encapsulation to span the enterprise in a single (inner) IP hop 335 in order to avoid the multilink subnet issues that arise when 336 enterprise-interior interfaces are used directly by applications. 338 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 339 both a host function and router function. The host function supports 340 global-scoped communications over any of the enterprise router's non- 341 enterprise-interior interfaces according to the weak end system model 342 [RFC1122] and also supports enterprise-local-scoped communications 343 over its enterprise-interior interfaces. The router function 344 connects the enterprise router's attached edge networks to the 345 enterprise and/or connects the enterprise to other networks including 346 the Internet (see: Figure 1). 348 In addition to other interface types, EBRs configure VET interfaces 349 that view all other EBRs in an enterprise as single-hop neighbors, 350 where the enterprise can also appear as a single IP hop within 351 another enterprise. EBRs configure a separate VET interface for each 352 distinct enterprise to which they connect, and discover a list of 353 EBRs for each VET interface that can be used for forwarding packets 354 to off-enterprise destinations. The following sections present the 355 Virtual Enterprise Traversal approach. 357 4. Autoconfiguration 359 EIRs configure enterprise-interior interfaces. An EBR is an EIR that 360 also configures enterprise-edge and VET interfaces. An EBG is an EBR 361 that also either directly or indirectly connects the enterprise to a 362 provider network. EIRs, EBRs and EBGs configure themselves for 363 operation according to the following subsections: 365 4.1. Enterprise Interior Router (EIR) Autoconfiguration 367 EIRs configure enterprise-interior interfaces and engage in routing 368 protocols over those interfaces. 370 When an EIR joins an enterprise, it first configures a unique IPv6 371 link-local address on each enterprise-interior interface that 372 requires an IPv6 link-local capability and an IPv4 link-local address 373 on each enterprise-interior interface that requires an IPv4 link- 374 local capability. IPv6 link-local address generation mechanisms that 375 provide sufficient uniqueness include Cryptographically Generated 376 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 377 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 378 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 379 provide an IPv4 link-local address generation capability. 381 Next, the EIR configures an Enterprise Local Address (ELA) of the 382 outer IP protocol version on each of its enterprise-interior 383 interfaces and engages in any routing protocols on those interfaces. 384 The EIR can configure an ELA via explicit management, DHCP 385 autoconfiguration, pseudo-random self-generation from a suitably 386 large address pool, or through an alternate autoconfiguration 387 mechanism. In some enterprise use cases (e.g., highly dynamic 388 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 389 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 390 issues. 392 EIRs that configure ELAs using DHCP may require relay support from 393 other EIRs within the enterprise; the EIR can alternatively configure 394 both a DHCP client and relay that are connected, e.g., via a pair of 395 back-to-back connected ethernet interfaces, a tun/tap interface, a 396 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 397 do not already know the ELA of a server relay requests to the 398 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 399 relays that do not already know the ELA of a server relay requests to 400 the site-scoped IPv4 multicast group address TBD (see: Section 8). 401 DHCPv4 servers that delegate ELAs join the TBD multicast group and 402 service any DHCPv4 messages received for that group. 404 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 405 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 406 generation of ELAs for IPv4 can be from a large IPv4 private address 407 range (e.g., [RFC1918]). When self-generation is used alone, the EIR 408 must continuously monitor the ELAs for uniqueness, e.g., by 409 monitoring the routing protocol, but care must be taken in the 410 interaction of this monitoring with existing mechanisms. 412 A combined approach using both DHCP and self-generation is also 413 possible in which the EIR first self-generates a temporary ELA used 414 only for the purpose of procuring an actual ELA taken from a disjoint 415 addressing range. The EIR then assigns the temporary ELA to an 416 enterprise-interior interface, engages in the routing protocol and 417 performs a DHCP client/relay exchange using the temporary ELA as the 418 address of the relay. When the DHCP server delegates an actual ELA, 419 the EIR abandons the temporary ELA, assigns the actual ELA to the 420 enterprise-interior interface and re-engages in the routing protocol. 422 4.2. Enterprise Border Router (EBR) Autoconfiguration 424 EBRs are EIRs that configure enterprise-edge interfaces and also 425 configure VET interfaces over sets of underlying enterprise-interior 426 interfaces. Note that an EBR may connect to multiple distinct 427 enterprises, in which case it would configure multiple VET 428 interfaces. EBRs perform the following autoconfiguration operations: 430 4.2.1. VET Interface Autoconfiguration 432 VET interface autoconfiguration entails: 1) interface initialization, 433 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 434 address autoconfiguration. These functions are specified in the 435 following sections: 437 4.2.1.1. Interface Initialization 439 EBRs configure a VET interface over a set of underlying enterprise- 440 interior interfaces belonging to the same enterprise, where the VET 441 interface presents a virtual view of all EBRs in the enterprise as 442 single hop neighbors through the use of IP-in-IP encapsulation. 444 When IPv6 and IPv4 are used as the inner/outer protocols 445 (respectively), the EBR autoconfigures an ISATAP link-local address 446 ([RFC5214], Section 6.2) on the VET interface to support packet 447 forwarding and operation of the IPv6 neighbor discovery protocol. 448 The ISATAP link-local address embeds an IPv4 ELA assigned to an 449 underlying enterprise-interior interface, and need not be checked for 450 uniqueness since the IPv4 ELA itself was already determined to be 451 unique (see: Section 4.1). Link-local address configuration for 452 other inner/outer IP protocol combinations is through administrative 453 configuration or through an unspecified alternate method. 455 After the EBR configures a VET interface, it can communicate with 456 other EBRs as single-hop neighbors from the viewpoint of the inner IP 457 protocol (where discovery of other EBRs is discussed in Section 5.4). 458 The EBR can also confirm reachability of other EBRs through Neighbor 459 Discovery (ND) and/or DHCP exchanges over the VET interface, or 460 through other means such as information conveyed in the routing 461 protocol. 463 The EBR must be able to detect and recover from the loss of VET 464 interface neighbors due to, e.g., network partitions, node failures, 465 etc. Mechanisms specified outside of this document such as 466 monitoring the routing protocol, ND beaconing/polling, DHCP renewals/ 467 leasequeries, upper layer protocol hints of forward progress, 468 bidirectional forward detection, detection of network attachment, 469 etc. can be used according to the particular deployment scenario. 471 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 472 Identification 474 After the EBR configures its VET interfaces, it next discovers a list 475 of EBGs for each distinct enterprise to which it connects. The list 476 can be discovered through information conveyed in the routing 477 protocol and/or through the Potential Router List (PRL) discovery 478 mechanisms outlined in [RFC5214], Section 8.3.2. 480 In particular, whether or not routing information is available the 481 EBR can discover the list of EBGs by resolving an identifying name 482 for the enterprise using an enterprise local name resolution service 483 (e.g., and enterprise-wide DNS service, LLMNR [RFC4759], etc.). In 484 the absence of other identifying names, the EBR can resolve either 485 the hostname "6over4" or the FQDN "6over4.example.com" (i.e., if an 486 enterprise specific suffix "example.com" is known) for multicast 487 capable enterprises. For non-multicast enterprises, the EBR can 488 instead resolve the hostname "isatap" or the FQDN 489 "isatap.example.com". 491 Identifying names along with addresses of EBGs and/or the prefixes 492 they aggregate serve as an identifier for the enterprise. 494 4.2.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) 496 When IPv6 is used as the inner protocol, the EBR sends unicast IPv6 497 Router Solicitation (RS) messages over its VET interface(s) to 498 receive Router Advertisements (RAs) from EBGs. When the EBR receives 499 an RA containing Prefix Information Options (PIOs) with the 'A' and 500 'L' bits set to 1, it autoconfigures IPv6 addresses from the prefixes 501 using SLAAC and assigns them to the VET interface. (When IPv4 is 502 used as the outer IP protocol, the addresses are autoconfigured and 503 assigned as ISATAP addresses the same as specified in [RFC5214].) 505 The use of DHCPv6 for address configuration on VET interfaces is 506 undefined. 508 4.2.2. Inner IP Address/Prefix Delegation and Maintenance 510 EBRs acquire inner IP protocol addresses and/or prefix delegations 511 through autoconfiguration exchanges via EBGs over VET interfaces, as 512 discussed in the following sections: 514 4.2.2.1. IPv4 Addresses/Prefix Delegation 516 When IPv4 is used as the inner IP protocol, the EBR acquires IPv4 517 prefixes for sub-delegation and/or assignment on its enterprise-edge 518 interfaces. This could be via an unspecified automated prefix 519 delegation exchange, explicit management, etc. 521 4.2.2.2. IPv6 Addresses/Prefix Delegation 523 If the EBR receives an RA from an EBG that contains PIOs with the 'L' 524 bit set to 0, it can use the PIOs as hints of prefixes a DHCPv6 525 server reachable via the EBG may be willing to delegate (see: 526 Section 5.4). Whether or not such hints are available, the EBR 527 (acting as a requesting router) can use DHCPv6 prefix delegation 528 [RFC3633] over the VET interface to obtain IPv6 prefixes from the 529 server (acting as a delegating router). The EBR can then use the 530 delegated prefixes for sub-delegation on enterprise-edge networks 531 and/or assignment on its enterprise-edge interfaces. 533 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 534 exchange [RFC3315]. For example, to perform the 2-message exchange 535 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 536 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 537 relay (see: Section 4.1). The relay then forwards the message over 538 the VET interface to the server via the EBG. The forwarded Solicit 539 message will elicit a Reply from the server containing IPv6 prefix 540 delegations. 542 The EBR can also propose a specific prefix to the DHCPv6 server per 543 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 544 available. The server will check the proposed prefix for consistency 545 and uniqueness, then return it in the reply to the EBR if it was able 546 to perform the delegation. The EBR can use mechanisms such as CGAs 547 [RFC3972], IPv6 privacy address [RFC4941], etc. to self-generate 548 addresses in conjunction with prefix delegation. 550 4.2.3. Portable Inner IP Addresses/Prefixes 552 Independent of any inner IP address/prefix delegations (see: 553 Section 4.2.2), an EBR can also use portable IP addresses/prefixes 554 (e.g., taken from a home network) and/or self-configured IP 555 addresses/prefixes (e.g., IPv6 Unique Local Addresses (ULAs) 557 [RFC4193][I-D.ietf-ipv6-ula-central]). Indeed, the mechanisms 558 defined herein easily support portable addresses/prefixes for 559 enterprises that choose to use them. 561 The EBR can continue to use these addresses/prefixes as it travels 562 between visited enterprise networks as long as it coordinates in some 563 fashion with a mapping agent, prefix aggregation authority, etc. 564 EBRs can also sub-delegate portable (and other self-configured) 565 prefixes to requesting routers on networks connected on their 566 enterprise-edge interfaces as well as to EBRs in other enterprises. 568 4.2.4. Enterprise-edge Interface Autoconfiguration 570 After the EBR receives inner IP address/prefix delegations (see: 571 Section 4.2.2), it assigns them on enterprise-edge interfaces only; 572 it does not assign them on provider-edge, VET, or enterprise-interior 573 interfaces (see: [RFC3633], Section 12.1). 575 Similarly, the EBR can assign portable and/or self-configured 576 addresses/prefixes (see: Section 4.2.3) on enterprise-edge 577 interfaces. 579 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 581 EBGs are EBRs that connect an enterprise to a service provider either 582 directly via provider-edge interfaces or indirectly via another 583 enterprise. EBGs configure provider-edge interfaces in a manner that 584 is specific to its provider connections. EBGs should also configure 585 a DHCP relay/server that can service prefix delegation requests from 586 EBRs. 588 EBGs must arrange to add their enterprise-interior interface 589 addresses to the PRL (see: Section 4.2.1.2), and must maintain these 590 resource records in accordance with ([RFC5214], Section 9). 592 EBGs add their enterprise-interior interface addresses to the 593 hostname "isatap" and/or the FQDN "isatap.example.com"; EBGs that 594 connect to multicast-capable enterprises additionally add these 595 addresses to the hostname "6over4" and/or the FQDN 596 "6over4.example.com". 598 4.4. VET Host Autoconfiguration 600 Non-routing hosts that cannot be attached via an EBR's enterprise- 601 edge interface (e.g., nomadic laptops that connect to a home office 602 via a Virtual Private Network (VPN)) can instead be configured for 603 operation as a simple host connected to the VET interface. Such VET 604 hosts configure one or more VET interfaces over corresponding sets of 605 enterprise-interior interfaces exactly as for EBRs, but they do not 606 configure a router function nor provide packet forwarding services 607 for nodes on enterprise-edge interfaces. VET hosts can then send 608 packets to other hosts on the VET interface, or to off-enterprise 609 destinations via a next-hop EBR. 611 5. Post-Autoconfiguration Operation 613 The following sections discuss post-autoconfiguration operations: 615 5.1. Routing Protocol Participation 617 After an EIR has been autoconfigured, it participates in any routing 618 protocols over enterprise-interior interfaces and forwards outer IP 619 packets within the enterprise as for any ordinary router. 621 EBRs can additionally engage in any inner IP routing protocols over 622 enterprise-edge, provider-edge and VET interfaces, and can use those 623 interfaces for forwarding inner IP packets to off-enterprise 624 destinations. Note that these inner IP routing protocols are 625 separate and distinct from any enterprise-interior routing protocols. 627 5.2. DHCP Prefix Delegation Maintenance 629 When DHCP prefix delegation is used, the DHCP server ensures that the 630 delegations are unique and that the EBG's router function will 631 forward IP packets over the VET interface to the EBRs to which the 632 prefixes were delegated. The EBRs can then sub-delegate inner IP 633 prefixes to requesting routers on networks connected on their 634 enterprise-edge interfaces as well as to EBRs in other enterprises. 636 The DHCP prefix delegations remain active as long as the EBR 637 continues to issue renewals over the VET interface before lease 638 lifetimes expire. The lease lifetime also keeps the delegation state 639 active even if communications between the EBR and DHCP server are 640 disrupted for a period of time (e.g., due to an enterprise network 641 partition) before being reestablished (e.g., due to an enterprise 642 network merge). 644 Since the DHCP client and relay are co-resident on the same EBR, no 645 special coordination is necessary for the EBG to maintain routing 646 information. The EBG simply retains Forwarding Information Base 647 (FIB) entries that identify the EBR as the next-hop toward the prefix 648 over the VET interface. 650 5.3. IPv6 Prefix Mapping 652 EBRs in enterprises that are managed under a cooperative 653 administrative authority should use the enterprise name service 654 (e.g., the DNS [RFC1035]) as the IPv6 prefix mapping service. EBRs 655 in enterprises that are managed in a distributed fashion should 656 implement their own distributed name resolution service (e.g., LLMNR 657 [RFC4759]). 659 For each /64 IPv6 prefix reachable via one of its enterprise edge 660 interfaces, the EBR configures the IPv6 subnet router anycast address 661 for the prefix [RFC4291], e.g., on a loopback interface. The EBR 662 then publishes the most-significant 64 bits of the prefix in the 663 enterprise name service using the domain name suffix 664 'isatap.example.com'. The EBR publishes the prefix as a domain name 665 containing a sequence of 16 nibbles in reverse order using a format 666 corresponding to that specified in ([RFC3596], Section 2.5). For 667 example, the EBR publishes the prefix 2001:DB8::/64 as: 668 '0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. For 669 publications within the interdomain global DNS itself, the domain 670 name suffix 'isatap.net' is used instead of 'isatap.example.com'. 672 The EBR includes in the publication IPv4 addresses (e.g., in DNS A 673 records) taken from the EBR's enterprise interior interfaces, and an 674 IPv6 link-local CGA address [RFC3972] (e.g., in DNS AAAA records) 675 that other nodes can use to uniquely identify the EBR (or one of a 676 group of redundant EBRs). In enterprises with a cooperative 677 administrative authority, EBRs coordinate their publications with an 678 administrator and/or by using a secure automated name service update 679 mechanism (e.g., [RFC3007]). In enterprises that are managed in a 680 distributed fashion, EBRs publish their /64 IPv6 prefixes through 681 direct responses to distributed name resoultion service queries. 683 In this way, the name service itself becomes an extension of the 684 enterprise's PRL. 686 5.4. IPv6 EBR/EBG Router Discovery 688 EBGs follow the router and prefix discovery procedures specified in 689 ([RFC5214], Section 8.2). They send RAs over VET interfaces for 690 which they are gateways with PIOs for SLAAC, with the 'M' flag set to 691 0 and with the 'O' flag set to indicate whether "other" DHCP services 692 are available. EBGs can also include PIOs with the 'L' bit set to 0 693 and with a prefix such as 2001:DB8::/48 as a hint of an aggregated 694 prefix from which it is willing to delegate longer prefixes. 696 VET hosts and EBRs follow the router and prefix discovery procedures 697 specified in ([RFC5214], Section 8.3). They discover EBGs by 698 resolving the names "6over4.example.com" and/or "isatap.example.com"; 699 in some multicast-capable deployments, they can also derive hints of 700 EBG reachability by listening for advertisements on the 'rasadv' 701 [RASADV] IPv4 multicast group address. 703 VET hosts and EBRs discover the EBRs for specific IPv6 prefixes by 704 querying the name service for the /64 IPv6 prefix corresponding to a 705 packet's destination address. For example, for the IPv6 destination 706 address 2001:DB8:1:2::1 the VET host/EBR queries the 707 'isatap.example.com' domain for the domain name: 708 '2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. The name 709 service query will return IPv4 addresses (e.g., in DNS A records) 710 that correspond to an EBR's enterprise interior interfaces and an 711 IPv6 link-local CGA address (e.g., in DNS AAAA records) that the VET 712 host/EBR can use to verify EBR/EBG address ownership. 714 VET hosts and EBRs discover default router lifetimes, default router 715 preferences and more-specific routes [RFC4191] by sending an RS over 716 the VET interface using the link-local CGA address of the EBR/EBG as 717 the destination address. The EBR/EBG returns an RA using Secure 718 Neighbor Discovery (SEND) [RFC3971], with the CGA published in the 719 name service as the IPv6 link-local source address and with an IPv4 720 address taken from its enterprise interior addresses as the IPv4 721 address in the outer header. The VET host/EBR can then use SEND to 722 verify that the RA came from the correct EBR/EBG. 724 VET hosts and EBRs must only accept PIOs, M/O flag settings and 725 default router preferences in RAs that are received from EBGs; they 726 MUST NOT accept them from ordinary EBRs. 728 5.5. Forwarding Packets to Destinations Outside of the Enterprise 730 After default and/or more-specific routes are discovered, VET hosts 731 and EBRs can forward IP packets to off-enterprise destinations by 732 consulting the FIB to determine a specific EBR/EBG as the next-hop 733 router on the VET interface. When multiple next-hop routers are 734 available, VET hosts and EBRs can use default router preferences, 735 routing protocol information, traffic engineering configurations, 736 etc. to select the best exit router. When there is no FIB 737 information available, VET hosts and EBRs can discover the next-hop 738 EBR/EBG through the mechanisms specified in Section 5.4. 740 VET interfaces encapsulate inner IP packets in any mid-layer headers 741 followed by an outer IP header according to the specific 742 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 743 next submit the encapsulated packet to the outer IP forwarding engine 744 for transmission on an underlying enterprise-interior interface. For 745 forwarding to next-hop addresses over VET interfaces that use IPv6- 746 in-IPv4 encapsulation, VET hosts and EBRs determine the outer 747 destination address through static extraction of the IPv4 address 748 embedded in the next-hop ISATAP address. For other IP-in-IP 749 encapsulations, determination of the outer destination address is 750 through administrative configuration or through an unspecified 751 alternate method. 753 When a VET host/EBR forward packets to an EBG that has more 754 comprehensive FIB information, the EBG can forward the packet and 755 issue ordinary ICMP redirects over the VET interface as necessary. 756 If the next-hop corresponds to a node outside the enterprise, the EBG 757 decapulates the packet and forwards it the same as for an ordinary 758 router. If the next-hop corresponds to another node on the VET 759 interface, however, the EBG forwards the packet without decapsulation 760 by rewriting the outer IP destination address but leaving the outer 761 IP source address intact. 763 5.6. Source Address Verification 765 VET hosts and EBRs must verify that the outer IP source address of a 766 packet received on a VET interface is correct for the inner IP source 767 address using the procedures specified in ([RFC5214], Section 7.3). 769 5.7. Enterprise-Local Communications 771 When permitted by policy, end systems that configure the endpoints of 772 enterprise-local communications can avoid VET interface encapsulation 773 by directly invoking the outer IP protocol using ELAs assigned to 774 their enterprise-interior interfaces. For example, when the outer 775 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 776 communications over their enterprise-interior interfaces without 777 using the VET interface. 779 5.8. Multicast 781 In multicast-capable deployments, EIRs provide an enterprise-wide 782 multicasting service such as Simplified Multicast Forwarding (SMF) 783 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 784 that outer IP multicast messages of site- or greater scope will be 785 propagated across the enterprise. For such deployments, VET hosts 786 and EBRs can also provide an inner IP multicast/broadcast capability 787 over their VET interfaces through mapping of the inner IP multicast 788 address space to the outer IP multicast address space. 790 VET hosts and EBRs encapsulate inner IP multicast messages sent over 791 the VET interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) 792 plus an outer IP header with a site-scoped outer IP multicast address 793 as the destination. For the case of IPv6 and IPv4 as the inner/outer 794 protocols (respectively), [RFC2529] provides mappings from the IPv6 795 multicast address space to the IPv4 multicast address space. For 796 other IP-in-IP encapsulations, mappings are established through 797 administrative configuration or through an unspecified alternate 798 method. 800 For multicast-capable enterprises, use of the inner IP multicast 801 service for operating the ND protocol over the VET interface is 802 available but should be used sparingly to minimize enterprise-wide 803 flooding. 805 5.9. Service Discovery 807 VET hosts and EBRs can peform enterprise-wide service discovery using 808 a suitable name-to-address resolution service. Examples of flooding- 809 based services include the use of LLMNR [RFC4759] over the VET 810 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 811 underlying enterprise-interior interface. More scalable and 812 efficient service discovery mechanisms are for further study. 814 6. Enterprise Partitioning 816 EBGs can physically partition an enterprise by configuring multiple 817 VET interfaces over multiple distinct sets of underlying interfaces. 818 In that case, each partition (i.e., each VET interface) must 819 configure its own distinct PRL zone (e.g., 'zone1.example.com', 820 'zone2.example.com', etc.). 822 EBGs can logically partition an enterprise using a single VET 823 interface by sending RAs with PIOs containing different IPv6 subnet 824 prefixes to nodes in different logical partitions. EBGs can identify 825 partitions, e.g., by examining IPv4 prefixes, observing the 826 interfaces over which RSs are received, etc. In that case, a single 827 PRL zone can cover all partitions. 829 7. Securing VET with SEAL 831 Enterprises for which use of IPsec is infeasible (or for which 832 additional mechanisms are desired) can use SEAL encapsulation 833 [I-D.templin-seal] in conjunction with VET to defend against rogue 834 routers and source address spoofing. 836 When an ingress EBR in an enterprise that uses SEAL encapsulation has 837 an IPv6 packet to send but there is no matching FIB entry, it should 838 first send an IPv6 RA using the IPv6 subnet router anycast address 839 [RFC4291] corresponding to the destination as the RA's destination 840 and using its published IPv6 CGA address as the RA's source. The RA 841 should contain SEND parameters and Route Information Options 842 [RFC4191] corresponding to the ingress EBR's aggregated IPv6 843 prefixes. The ingress EBR should populate its FIB entries based on 844 mapping lookups in parallel with sending the RA to the subnet router 845 anycast address; it can optionally buffer the RA and subsequent 846 packets while mapping lookups are performed, or it can forward the 847 packets immediately via an EBG. 849 Using this approach, the ingress EBR can optionally set the 850 'Acknolwedgement Requested' bit in the SEAL header to receive L2 851 confirmation that an egress EBR has received its RA, and can schedule 852 retransmissions if no confirmation is received. The ingress EBR also 853 sets the SEAL_ID in the packet such that the egress EBR can discover 854 the current encapsulation sequence number. 856 When an egress EBR that configures the subnet router anycast address 857 receives the RA, it can use SEND mechanisms to verify that the packet 858 came from an authentic ingress EBR and can use the SEAL_ID to track 859 the sequence of subsequent packets it receives from the ingress EBR. 860 The egress EBR can therefore use the SEAL_ID to detect and discard 861 potentially spoofed packets that have IDs outside of the current 862 window, and can use the prefixes received from the ingress EBR for 863 egress filtering to detect source address spoofing. The egress EBR 864 can also send an RS to elicit an RA from the ingress EBR to refresh 865 prefix lifetimes, or at any time state synchronization must be 866 reestablished. 868 8. IANA Considerations 870 A Site-Local Scope IPv4 multicast group (TBD) for DHCPv4 server 871 discovery is requested. The allocation should be taken from the 872 239.255.000.000-239.255.255.255 Site-Local Scope range in the IANA 873 'multicast-addresses' registry. 875 9. Security Considerations 877 Security considerations for MANETs are found in [RFC2501]. 879 Security considerations with tunneling that apply also to VET are 880 found in [RFC2529][RFC5214]. 882 The securing methods specified in Section 7 provide additional 883 mitigation against both rogue EBRs (via SEND) and source address 884 spoofing (via the SEAL_ID and prefix-based egress filtering). These 885 mechanisms can further be fortifed and made more resiliant against 886 DOS attacks when EIRs function as IPv6 RA-Guards 887 [I-D.ietf-v6ops-ra-guard]. 889 10. Related Work 891 The authors acknowledge the work done by Brian Carpenter and Cyndi 892 Jung in [RFC2529] that introduced the concept of intra-site automatic 893 tunneling. This concept was later called: "Virtual Ethernet" and 894 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 895 As for this document, these architectural principles also follow from 896 earlier works articulated by the ROAD group deliberations of 1992. 898 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 899 program. The Naval Research Lab (NRL) Information Technology 900 Division uses DHCP in their MANET research testbeds. Various 901 proposals within the IETF have suggested similar mechanisms. 903 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 904 regarding tunneling mechanisms that may subvert security through 905 Network Address Translator (NAT) traversal. 907 An automated IPv4 prefix delegation mechanism is proposed in 908 [I-D.ietf-dhc-subnet-alloc]. 910 11. Acknowledgements 912 The following individuals gave direct and/or indirect input that was 913 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 914 Bound, Thomas Clausen, Joel Halpern, Bob Hinden, Joe Macker, Thomas 915 Narten, Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, 916 Ole Troan, Michaela Vanderveen and others in the IETF AUTOCONF and 917 MANET working groups. Many others have provided guidance over the 918 course of many years. 920 12. Contributors 922 The following individuals have contributed to this document: 924 Eric Fleischman (eric.fleischman@boeing.com) 925 Thomas Henderson (thomas.r.henderson@boeing.com) 926 Steven Russert (steven.w.russert@boeing.com) 927 Seung Yi (seung.yi@boeing.com) 929 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 930 of the document. 932 13. References 934 13.1. Normative References 936 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 937 September 1981. 939 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 940 converting network protocol addresses to 48.bit Ethernet 941 address for transmission on Ethernet hardware", STD 37, 942 RFC 826, November 1982. 944 [RFC1035] Mockapetris, P., "Domain names - implementation and 945 specification", STD 13, RFC 1035, November 1987. 947 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 948 RFC 2131, March 1997. 950 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 951 (IPv6) Specification", RFC 2460, December 1998. 953 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 954 Update", RFC 3007, November 2000. 956 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 957 and M. Carney, "Dynamic Host Configuration Protocol for 958 IPv6 (DHCPv6)", RFC 3315, July 2003. 960 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 961 "DNS Extensions to Support IP Version 6", RFC 3596, 962 October 2003. 964 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 965 Host Configuration Protocol (DHCP) version 6", RFC 3633, 966 December 2003. 968 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 969 Neighbor Discovery (SEND)", RFC 3971, March 2005. 971 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 972 RFC 3972, March 2005. 974 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 975 More-Specific Routes", RFC 4191, November 2005. 977 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 978 Architecture", RFC 4291, February 2006. 980 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 981 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 982 September 2007. 984 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 985 Address Autoconfiguration", RFC 4862, September 2007. 987 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 988 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 989 March 2008. 991 13.2. Informative References 993 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 994 Switching Networks", May 1974. 996 [I-D.cheshire-dnsext-multicastdns] 997 Cheshire, S. and M. Krochmal, "Multicast DNS", 998 draft-cheshire-dnsext-multicastdns-07 (work in progress), 999 September 2008. 1001 [I-D.clausen-manet-linktype] 1002 Clausen, T., "The MANET Link Type", 1003 draft-clausen-manet-linktype-00 (work in progress), 1004 October 2008. 1006 [I-D.ietf-autoconf-manetarch] 1007 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1008 Network Architecture", draft-ietf-autoconf-manetarch-07 1009 (work in progress), November 2007. 1011 [I-D.ietf-dhc-subnet-alloc] 1012 Johnson, R., "Subnet Allocation Option", 1013 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1014 July 2008. 1016 [I-D.ietf-ipv6-ula-central] 1017 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1018 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1019 progress), June 2007. 1021 [I-D.ietf-manet-smf] 1022 Macker, J. and S. Team, "Simplified Multicast Forwarding 1023 for MANET", draft-ietf-manet-smf-08 (work in progress), 1024 November 2008. 1026 [I-D.ietf-v6ops-ra-guard] 1027 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 1029 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-01 1030 (work in progress), September 2008. 1032 [I-D.ietf-v6ops-tunnel-security-concerns] 1033 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1034 Concerns With IP Tunneling", 1035 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1036 progress), October 2008. 1038 [I-D.templin-seal] 1039 Templin, F., "The Subnetwork Encapsulation and Adaptation 1040 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1041 August 2008. 1043 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1044 July 1978. 1046 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1047 Protocol Specification", October 2008. 1049 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1050 Communication Layers", STD 3, RFC 1122, October 1989. 1052 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1053 Routing and Addressing Architecture", RFC 1753, 1054 December 1994. 1056 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1057 E. Lear, "Address Allocation for Private Internets", 1058 BCP 5, RFC 1918, February 1996. 1060 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1061 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1063 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1064 (MANET): Routing Protocol Performance Issues and 1065 Evaluation Considerations", RFC 2501, January 1999. 1067 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1068 Domains without Explicit Tunnels", RFC 2529, March 1999. 1070 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1071 February 2000. 1073 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1074 via IPv4 Clouds", RFC 3056, February 2001. 1076 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1077 RFC 3753, June 2004. 1079 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1080 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1081 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1082 RFC 3819, July 2004. 1084 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1085 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1086 May 2005. 1088 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1089 Addresses", RFC 4193, October 2005. 1091 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1092 Internet Protocol", RFC 4301, December 2005. 1094 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1095 Indicator Parameter for the "tel" URI", RFC 4759, 1096 December 2006. 1098 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1099 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1100 Focus", RFC 4852, April 2007. 1102 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1103 June 2007. 1105 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1106 Extensions for Stateless Address Autoconfiguration in 1107 IPv6", RFC 4941, September 2007. 1109 Appendix A. Duplicate Address Detection (DAD) Considerations 1111 A-priori uniqueness determination (also known as "pre-service DAD") 1112 for an ELA assigned on an enterprise-interior interface (such as 1113 specified in [RFC4862]) would require either flooding the entire 1114 enterprise or somehow discovering a link in the enterprise on which a 1115 node that configures a duplicate address is attached and performing a 1116 localized DAD exchange on that link. But, the control message 1117 overhead for such an enterprise-wide DAD would be substantial and 1118 prone to false-negatives due to packet loss and intermittent 1119 connectivity. An alternative to pre-service DAD is to autoconfigure 1120 pseudo-random ELAs on enterprise-interior interfaces and employ a 1121 passive in-service DAD (e.g., one that monitors routing protocol 1122 messages for duplicate assignments). 1124 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1125 CGAs, IPv6 privacy addresses, etc. with very small probability of 1126 collision. Pseudo-random IPv4 ELAs can be generated through random 1127 assignment from a suitably large IPv4 prefix space. 1129 Consistent operational practices can assure uniqueness for EBG- 1130 aggregated addresses/prefixes, while statistical properties for 1131 pseudo-random address self-generation can assure uniqueness for the 1132 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 1133 ELA delegation authority should be used when available, while a 1134 passive in-service DAD mechanism should be used to detect ELA 1135 duplications when there is no ELA delegation authority. 1137 Appendix B. Change Log 1139 (Note to RFC editor - this section to be removed before publication 1140 as an RFC.) 1142 Changes from -21 to 22: 1144 o Using SEAL to secure VET 1146 Changes from -20 to 21: 1148 o Enterprise partitioning. 1150 o Mapping and name service management. 1152 Changes from -18 to 20: 1154 o Added support for simple hosts. 1156 o Added EBG name service maintenace procedures 1158 o Added router and prefix maintenace procedures 1160 Changes from -17 to 18: 1162 o adjusted section headings to group autoconf operations under EIR/ 1163 EBR/EBG. 1165 o clarified M/O bits 1167 o clarified EBG roles 1169 Changes from -15 to 17: 1171 o title change to "Virtual Enterprise Traversal (VET)". 1173 o changed document focus from MANET-centric to the much-broader 1174 Enterprise-centric, where "Enterprise" is understood to also cover 1175 a wide range of MANET types. 1177 Changes from -14 to 15: 1179 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1181 o Address review comments 1183 Changes from -12 to 14: 1185 o title change to "The MANET Virtual Ethernet Abstraction". 1187 o Minor section rearrangement. 1189 o Clartifications on portable and self-configured prefixes. 1191 o Clarifications on DHCPv6 prefix delegation procedures. 1193 Changes from -11 to 12: 1195 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1197 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1198 delegation mechanism. 1200 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1202 o fixed editorials based on comments received. 1204 Changes from -10 to 11: 1206 o removed the transparent/opaque VET portal abstractions. 1208 o removed routing header as an option for MANET exit router 1209 selection. 1211 o included IPv6 SLAAC as an endorsed address configuration mechanism 1212 for the VET interface. 1214 Changes from -08 to -09: 1216 o Introduced the term "VET". 1218 o Changed address delegation language to speak of "MNBR-aggregated" 1219 instead of global/local. 1221 o Updated figures 1-3. 1223 o Explained why a MANET interface is "neutral". 1225 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1226 DHCPv4 servers; not relays. 1228 Changes from -07 to -08: 1230 o changed terms "unenhanced" and "enhanced" to "transparent" and 1231 "opaque". 1233 o revised MANET Router diagram. 1235 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1236 interface. 1238 o changed abbreviations to "MNR" and "MNBR". 1240 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1242 o rearranged Section 3.1. 1244 o various minor text cleanups 1246 Changes from -06 to -07: 1248 o added MANET Router diagram. 1250 o added new references 1252 o various minor text cleanups 1254 Changed from -05 to -06: 1256 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1258 o minor changes to preserve generality 1260 Changed from -04 to -05: 1262 o introduced conceptual "virtual ethernet" model. 1264 o support "raw" and "cooked" modes as equivalent access methods on 1265 the virutal ethernet. 1267 Changed from -03 to -04: 1269 o introduced conceptual "imaginary shared link" as a representation 1270 for a MANET. 1272 o discussion of autonomous system and site abstractions for MANETs 1274 o discussion of autoconfiguration of CGAs 1276 o new appendix on IPv6 StateLess Address AutoConfiguration 1278 Changes from -02 to -03: 1280 o updated terminology based on RFC2461 "asymmetric reachability" 1281 link type; IETF67 MANET Autoconf wg discussions. 1283 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1284 Address Detection 1286 o relaxed DHCP server deployment considerations allow DHCP servers 1287 within the MANET itself 1289 Changes from -01 to -02: 1291 o minor updates for consistency with recent developments 1293 Changes from -00 to -01: 1295 o new text on DHCPv6 prefix delegation and multilink subnet 1296 considerations. 1298 o various editorial changes 1300 Author's Address 1302 Fred L. Templin (editor) 1303 Boeing Phantom Works 1304 P.O. Box 3707 MC 7L-49 1305 Seattle, WA 98124 1306 USA 1308 Email: fltemplin@acm.org 1310 Full Copyright Statement 1312 Copyright (C) The IETF Trust (2008). 1314 This document is subject to the rights, licenses and restrictions 1315 contained in BCP 78, and except as set forth therein, the authors 1316 retain all their rights. 1318 This document and the information contained herein are provided on an 1319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1326 Intellectual Property 1328 The IETF takes no position regarding the validity or scope of any 1329 Intellectual Property Rights or other rights that might be claimed to 1330 pertain to the implementation or use of the technology described in 1331 this document or the extent to which any license under such rights 1332 might or might not be available; nor does it represent that it has 1333 made any independent effort to identify any such rights. Information 1334 on the procedures with respect to rights in RFC documents can be 1335 found in BCP 78 and BCP 79. 1337 Copies of IPR disclosures made to the IETF Secretariat and any 1338 assurances of licenses to be made available, or the result of an 1339 attempt made to obtain a general license or permission for the use of 1340 such proprietary rights by implementers or users of this 1341 specification can be obtained from the IETF on-line IPR repository at 1342 http://www.ietf.org/ipr. 1344 The IETF invites any interested party to bring to its attention any 1345 copyrights, patents or patent applications, or other proprietary 1346 rights that may cover technology that may be required to implement 1347 this standard. Please address the information to the IETF at 1348 ietf-ipr@ietf.org.