idnits 2.17.1 draft-templin-autoconf-dhcp-34.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 651: '...PRLNAME'. To avoid looping, EBGs MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 17, 2009) is 5545 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 190, but not defined == Unused Reference: 'RFC4291' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1374, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1454, 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 (-05) exists of draft-ietf-csi-proxy-send-00 == 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 (~~), 12 warnings (==), 4 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 Research and Technology 4 Intended status: Informational February 17, 2009 5 Expires: August 21, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-34.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 21, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 Enterprise networks connect routers over various link types, and may 48 also connect to provider networks and/or the global Internet. 50 Enterprise network nodes require a means to automatically provision 51 IP addresses/prefixes and support internetworking operation in a wide 52 variety of use cases including SOHO networks, Mobile Ad-hoc Networks 53 (MANETs), multi-organizational corporate networks and the interdomain 54 core of the global Internet itself. This document specifies a 55 Virtual Enterprise Traversal (VET) abstraction for autoconfiguration 56 and operation of nodes in enterprise networks. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 10 63 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 11 65 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 13 66 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 13 67 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration . . 14 68 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration . . 15 69 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 15 70 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 16 71 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 16 72 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 16 73 5.2. IPv6 Router Discovery and Prefix Registration . . . . . . 16 74 5.2.1. IPv6 Default Router Discovery . . . . . . . . . . . . 17 75 5.2.2. IPv6 PA Prefix Registration . . . . . . . . . . . . . 17 76 5.2.3. IPv6 PI Prefix Registration . . . . . . . . . . . . . 18 77 5.2.4. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . 19 78 5.3. IPv4 Router Discovery and Prefix Registration . . . . . . 21 79 5.4. Forwarding Packets . . . . . . . . . . . . . . . . . . . . 22 80 5.5. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 22 81 5.6. Generating Errors . . . . . . . . . . . . . . . . . . . . 23 82 5.7. Processing Errors . . . . . . . . . . . . . . . . . . . . 23 83 5.8. Mobility and Multihoming Considerations . . . . . . . . . 24 84 5.9. Enterprise-Local Communications . . . . . . . . . . . . . 25 85 5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 25 86 5.11. Service Discovery . . . . . . . . . . . . . . . . . . . . 26 87 5.12. Enterprise Partitioning . . . . . . . . . . . . . . . . . 27 88 5.13. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 27 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 91 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 97 Appendix A. Duplicate Address Detection (DAD) Considerations . . 33 98 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 34 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 1. Introduction 103 Enterprise networks [RFC4852] connect routers over various link types 104 (see: [RFC4861], Section 2.2). The term "enterprise network" in this 105 context extends to a wide variety of use cases and deployment 106 scenarios. For example, an "enterprise" can be as small as a SOHO 107 network, as complex as a multi-organizational corporation, or as 108 large as the global Internet itself. Certain Mobile Ad-hoc Networks 109 (MANETs) [RFC2501] can also be considered as a challenging example of 110 an enterprise network, in that their topologies may change 111 dynamically over time and that they may employ little/no active 112 management by a centralized network administrative authority. These 113 specialized characteristics for MANETs require careful consideration, 114 but the same principles apply equally to other enterprise network 115 scenarios. 117 This document specifies a Virtual Enterprise Traversal (VET) 118 abstraction for autoconfiguration and internetworking operation, 119 where addresses of different scopes may be assigned on various types 120 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 121 [RFC2460] are discussed within this context. The use of standard 122 DHCP [RFC2131][RFC3315] and neighbor discovery 123 [RFC0826][RFC1256][RFC4861] mechanisms is assumed unless otherwise 124 specified. 126 Provider-edge Interfaces 127 x x x 128 | | | 129 +--------------------+---+--------+----------+ E 130 | | | | | n 131 | I | | .... | | t 132 | n +---+---+--------+---+ | e 133 | t | +--------+ /| | r 134 | e I x----+ | Host | I /*+------+--< p I 135 | r n | |Function| n|**| | r n 136 | n t | +--------+ t|**| | i t 137 | a e x----+ V e|**+------+--< s e 138 | l r . | E r|**| . | e r 139 | f . | T f|**| . | f 140 | V a . | +--------+ a|**| . | I a 141 | i c . | | Router | c|**| . | n c 142 | r e x----+ |Function| e \*+------+--< t e 143 | t s | +--------+ \| | e s 144 | u +---+---+--------+---+ | r 145 | a | | .... | | i 146 | l | | | | o 147 +--------------------+---+--------+----------+ r 148 | | | 149 x x x 150 Enterprise-edge Interfaces 152 Figure 1: Enterprise Router (ER) Architecture 154 Figure 1 above depicts the architectural model for an Enterprise 155 Router (ER). As shown in the figure, an ER may have a variety of 156 interface types including enterprise-edge, enterprise-interior, 157 provider-edge, internal-virtual, as well as VET interfaces used for 158 encapsulation of inner IP packets within outer IP headers. The 159 different types of interfaces are defined, and the autoconfiguration 160 mechanisms used for each type are specified. This architecture 161 applies equally for MANET routers, in which enterprise-interior 162 interfaces correspond to the wireless multihop radio interfaces 163 typically associated with MANETs. Out of scope for this document is 164 the autoconfiguration of provider interfaces, which must be 165 coordinated in a manner specific to the service provider's network. 167 Enterprise networks must have a means for supporting both Provider- 168 Independent (PI) and Provider-Aggregated (PA) IP prefixes for global- 169 scope communications. This is especially true for enterprise 170 scenarios that involve mobility and multihoming. Also in scope are 171 ingress filtering for multi-homed sites, adaptation based on 172 authenticated ICMP feedback from on-path routers, effective tunnel 173 path MTU mitigations and routing scaling suppression as required in 174 many enterprise network scenarios. Recognizing that one size does 175 not fit all, the VET specification provides adaptable mechanisms that 176 address these issues and more in a wide variety of enterprise network 177 use cases. 179 VET represents a functional superset of 6over4 [RFC2529] and ISATAP 180 [RFC5214], and further supports additional encapsulations such as 181 IPsec [RFC4301], SEAL [I-D.templin-seal], etc. As a result, VET 182 provides a map-and-encaps architecture using IP-in-IP tunneling based 183 on both IP routing and mapping service resolution (defined herein). 185 The VET principles can be either directly or indirectly traced to the 186 deliberations of the ROAD group in January 1992, and also to still 187 earlier works including NIMROD [RFC1753], the Catenet model for 188 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 189 the high-level architectural aspects of the ROAD group deliberations 190 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 191 IPNG". 193 VET is related to the present-day activites of the IETF autoconf, 194 dhc, ipv6, manet and v6ops working groups, as well as the IRTF rrg 195 working group. 197 2. Terminology 199 The mechanisms within this document build upon the fundamental 200 principles of IP-within-IP encapsulation. The terms "inner" and 201 "outer" are used to respectively refer to the innermost IP {address, 202 protocol, header, packet, etc.} *before* encapsulation, and the 203 outermost IP {address, protocol, header, packet, etc.} *after* 204 encapsulation. VET also allows for inclusion of "mid-layer" 205 encapsulations between the inner and outer layers, including IPSec 206 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 207 [I-D.templin-seal], etc. 209 The terminology in the normative references apply; the following 210 terms are defined within the scope of this document: 212 subnetwork 213 the same as defined in [RFC3819]. 215 enterprise 216 the same as defined in [RFC4852]. An enterprise is also 217 understood to refer to a cooperative networked collective with a 218 commonality of business, social, political, etc. interests. 219 Minimally, the only commonality of interest in some enterprise 220 network scenarios may be the cooperative provisioning of 221 connectivity itself. 223 site 224 a logical and/or physical grouping of interfaces that connect a 225 topological area less than or equal to an enterprise in scope. A 226 site within an enterprise can in some sense be considered as an 227 enterprise unto itself. 229 Mobile Ad-hoc Network (MANET) 230 a connected topology of mobile or fixed routers that maintain a 231 routing structure among themselves over dynamic links, where a 232 wide variety of MANETs share common properties with enterprise 233 networks. Characteristics of MANETs are defined in [RFC2501], 234 Section 3. 236 enterprise/site/MANET 237 throughout the remainder of this document, the term "enterprise" 238 is used to collectively refer to any of enterprise/site/MANET, 239 i.e., the VET mechanisms and operational principles can be applied 240 to enterprises, sites and MANETs of any size or shape. 242 Enterprise Router (ER) 243 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 244 mobile router that comprises a router function, a host function, 245 one or more enterprise-interior interfaces and zero or more 246 internal virtual, enterprise-edge, provider-edge and VET 247 interfaces. At a minimum, an ER forwards packets over one or more 248 sets of enterprise-interior interfaces, where each set connects to 249 a distinct enterprise. 251 Enterprise Border Router (EBR) 252 an ER that connects edge networks to the enterprise, and/or 253 connects multiple enterprises together. An EBR configures a 254 seperate VET interface over each set of enterprise-interior 255 interfaces that connect the EBR to each distinct enterprise. In 256 particular, an EBR may configure mulitple VET interfaces - one for 257 each distinct enterprise. All EBRs are also ERs. 259 Enterprise Border Gateway (EBG) 260 an EBR that connects VET interfaces configured over child 261 enterprises to a provider network - either directly via a 262 provider-edge interface, or indirectly via another VET interface 263 configured over a parent enterprise. EBRs may act as EBGs on some 264 VET interfaces and as ordinary EBRs on other VET interfaces. All 265 EBGs are also EBRs. 267 enterprise-interior interface 268 a ER's attachment to a link within an enterprise. Packets sent 269 over enterprise-interior interfaces may be forwarded over multiple 270 additional enterprise-interior interfaces within the enterprise 271 before they are forwarded via an enterprise-edge interface, 272 provider-edge interface or a VET interface configured over a 273 different enterprise. 275 enterprise-edge interface 276 an EBR's attachment to a link (e.g., an ethernet, a wireless 277 personal area network, etc.) on an arbitrarily-complex edge 278 network that the EBR connects to an enterprise and/or to provider 279 networks. 281 internal-virtual interface 282 a virtual interface that is a special case of either an 283 enterprise-edge or an enterprise-interior interface. Internal- 284 virtual interfaces that are also enterprise-edge interfaces are 285 often loopback interfaces of some form. Internal-virtual 286 interfaces that are also enterprise-interior interfaces are often 287 tunnel interfaces of some form configured over another enterprise- 288 interior interface. 290 provider-edge interface 291 an EBR's attachment to the Internet, or to a provider network 292 outside of the enterprise via which the Internet can be reached. 294 Enterprise Local Address (ELA) 295 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 296 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 297 is assigned to an enterprise-interior interface and unique within 298 the enterprise. ELAs are used as identifiers for operating the 299 routing protocol and/or locators for packet forwarding within the 300 scope of the enterprise. ELAs are used as the *outer* IP 301 addresses during encapsulation, and can also be used as addresses 302 for enterprise-internal communications that do not require 303 encapsulation. 305 Provider-Independent (PI) prefix 306 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 307 that is routable within a limited scope and may also appear in a 308 global mapping table. PI prefixes that can appear in a global 309 mapping table are typically delegated to an EBR by a registry, but 310 are not aggregated by a provider network. Local-use IPv6 and IPv4 311 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of 312 a PI prefix, but these typically do not appear in a global mapping 313 table. 315 Provider Aggregated (PA) prefix 316 an IPv6 or IPv4 prefix that is either derived from a PI prefix or 317 delegated directly to a provider network by a registry. 319 Virtual Enterprise Traversal (VET) 320 an abstraction that uses IP-in-IP encapsulation to span a multi- 321 link enterprise in a single (inner) IP hop. 323 VET interface 324 an EBR's Non-Broadcast, Multiple Access (NBMA) interface used for 325 Virtual Enterprise Traversal. The EBR configures a VET interface 326 over a set of underlying enterprise-interior interface(s) 327 belonging to the same enterprise. When there are multiple 328 distinct enterprises (each with their own distinct set of 329 enterprise-interior interfaces), the EBR configures a separate VET 330 interface over each set of enterprise-interior interfaces, i.e., 331 the EBR configures multiple VET interfaces. 333 The VET interface encapsulates each inner IP packet in any mid- 334 layer headers plus an outer IP header then forwards it on an 335 underlying enterprise-interior interface such that the TTL/Hop 336 Limit in the inner header is not decremented as the packet 337 traverses the enterprise. The VET interface therefore presents an 338 automatic tunneling abstraction that represents the enterprise as 339 a single IP hop. 341 VET host 342 any node (host or router) that configures a VET interface for host 343 operation only. Note that a single node may configure some of its 344 VET interfaces as host interfaces and others as router interfaces. 346 VET node 347 any node that configures and uses a VET interface. 349 The following additional acronyms are used throughout the document: 351 CGA - Cryptographically Generated Address 352 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 353 FIB - Forwarding Information Base 354 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 355 NBMA - Non-Broadcast, Multiple Access 356 ND - Neighbor Discovery 357 PA - Provider Aggregated 358 PI - Provider Independent 359 PIO - Prefix Information Option 360 PRL - Potential Router List 361 PRLNAME - Identifying name for the PRL (default is "isatap") 362 RIO - Route Information Option 363 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 364 SEAL - Subnetwork Encapsulation and Adaptation Layer 365 SLAAC - IPv6 StateLess Address AutoConfiguation 367 3. Enterprise Characteristics 369 Enterprises consist of links that are connected by Enterprise Routers 370 (ERs) as depicted in Figure 1. ERs typically participate in a 371 routing protocol over enterprise-interior interfaces to discover 372 routes that may include multiple Layer-2 or Layer-3 forwarding hops. 373 Enterprise Border Routers (EBRs) are ERs that connect edge networks 374 to the enterprise and/or join multiple enterprises together. 375 Enterprise Border Gateways (EBGs) are EBRs that either directly or 376 indirectly connect enterprises to provider networks. 378 An enterprise may be as simple as a small collection of ERs and their 379 attached edge networks; an enterprise may also contain other 380 enterprises and/or be a subnetwork of a larger enterprise. An 381 enterprise may further encompass a set of branch offices and/or 382 nomadic hosts connected to a home office over one or several service 383 providers, e.g., through Virtual Private Network (VPN) tunnels. 385 Enterprises that comprise link types with sufficiently similar 386 properties (e.g., Layer-2 (L2) address formats, maximum transmission 387 units (MTUs), etc.) can configure a sub-IP layer routing service such 388 that IP sees the enterprise as an ordinary shared link the same as 389 for a (bridged) campus LAN. In that case, a single IP hop is 390 sufficient to traverse the enterprise without IP layer encapsulation. 392 Enterprises that comprise link types with diverse properties and/or 393 configure multiple IP subnets must also provide a routing service 394 that operates as an IP layer mechanism. In that case, multiple IP 395 hops may be necessary to traverse the enterprise such that specific 396 autoconfiguration procedures are necessary to avoid multilink subnet 397 issues [RFC4903]. In particular, we describe herein the use of IP- 398 in-IP encapsulation to span the enterprise in a single (inner) IP hop 399 in order to avoid the multilink subnet issues that arise when 400 enterprise-interior interfaces are used directly by applications. 402 Conceptually, an ER embodies both a host function and router 403 function. The host function supports global-scoped communications 404 over any of the ER's non-enterprise-interior interfaces according to 405 the weak end system model [RFC1122] and also supports enterprise- 406 local-scoped communications over its enterprise-interior interfaces. 407 The router function engages in the enterprise-interior routing 408 protocol, connects any of the ER's edge networks to the enterprise 409 and may also connect the enterprise to provider networks (see: 411 Figure 1). 413 In addition to other interface types, VET nodes configure VET 414 interfaces that view all other VET nodes in an enterprise as single- 415 hop neighbors attached to an imaginary Non-Broadcast, Multiple Access 416 (NBMA) link, where the enterprise can also appear as a single IP hop 417 within another enterprise. VET nodes configure a separate VET 418 interface for each distinct enterprise to which they connect, and 419 discover other EBRs on each VET interface that can be used for 420 forwarding packets to off-enterprise destinations. 422 For each distinct enterprise, an enterprise trust basis must be 423 established and consistently applied. For example, in enterprises in 424 which EBRs establish symmetric security associations, mechanisms such 425 as IPsec [RFC4301] can be used to assure authentication and 426 confidentiality. In other enterprise network scenarios, asymmetric 427 securing mechanisms such as SEcure Neighbor Discovery (SEND) 428 [RFC3971] may be necessary to authenticate exchanges based on trust 429 anchors. 431 Finally, in enterprises with a centralized management structure 432 (e.g., a corporate campus network), the enterprise name service and a 433 synchronized set of EBGs can provide infrastructure support for 434 virtual enterprise traversal. In that case, the EBGs can provide a 435 "default mapper" [I-D.jen-apt] service used for short term packet 436 forwarding until EBR neighbor relationships can be established. In 437 enterprises with a distributed management structure (e.g., a large 438 MANET), peer-to-peer coordination between the EBRs themselves may be 439 required. Recognizing that various use cases will entail a continuum 440 between a fully-distributed and fully-centralized approach, the 441 following sections present the mechanisms of Virtual Enterprise 442 Traversal as they apply to a wide variety of scenarios. 444 4. Autoconfiguration 446 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 447 specified in the following subsections: 449 4.1. Enterprise Router (ER) Autoconfiguration 451 ERs configure enterprise-interior interfaces and engage in routing 452 protocols over those interfaces. 454 When an ER joins an enterprise, it first configures a unique IPv6 455 link-local address on each enterprise-interior interface that 456 requires an IPv6 link-local capability and an IPv4 link-local address 457 on each enterprise-interior interface that requires an IPv4 link- 458 local capability. IPv6 link-local address generation mechanisms that 459 provide sufficient uniqueness include Cryptographically Generated 460 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 461 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 462 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 463 provide an IPv4 link-local address generation capability. 465 Next, the ER configures an Enterprise Local Address (ELA) of the 466 outer IP protocol version on each of its enterprise-interior 467 interfaces and engages in any routing protocols on those interfaces. 468 The ER can configure an ELA via explicit management, DHCP 469 autoconfiguration, pseudo-random self-generation from a suitably 470 large address pool, or through an alternate autoconfiguration 471 mechanism. In some enterprise use cases (e.g., highly dynamic 472 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 473 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 474 issues. 476 ERs that configure ELAs using DHCP may require relay support from 477 other ERs within the enterprise; the ER can alternatively configure 478 both a DHCP client and relay that are connected, e.g., via a pair of 479 back-to-back connected ethernet interfaces, a tun/tap interface, a 480 loopback interface, inter-process communication, etc. For DHCPv6, 481 relays that do not already know the ELA of a server relay requests to 482 the 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 483 relays that do not already know the ELA of a server relay requests to 484 the site-scoped IPv4 multicast group address 'All_DHCPv4_Servers' 485 (see: Section 6). DHCPv4 servers that delegate ELAs join the 486 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 487 received for that group. 489 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 490 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 491 generation of ELAs for IPv4 can be from a large IPv4 private address 492 range (e.g., [RFC1918]). When self-generation is used alone, the ER 493 must continuously monitor the ELAs for uniqueness, e.g., by 494 monitoring the routing protocol, but care must be taken in the 495 interaction of this monitoring with existing mechanisms. 497 A combined approach using both DHCP and self-generation is also 498 possible in which the ER first self-generates a temporary ELA used 499 only for the purpose of procuring an actual ELA taken from a disjoint 500 addressing range. The ER then assigns the temporary ELA to an 501 enterprise-interior interface, engages in the routing protocol and 502 performs a DHCP client/relay exchange using the temporary ELA as the 503 address of the relay. When the DHCP server delegates an actual ELA, 504 the ER abandons the temporary ELA, assigns the actual ELA to the 505 enterprise-interior interface and re-engages in the routing protocol. 507 4.2. Enterprise Border Router (EBR) Autoconfiguration 509 EBRs are ERs that configure VET interfaces over distinct sets of 510 underlying enterprise-interior interfaces; an EBR can connect to 511 multiple enterprises, in which case it would configure multiple VET 512 interfaces. EBRs perform the following autoconfiguration operations: 514 4.2.1. VET Interface Autoconfiguration 516 VET interface autoconfiguration entails: 1) interface initialization, 517 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 518 address autoconfiguration. These functions are specified in the 519 following sections: 521 4.2.1.1. Interface Initialization 523 EBRs configure a VET interface over a set of underlying enterprise- 524 interior interfaces belonging to the same enterprise, where the VET 525 interface presents a Non-Broadcast, Multiple Access (NBMA) 526 abstraction in which all EBRs in the enterprise appear as single hop 527 neighbors through the use of IP-in-IP encapsulation. 529 When IPv6 and IPv4 are used as the inner/outer protocols 530 (respectively), the EBR autoconfigures an ISATAP link-local address 531 ([RFC5214], Section 6.2) on the VET interface to support packet 532 forwarding and operation of the IPv6 neighbor discovery protocol. 533 The ISATAP link-local address embeds an IPv4 ELA assigned to an 534 underlying enterprise-interior interface, and need not be checked for 535 uniqueness since the IPv4 ELA itself was already checked (see: 536 Section 4.1). Link-local address configuration for other inner/outer 537 IP protocol combinations is through administrative configuration or 538 through an unspecified alternate method. 540 After the EBR configures a VET interface, it can communicate with 541 other VET nodes as single-hop neighbors from the viewpoint of the 542 inner IP protocol. 544 4.2.1.2. Enterprise Border Gateway Discovery 546 The EBR next discovers a list of EBGs for each of its VET interfaces. 547 The list can be discovered through information conveyed in the 548 routing protocol and/or through the Potential Router List (PRL) 549 discovery mechanisms outlined in ([RFC5214], Section 8.3.2). In 550 multicast-capable enterprises, EBRs can also listen for 551 advertisements on the 'rasadv' [RASADV] IPv4 multicast group address. 553 In particular, whether or not routing information is available the 554 EBR can discover the list of EBGs by resolving an identifying name 555 for the PRL ('PRLNAME') formed as 'hostname.domainname', where 556 'hostname' is an enterprise-specific name string and 'domainname' is 557 an enterprise-specific DNS suffix. The EBR discovers 'PRLNAME' 558 through manual configuration, a DHCP option, 'rasadv' protocol 559 advertisements, link-layer information (e.g., an IEEE 802.11 SSID) or 560 through some other means specific to the enterprise. In the absence 561 of other information, the EBR sets the 'hostname' component of 562 'PRLNAME' to "isatap" and sets the 'domainname' component only if an 563 enterprise-specifc DNS suffix "example.com" is known (e.g., as 564 "isatap.example.com"). 566 The global Internet interdomain routing core represents a specific 567 example of an enterprise network scenario, albeit on an enormous 568 scale. The 'PRLNAME' assigned to the global Internet interdomain 569 routing core is "isatap.net". 571 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 572 resolving 'PRLNAME' to a list of IPv4 addresses through a name 573 service lookup. For centrally-managed enterprises, the EBR resolves 574 'PRLNAME' using an enterprise-local name service (e.g., the 575 enterprise-local DNS). For enterprises with a distributed management 576 structure, the EBR resolves 'PRLNAME' using LLMNR [RFC4759] over the 577 VET interface. In that case, all EBGs in the PRL respond to the 578 LLMNR query, and the EBR accepts the union of all responses. 580 4.2.1.3. Enterprise Identification 582 Each distinct enterprise must have a unique identity that EBRs can 583 use to discern their enterprise affiliations. 'PRLNAME' as well as 584 the ELAs of EBGs and the IP prefixes the EBGs aggregate serve as an 585 identifier for the enterprise. 587 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration 589 EBRs can acquire Provider-Aggregated (PA) prefixes through 590 autoconfiguration exchanges with EBGs over VET interfaces, where each 591 EBG may be configured as either a DHCP relay or DHCP server. 593 When IPv4 is used as the inner IP protocol, the EBR acquires PA 594 prefixes via an unspecified automated IPv4 prefix delegation 595 exchange, explicit management, etc. 597 When IPv6 is used as the inner IP protocol, the EBR acquires PA 598 prefixes via IPv6 Neighbor Discovery and DHCPv6 Prefix Delegation 599 exchanges. In particular, the EBR (acting as a requesting router) 600 can use DHCPv6 prefix delegation [RFC3633] over the VET interface via 601 an EBG to obtain PA IPv6 prefixes from the server (acting as a 602 delegating router). 604 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 605 exchange [RFC3315]. For example, to perform the 2-message exchange 606 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 607 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 608 relay (see: Section 4.1). The relay then forwards the message over 609 the VET interface to the EBG, which either services the request or 610 relays it further. The forwarded Solicit message will elicit a reply 611 from the server containing PA IPv6 prefix delegations. 613 The EBR can propose a specific prefix to the DHCPv6 server per 614 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 615 available. The server will check the proposed prefix for consistency 616 and uniqueness, then return it in the reply to the EBR if it was able 617 to perform the delegation. 619 After the EBR receives PA prefix delegations, it can provision the 620 prefixes on its enterprise-edge interfaces as well as on other VET 621 interfaces for which it is configured as an EBG. 623 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration 625 Independent of any PA prefixes, EBRs can acquire and use Provider- 626 Independent (PI) prefixes that are either self-configured 627 [RFC4193][I-D.ietf-ipv6-ula-central] or delegated by a registration 628 authority. When an EBR acquires a PI prefix, it must also obtain 629 credentials (e.g., from a certification authority) that it can use to 630 prove prefix ownership when it registers the prefixes with EBGs 631 within an enterprise (see: Section 5.2 and Section 5.3). 633 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 635 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 637 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 639 EBGs are EBRs that connect child enterprises to a provider network 640 via ordinay provider-edge interfaces and/or VET interfaces configured 641 over parent enterprises. EBGs autoconfigure provider-edge interfaces 642 in a manner that is specific to their provider connections, and 643 autoconfigure VET interfaces as specified in Section 4.2.1. EBGs 644 that support PA prefix delegation also configure a DHCP relay/server. 646 For each VET interface on which it is configured as an EBG, the EBG 647 must arrange to add its enterprise-interior interface addresses 648 (i.e., its ELAs) to the PRL (see: Section 4.2.1.2), and must maintain 649 these resource records in accordance with ([RFC5214], Section 9). In 650 particular, for each such VET interface the EBG adds its ELAs to name 651 service resource records for 'PRLNAME'. To avoid looping, EBGs MUST 652 NOT configure a default route over a VET interface on which it is 653 configured as an EBG. 655 For enterprises with a distributed management structure, EBGs respond 656 to LLMNR queries for 'PRLNAME'. 658 4.4. VET Host Autoconfiguration 660 Nodes that cannot be attached via an EBR's enterprise-edge interface 661 (e.g., nomadic laptops that connect to a home office via a Virtual 662 Private Network (VPN)) can instead be configured for operation as a 663 simple host connected to the VET interface. Such VET hosts perform 664 the same VET interface autoconfiguration procedures as specified for 665 EBRs in Section 4.2.1, but they configure their VET interfaces as 666 host interfaces (and not router interfaces). VET hosts can then send 667 packets to other hosts on the VET interface, or to off-enterprise 668 destinations via a next-hop EBR. 670 Note that a node may be configured as a host on some VET interfaces 671 and as an EBR/EBG on other VET interfaces. 673 5. Internetworking Operation 675 Following the autoconfiguration procedures specified in Section 4, 676 ERs, EBRs, EBGs and VET hosts engage in normal internetworking 677 operations as discussed in the following sections: 679 5.1. Routing Protocol Participation 681 Following autoconfiguration, ERs engage in any routing protocols over 682 their enterprise-interior interfaces and forward outer IP packets 683 within the enterprise as for any ordinary router. 685 EBRs can additionally engage in any inner IP routing protocols over 686 enterprise-edge, provider-edge and VET interfaces, and can use those 687 interfaces for forwarding inner IP packets to off-enterprise 688 destinations. Note that these inner IP routing protocols are 689 separate and distinct from any enterprise-interior routing protocols. 691 5.2. IPv6 Router Discovery and Prefix Registration 693 The following sections discuss router and prefix discovery 694 considerations for the case of IPv6 as the inner IP protocol: 696 5.2.1. IPv6 Default Router Discovery 698 EBGs follow the router and prefix discovery procedures specified in 699 ([RFC5214], Section 8.2). They send solicited RAs over VET 700 interfaces for which they are configured as gateways with default 701 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 702 with any other required options/parameters. EBGs must set the 'M' 703 flag in RAs to 0, since the use of DHCPv6 for address configuration 704 on VET interfaces is undefined. EBGs can also include PIOs with the 705 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 706 of an aggregated prefix from which it is willing to delegate longer 707 PA prefixes. 709 VET nodes follow the router and prefix discovery procedures specified 710 in ([RFC5214], Section 8.3). They discover EBGs within the 711 enterprise as specified in Section 4.2.1.2, then perform RS/RA 712 exchanges with the EBGs to establish and maintain default routes. In 713 particular the VET node sends unicast RS messages to EBGs over its 714 VET interface(s) to receive RAs. Depending on the enterprise network 715 trust basis, VET nodes may be required to use SEND to secure the 716 RS/RA exchanges. 718 When the VET node receives an RA, it authenticates the message then 719 configures a default route based on the Router Lifetime. If the RA 720 contains Prefix Information Options (PIOs) with the 'A' and 'L' bits 721 set to 1, the VET node also autoconfigures IPv6 addresses from the 722 advertised prefixes using SLAAC and assigns them to the VET 723 interface. Thereafter, the VET node accepts packets that are 724 fowarded by EBGs for which it has current default routing information 725 (i.e., ingress filtering is based on the default router trust 726 relationship rather than a prefix-specific ingress filter entry). 728 5.2.2. IPv6 PA Prefix Registration 730 After an EBR discovers default routes, it can use DHCP prefix 731 delegation to obtain PA prefixes via an EBG as specified in 732 Section 4.2.2. The DHCP server ensures that the delegations are 733 unique and that the EBG's router function will forward IP packets 734 over the VET interface to the correct EBR. In particular, the EBG 735 must register and track the PA prefixes that are delegated to each 736 EBR. 738 The PA prefix registrations remain active in the EBGs as long as the 739 EBR continues to issue DHCP renewals over the VET interface before 740 lease lifetimes expire. The lease lifetime also keeps the delegation 741 state active even if communications between the EBR and DHCP server 742 are disrupted for a period of time (e.g., due to an enterprise 743 network partition) before being reestablished (e.g., due to an 744 enterprise network merge). 746 5.2.3. IPv6 PI Prefix Registration 748 After an EBR discovers default routes, it must register its PI 749 prefixes by sending RAs to a set of one or more EBGs with Route 750 information Options (RIOs) [RFC4191] that contain the EBR's PI 751 prefixes. Each RA must include the ELA of an EBG as the outer IP 752 destination address and an ISATAP link-local address derived from the 753 ELA as the inner IP destination address. For enterprises that use 754 SEND, the RAs also include a CGA link-local inner source address 755 along with SEND credentials plus any certificates needed to prove 756 ownership of the PI prefixes. The EBR additionally tracks the set of 757 EBGs that it sends RAs to so that it can send subsequent RAs to the 758 same set. 760 When the EBG receives the RA, it first authenticates the message; if 761 the authentication fails, the EBG discards the RA. Otherwise, the 762 EBG installs the PI prefixes with their respective lifetimes in its 763 Forwarding Information Base (FIB) and configures them for both 764 ingress filtering [RFC3704] and forwarding purposes. In particular, 765 the EBG configures the FIB entries as ingress filter rules to accept 766 packets received on the VET interface that have a source address 767 taken from the PI prefixes. It also configures the FIB entries to 768 forward packets received on other interfaces with a destination 769 address taken from the PI prefixes to the EBR that registered the 770 prefixes on the VET interface. 772 The EBG then publishes the PI prefixes in a distributed database 773 (e.g., in a private instance of a routing protocol in which only EBGs 774 participate, via an automated name service update mechanism 775 [RFC3007], etc.). For enterprises that are managed under a 776 centralized administrative authority, the EBG also publishes the PI 777 prefixes in the enterprise-local name service (e.g., the enterprise- 778 local DNS [RFC1035]). 780 In particular, the EBG publishes each /56 prefix taken from the PI 781 prefixes as a seperate FQDN that consists of a sequence of 14 nibbles 782 in reverse order (i.e., the same as in [RFC3596], Section 2.5) 783 followed by the string 'ip6' followed by the string 'PRLNAME'. For 784 example, when 'PRLNAME' is "isatap.example.com", the EBG publishes 785 the prefix '2001:DB8::/56' as: 786 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. The EBG 787 includes the outer IPv4 source address of the RA (e.g., in a DNS A 788 resource record) in each prefix publication. For enterprises that 789 use SEND, the EBG also includes the inner IPv6 CGA source address 790 (e.g., in a DNS AAAA record) in each prefix publication. If the 791 prefix was already installed in the distributed database, the EBG 792 instead adds the outer IPv4 source address (e.g., in an additional 793 DNS A records) to the pre-existing publication to support PI prefixes 794 that are multihomed. For enterprises that use SEND, this latter 795 provision requires all EBRs of a multihomed site that advertise the 796 same PI prefixes in RAs to use the same CGA and the same SEND 797 credentials. 799 After the EBG authenticates the RA and publishes the PI prefixes, it 800 next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the 801 VET interfaces configured over any of its parent enterprises and 802 relays a proxied RA to the EBGs on those interfaces. (For 803 enterprises that use SEND, the EBG additionally acts as a SEcure 804 Neighbor Discovery Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) 805 EBGs in parent enterprises that receive the proxied RAs in turn act 806 as NDProxys/SENDProxys to relay the RAs to EBGs on their parent 807 enterprises, etc. The RA proxying and PI prefix publication recurses 808 in this fashion and ends when an EBR attached to an interdomain 809 routing core is reached. 811 After the initial PI prefix registration, the EBR that owns the 812 prefix(es) must periodically send additional RAs to its set of EBGs 813 to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in 814 parent enterprises that it relays the proxied RAs to, and should 815 relay subsequent RAs to the same set. 817 This procedure has a direct analogy in the Teredo method of 818 maintaining state in network middleboxes through the periodic 819 transmission of "bubbles" [RFC4380]. 821 5.2.4. IPv6 Next-Hop EBR Discovery 823 VET nodes discover destination-specific next-hop EBRs within the 824 enterprise by querying the name service for the /56 IPv6 PI prefix 825 taken from a packet's destination address, by forwarding packets via 826 a default route to an EBG, or by some other inner IP to outer IP 827 address mapping mechansim. For example, for the IPv6 destination 828 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 829 node can lookup the domain name: 830 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. If the name 831 service lookup succeeds, it will return IPv4 addresses (e.g., in DNS 832 A records) that correspond to the ELAs assigned to enterprise 833 interior interfaces of next-hop EBRs to which the VET node can 834 forward packets. (In enterprises that use SEND, it will also return 835 an IPv6 CGA address, e.g., in a DNS AAAA record.) 837 Name service lookups in enterprises with a centralized management 838 structure use an infrastructure-based service, e.g., an enterprise- 839 local DNS. Name service lookups in enterprises with a distributed 840 management structure and/or that lack an infrastructure-based name 841 service instead use LLMNR over the VET interface. When LLMNR is 842 used, the EBR that performs the lookup sends an LLMNR query (with the 843 /56 prefix taken from the IP destination address encoded in dotted- 844 nibble format as shown above) and accepts the union of all replies it 845 receives from other EBRs on the VET interface. When an EBR receives 846 an LLMNR query, it responds to the query IFF it aggregates an IP 847 prefix that covers the prefix in the query. 849 Alternatively, in enterprises with a stable and highly-available set 850 of EBGs, the VET node can simply forward an initial packet via a 851 default route to an EBG. The EBG will forward the packet to a next- 852 hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] 853 (using SEND, if necessary). If the packet's source address is on- 854 link on the VET interface, the EBG returns an ordinary "router-to- 855 host" redirects with the source address of the packet as its 856 destination. If the packet's source address is not on-link, the EBG 857 instead returns a "router-to-router" redirect with the link-local 858 ISATAP address of the previous-hop EBR as its destination. The EBG 859 also includes in the redirect one or more IPv6 Link-Layer Address 860 Options (LLAOs) that contain the IPv4 ELAs of potential next-hop EBRs 861 arranged in order from highest to lowest priority (i.e., the first 862 LLAO contains the highest priority ELA and the final LLAO option 863 contains the lowest priority). The LLAOs are formatted using a 864 modified version of the form specified in ( [RFC2529], Section 5) as 865 shown in Figure 2: 867 +-------+-------+-------+-------+-------+-------+-------+-------+ 868 | Type |Length | TTL | IPv4 Address | 869 +-------+-------+-------+-------+-------+-------+-------+-------+ 871 Figure 2: VET Link-Layer Address Option Format 873 For each LLAO, the Type is set to 2 (for Target Link-Layer Address 874 Option), Length is set to 1, and IPv4 Address is set to the IPv4 ELA 875 of the next-hop EBR. TTL is set to the time in seconds that the 876 recipient may cache the ELA, where the value 65535 represents 877 infinity and the value 0 suspends forwarding through this ELA. 879 When a VET host receives an ordinay "router-to-host" redirect, it 880 processes the redirect exacly as specified in [RFC4861], Section 8. 881 When an EBR receives a "router-to-router" redirect, it discovers the 882 IPv4 ELA addresses of potential next-hop EBRs by examining the LLAOs 883 included in the redirect. The EBR then installs a FIB entry that 884 contains the /56 prefix of the destination address encoded in the 885 redirect and the list of IPv4 ELAs of potential next-hop EBRs. The 886 EBR then enables the FIB entry for forwarding to next-hop EBRs but 887 DOES NOT enable it for ingress filtering acceptance of packets from 888 next-hop EBRs (i.e., the forwarding determination is unidirectional). 890 In enterprises in which spoofing is possible, after discovering 891 potential next-hop EBRs (either through name service lookup or ICMP 892 redirect) the EBR must send authenticating credentials before 893 forwarding packets via the next-hops. To do so, the EBR must send 894 RAs over the VET interface (using SEND, if necessary) to one or more 895 of the potential next-hop EBRs with a link-local ISATAP address that 896 embeds a next-hop EBR IPv4 ELA as the destination. The RAs must 897 include a Route Information Option (RIO) [RFC4191] that contains the 898 /56 PI prefix of the original packet's source address. After sending 899 the RAs, the EBR can either enable the new FIB entry for forwarding 900 immediately or delay until it receives an explicit acknowledgement 901 that a next-hop EBR received the RA (e.g., using the SEAL explicit 902 acknowledgement mechanism - see: Section 5.5). 904 When a next-hop EBR receives the RA, it authenticates the message 905 then performs a name service lookup on the prefix in the RIO if 906 further authenticating evidence is required. If the name service 907 returns resource records that are consistent with the inner and outer 908 IP addresses of the RA, the next-hop EBR then installs the prefix in 909 the RIO in its FIB and enables the FIB entry for ingress filtering 910 but DOES NOT enable it for forwarding purposes. After an EBR sends 911 initial RAs following a redirect, it should send periodic RAs to 912 refresh the next-hop EBR's ingress filter prefix lifetimes as long as 913 traffic is flowing. 915 EBRs retain the FIB entrys created as result of an ICMP redirect 916 until all ELA TTLs expire, or until no hints of forward progress 917 through any of the associated ELAs are received. In this way, ELA 918 liveness detection exactly parallels IPv6 Neighbor Unreachability 919 Detection ([RFC4861], Section 3). 921 5.3. IPv4 Router Discovery and Prefix Registration 923 When IPv4 is used as the inner IP protocol, router discovery and 924 prefix registration exactly parallels the mechanisms specified for 925 IPv6 in Section 5.2. To support this, modifications to the ICMPv4 926 Router Advertisement [RFC1256] function to include SEND constructs, 927 and modifications to the ICMPv4 Redirect [RFC0792] function to 928 support router-to-router redirects will be specified in a future 929 document. Additionally, publications for IPv4 prefixes will be in 930 dotted-nibble format in the 'ip4.isatap.example.com' domain. For 931 example, the IPv4 prefix 192.0.2/24 would be represented as: 932 '2.0.0.0.0.c.ip4.isatap.example.com'. 934 5.4. Forwarding Packets 936 VET nodes forward packets by consulting the FIB to determine a 937 specific EBR/EBG as the next-hop router on a VET interface. When 938 multiple next-hop routers are available, VET nodes can use default 939 router preferences, routing protocol information, traffic engineering 940 configurations, etc. to select the best exit router. When there is 941 no FIB information other than ::/0 available, VET nodes can discover 942 the next-hop EBR/EBG through the mechanisms specified in Section 5.2. 944 VET interfaces encapsulate inner IP packets in any mid-layer headers 945 followed by an outer IP header according to the specific 946 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 947 next submit the encapsulated packet to the outer IP forwarding engine 948 for transmission on an underlying enterprise-interior interface. 950 For forwarding to next-hop addresses over VET interfaces that use 951 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 952 address (i.e., the IPv4 ELA of the next-hop EBR) through static 953 extraction of the IPv4 address embedded in the next-hop ISATAP 954 address. For other IP-in-IP encapsulations, determination of the 955 outer destination address is through administrative configuration or 956 through an unspecified alternate method. When there are multiple 957 candidate destination ELAs available, the VET node should only select 958 an ELA for which there is current forwarding information in the outer 959 IP protocol FIB. 961 5.5. SEAL Encapsulation 963 VET nodes should use SEAL encapsulation [I-D.templin-seal] in 964 conjunction with packet forwarding over VET interfaces to accommdate 965 path MTU diversity, to defeat source address spoofing, and to monitor 966 next-hop EBR reachability. SEAL encapsulation maintains a 967 unidirectional and monotonically-incrementing per-packet 968 identification value known as the 'SEAL_ID'. When a VET node that 969 uses SEAL encapsulation sends a SEND-protected Router Advertisement 970 (RA) or Router Solicitation (RS) message to another VET node, both 971 nodes cache the new SEAL_ID as per-tunnel state used for maintaining 972 a window of unacknowledged SEAL_IDs. 974 In terms of security, when a VET node receives an ICMP message, it 975 can confirm that the packet-in-error within the ICMP message 976 corresponds to one of its recently-sent packets by examining the 977 SEAL_ID along with source and destination addresses, etc. 978 Additionally, a next-hop EBR can track the SEAL_ID in packets 979 received from EBRs for which there is an ingress filter entry and 980 discard packets that have SEAL_ID values outside of the current 981 window. 983 In terms of next-hop reachability, an EBR can set the SEAL 984 "Acknowledgement Requested" bit in messages to receive confirmation 985 that a next-hop EBR is reachable (see also Section 5.2.4. Setting 986 the "Acknowledgement Requested" bit is also used as the method for 987 maintaining the window of outstanding SEAL_ID's. 989 5.6. Generating Errors 991 When an EBR receives a packet over a VET interface and there is no 992 matching ingress filter entry, it drops the packet and returns an 993 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 994 ingress/egress policy" message to the previous hop EBR subject to 995 rate limiting. 997 When an EBR receives a packet over a VET interface, and there is no 998 longest-prefix-match FIB entry for the destination, it returns an 999 ICMPv6 "Destination Unreachable; No route to destination" message to 1000 the previous hop EBR subject to rate limiting. 1002 When an EBR receives a packet over a VET interface and the longest- 1003 prefix-match FIB entry for the destination is configured over the 1004 same VET interface the packet arrived on, the EBR forwards the packet 1005 then (if the FIB prefix is longer than ::/0) sends a router-to-router 1006 ICMPv6 Redirect message (using SEND, if necessary) to the previous 1007 hop EBR as specified in Section 5.2.4. 1009 Generation of other ICMPv6 messages (e.g., ICMPv6 "Packet Too Big") 1010 is the same as for any IPv6 interface. 1012 5.7. Processing Errors 1014 When an EBR receives an ICMPv6 "Destination Unreachable; Source 1015 address failed ingress/egress policy" message from a next-hop EBR, 1016 and there is a longest-prefix-match FIB entry for the original 1017 packet's destination that is more-specific than ::/0, the EBR 1018 discards the message and marks the FIB entry for the destination as 1019 "forwarding suspended" for the ELA taken from the source address of 1020 the ICMPv6 message. The EBR should then allow subsequent packets to 1021 flow through different ELAs associated with the FIB entry until it 1022 forwards a new RA to the suspended ELA. If the EBR receives 1023 excessive ICMPv6 ingress policy errors through multiple ELAs 1024 associated with the same FIB entry, it should delete the FIB entry 1025 and allow subsequent packets to flow through an EBG if supported in 1026 the specific enterprise scenario. 1028 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1029 to destination" message from a next-hop EBR, it forwards the ICMPv6 1030 message to the source of the original packet as normal. If the EBR 1031 has longest-prefix-match FIB entry for the original packet's 1032 destination that is more-specific than ::/0, the EBR also deletes the 1033 FIB entry. 1035 When an EBR receives an authentic ICMPv6 Redirect, it processes the 1036 packet as specified in Section 5.2.4. 1038 When an EBG receives new mapping information for a specific 1039 destination prefix, it can propagate the update to other EBRs/EBGs by 1040 sending an ICMPv6 redirect message to the 'All Routers' link-local 1041 multicast address with a LLAO with the TTL for the unreachable LLAO 1042 set to zero, and with a NULL packet in error. 1044 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 1045 Unreachable; net / host unreachable" messages from an ER indicating 1046 that the path to a VET neighbor may be failing. The EBR should first 1047 check authenticating information in the message (e.g., the SEAL_ID, 1048 IPsec sequence number, source address of the original packet if 1049 available, etc.) before accepting it, then should mark the longest- 1050 prefix-match FIB entry for the destination as "forwarding suspended" 1051 for the ELA destination address of the ICMPv4 packet-in-error. If 1052 the EBR receives excessive ICMPv4 unreachable errors through multiple 1053 ELAs associated with the same FIB entry, it should delete the FIB 1054 entry and allow subsequent packets to flow through a different route. 1056 5.8. Mobility and Multihoming Considerations 1058 EBRs that travel between distinct enterprise networks must either 1059 abandon their PA prefixes that are relative to the "old" enterprise 1060 and obtain new ones relative to the "new" enterprise, or somehow 1061 coordinate with a "home" enterprise to retain ownership of the 1062 prefixes. In the first instance, the EBR would be required to 1063 coordinate a network renumbering event using the new PA prefixes 1064 [RFC4192]. In the second instance, an ancillary mobilitiy management 1065 mechanism must be used. 1067 EBRs can retain their PI prefixes as they travel between distinct 1068 enterprise networks as long as they register the prefixes with new 1069 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 1070 departure. Prefix registration with new EBGs is coordinated exactly 1071 as specified in Section 5.2.3; prefix withdrawl from old EBGs is 1072 simply through re-announcing the PI prefixes with zero lifetimes. 1074 Since EBRs can move about independently of one another, stale FIB 1075 entry state may be left in VET nodes when a neighboring EBR departs. 1076 Additionally, EBRs can lose state for various reasons, e.g., power 1077 failure, machine reboot, etc. For this reason, EBRs are advised to 1078 set relatively short PI prefix lifetimes in RIO options, and to send 1079 additional RAs to refresh lifetimes before they expire. (EBRs should 1080 place conservative limits on the RAs they send to reduce congestion, 1081 however.) 1083 EBRs may register their PI prefixes with multiple EBGs for 1084 multihoming purposes. EBRs should only forward packets via EBGs with 1085 which it has registered its PI prefixes, since other EBGs may drop 1086 the packets and return ICMPv6 "Destination Unreachable; Source 1087 address failed ingress/egress policy" messages. 1089 EBRs can also act as delegating routers to sub-delegate portions of 1090 their PI prefixes to requesting routers on their enterprise edge 1091 interfaces and on VET interfaces for which they are configured as 1092 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1093 become the PA prefixes for downstream-dependent nodes. Downstream- 1094 dependent nodes that travel with a mobile provider EBR can continue 1095 to use addresses configured from PA prefixes; downstream-dependent 1096 nodes that move away from their provider EBR must perform address/ 1097 prefix renumbering when they assocate with a new provider. 1099 The EBGs of a multi-homed enterprise should participate in a private 1100 inner IP routing protocol instance between themselves (possibly over 1101 an alternate topology) to accommodate enterprise partitions/merges as 1102 well as intra-enterprise mobility events. These peer EBGs should 1103 accept packets from one another without respect to the destination 1104 (i.e., ingress filtering is based on the peering relationship rather 1105 than a prefix-specific ingress filter entry). 1107 5.9. Enterprise-Local Communications 1109 When permitted by policy, end systems that configure the endpoints of 1110 enterprise-local communications can avoid VET interface encapsulation 1111 by directly invoking the outer IP protocol using ELAs assigned to 1112 their enterprise-interior interfaces. For example, when the outer 1113 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 1114 communications over their enterprise-interior interfaces without 1115 using encapsulation. 1117 5.10. Multicast 1119 In multicast-capable deployments, ERs provide an enterprise-wide 1120 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1121 [I-D.ietf-manet-smf], PIM routing, DVMRP routing, etc.) over their 1122 enterprise-interior interfaces such that outer IP multicast messages 1123 of site- or greater scope will be propagated across the enterprise. 1124 For such deployments, VET nodes can also provide an inner IP 1125 multicast/broadcast capability over their VET interfaces through 1126 mapping of the inner IP multicast address space to the outer IP 1127 multicast address space. In that case, operation of link- or greater 1128 scoped inner IP multicasting services (e.g., a link-scoped neighbor 1129 discovery protocol) over the VET interface is available, but link- 1130 scoped services should be used sparingly to minimize enterprise-wide 1131 flooding. 1133 VET nodes encapsulate inner IP multicast messages sent over the VET 1134 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1135 outer IP header with a site-scoped outer IP multicast address as the 1136 destination. For the case of IPv6 and IPv4 as the inner/outer 1137 protocols (respectively), [RFC2529] provides mappings from the IPv6 1138 multicast address space to a site-scoped IPv4 multicast address space 1139 (for other IP-in-IP encapsulations, mappings are established through 1140 administrative configuration or through an unspecified alternate 1141 static mapping). 1143 Multicast mapping for inner IP multicast groups over outer IP 1144 multicast groups can be accommodated, e.g. through VET interface 1145 snooping of inner multicast group membership and routing protocol 1146 control messages. To support inner-to-outer IP multicast mappinging, 1147 the VET interface acts as a virtual outer IP multicast host connected 1148 to its underlying enterprise-interior interfaces. When the VET 1149 interface detects inner IP multicast group joins or leaves, it 1150 forwards corresponding outer IP multicast group membership reports 1151 for each enterprise-interior interface over which the VET interface 1152 is configured. If the VET node is configured as an outer IP 1153 multicast router on the underlying enterprise-interior interfaces, 1154 the VET interface forwards locally looped-back group membership 1155 reports to the outer IP multicast routing process. If the VET node 1156 is configued as a simple outer IP multicast host, the VET interface 1157 instead fowards actual group membership reports (e.g., IGMP messages) 1158 directly over each of the underlying enterprise-interior interfaces. 1160 Since inner IP multicast groups are mapped to site-scoped outer IP 1161 multicast groups, the VET node must ensure that the site-scope outer 1162 IP multicast messages received on the enterprise-interior interfaces 1163 for one VET interface do not "leak out" to the enterprise-interior 1164 interfaces of another VET interface. This is accomodated through 1165 normal site-scoped outer IP multicast group filtering at enterprise- 1166 interior interface boundaries. 1168 5.11. Service Discovery 1170 VET nodes can peform enterprise-wide service discovery using a 1171 suitable name-to-address resolution service. Examples of flooding- 1172 based services include the use of LLMNR [RFC4759] over the VET 1173 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1174 underlying enterprise-interior interface. More scalable and 1175 efficient service discovery mechanisms are for further study. 1177 5.12. Enterprise Partitioning 1179 EBGs can physically partition an enterprise by configuring multiple 1180 VET interfaces over multiple distinct sets of underlying interfaces. 1181 In that case, each partition (i.e., each VET interface) must 1182 configure its own distinct 'PRLNAME' (e.g., 1183 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1185 EBGs can logically partition an enterprise using a single VET 1186 interface by sending RAs with PIOs containing different IPv6 PA 1187 prefixes to group nodes into different logical partitions. EBGs can 1188 identify partitions, e.g., by examining IPv4 ELA prefixes, observing 1189 the interfaces over which RSs are received, etc. In that case, a 1190 single 'PRLNAME' can cover all partitions. 1192 5.13. EBG Prefix State Recovery 1194 EBGs must retain explicit state that tracks the inner IP prefixes 1195 owned by EBRs within the enterprise, e.g., so that packets are 1196 delivered to the correct EBRs and not incorrectly "leaked out" of the 1197 enterprise via a default route. For PA prefixes the state is 1198 maintained via an EBR's DHCP prefix delegation lease renewals, while 1199 for PI prefixes the state is maintained via an EBR's periodic prefix 1200 registration RAs. 1202 When an EBG loses some or all of its state (e.g., due to a power 1203 failure), it must recover the state before allowing packets to flow 1204 over incorrect routes. If the EBG aggregates PA prefixes from which 1205 the IP prefixes of all EBRs in the enterprise are sub-delegated, then 1206 the EBG can recover state through DHCP prefix delegation lease 1207 renewals, through bulk lease queries, or through on-demand name 1208 service lookups based due to IP packet forwarding. If the EBG serves 1209 as an anchor for PI prefixes, however, care must be taken to avoid 1210 looping while state is recovered through prefix registration RAs from 1211 EBRs. In that case, when the EBG that is recovering state forwards 1212 an IP packet for which it has no explicit route other than ::/0, it 1213 must first perform an on-demand name service lookup to refresh state. 1215 6. IANA Considerations 1217 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1218 DHCPv4 server discovery is requested. The allocation should be taken 1219 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1220 the IANA 'multicast-addresses' registry. 1222 7. Security Considerations 1224 Security considerations for MANETs are found in [RFC2501]. 1226 Security considerations with tunneling that apply also to VET are 1227 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1228 that the outer IP source address of a packet received on a VET 1229 interface is correct for the inner IP source address using the 1230 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1231 the ingress filtering mechanisms specified in this document. 1233 SEND [RFC3971], IPsec [RFC4301] and SEAL Section 5.5 provide 1234 additional securing mitigations to detect source address spoofing and 1235 bogus RA messages sent by rogue routers. 1237 Rogue routers can send bogus RA messages with spoofed ELA source 1238 addresses that can consume network resources and cause EBGs to 1239 perform extra work. Nonetheless, EBGs should not "blacklist" such 1240 ELAs, as that may result in a denial of service to the ELAs' 1241 legitimate owners. 1243 8. Related Work 1245 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1246 automatic tunneling in [RFC2529]; this concept was later called: 1247 "Virtual Ethernet" and investigated by Quang Nguyen under the 1248 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1249 their colleagues have motivated a number of foundational concepts on 1250 which this work is based. 1252 Telcordia has proposed DHCP-related solutions for MANETs through the 1253 CECOM MOSAIC program. 1255 The Naval Research Lab (NRL) Information Technology Division uses 1256 DHCP in their MANET research testbeds. 1258 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 1259 pertaining to tunneling mechanisms. 1261 An automated IPv4 prefix delegation mechanism is proposed in 1262 [I-D.ietf-dhc-subnet-alloc]. 1264 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1266 Various proposals within the IETF have suggested similar mechanisms. 1268 9. Acknowledgements 1270 The following individuals gave direct and/or indirect input that was 1271 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Scott 1272 Brim, Brian Carpenter, James Bound, Thomas Clausen, Claudiu Danilov, 1273 Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, Bob Hinden, 1274 Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David 1275 Meyer, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru Petrescu, 1276 John Spence, Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela 1277 Vanderveen, Lixia Zhang and others in the IETF AUTOCONF and MANET 1278 working groups. Many others have provided guidance over the course 1279 of many years. 1281 10. Contributors 1283 The following individuals have contributed to this document: 1285 Eric Fleischman (eric.fleischman@boeing.com) 1286 Thomas Henderson (thomas.r.henderson@boeing.com) 1287 Steven Russert (steven.w.russert@boeing.com) 1288 Seung Yi (seung.yi@boeing.com) 1290 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1291 of the document. 1293 11. References 1295 11.1. Normative References 1297 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1298 September 1981. 1300 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1301 RFC 792, September 1981. 1303 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1304 converting network protocol addresses to 48.bit Ethernet 1305 address for transmission on Ethernet hardware", STD 37, 1306 RFC 826, November 1982. 1308 [RFC1035] Mockapetris, P., "Domain names - implementation and 1309 specification", STD 13, RFC 1035, November 1987. 1311 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1312 RFC 2131, March 1997. 1314 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1315 (IPv6) Specification", RFC 2460, December 1998. 1317 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1318 Update", RFC 3007, November 2000. 1320 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1321 and M. Carney, "Dynamic Host Configuration Protocol for 1322 IPv6 (DHCPv6)", RFC 3315, July 2003. 1324 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1325 "DNS Extensions to Support IP Version 6", RFC 3596, 1326 October 2003. 1328 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1329 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1330 December 2003. 1332 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1333 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1335 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1336 RFC 3972, March 2005. 1338 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1339 More-Specific Routes", RFC 4191, November 2005. 1341 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1342 Architecture", RFC 4291, February 2006. 1344 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1345 Message Protocol (ICMPv6) for the Internet Protocol 1346 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1348 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1349 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1350 September 2007. 1352 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1353 Address Autoconfiguration", RFC 4862, September 2007. 1355 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1356 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1357 March 2008. 1359 11.2. Informative References 1361 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1362 Switching Networks", May 1974. 1364 [I-D.cheshire-dnsext-multicastdns] 1365 Cheshire, S. and M. Krochmal, "Multicast DNS", 1366 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1367 September 2008. 1369 [I-D.clausen-manet-linktype] 1370 Clausen, T., "The MANET Link Type", 1371 draft-clausen-manet-linktype-00 (work in progress), 1372 October 2008. 1374 [I-D.ietf-autoconf-manetarch] 1375 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1376 Network Architecture", draft-ietf-autoconf-manetarch-07 1377 (work in progress), November 2007. 1379 [I-D.ietf-csi-proxy-send] 1380 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1381 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1382 in progress), November 2008. 1384 [I-D.ietf-dhc-subnet-alloc] 1385 Johnson, R., "Subnet Allocation Option", 1386 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1387 July 2008. 1389 [I-D.ietf-ipv6-ula-central] 1390 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1391 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1392 progress), June 2007. 1394 [I-D.ietf-manet-smf] 1395 Macker, J. and S. Team, "Simplified Multicast Forwarding 1396 for MANET", draft-ietf-manet-smf-08 (work in progress), 1397 November 2008. 1399 [I-D.ietf-v6ops-tunnel-security-concerns] 1400 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1401 Concerns With IP Tunneling", 1402 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1403 progress), October 2008. 1405 [I-D.jen-apt] 1406 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1407 L. Zhang, "APT: A Practical Transit Mapping Service", 1408 draft-jen-apt-01 (work in progress), November 2007. 1410 [I-D.templin-seal] 1411 Templin, F., "The Subnetwork Encapsulation and Adaptation 1412 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1413 August 2008. 1415 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1416 July 1978. 1418 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1419 Protocol Specification", October 2008. 1421 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1422 Communication Layers", STD 3, RFC 1122, October 1989. 1424 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1425 September 1991. 1427 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1428 Routing and Addressing Architecture", RFC 1753, 1429 December 1994. 1431 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1432 E. Lear, "Address Allocation for Private Internets", 1433 BCP 5, RFC 1918, February 1996. 1435 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1436 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1438 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1439 (MANET): Routing Protocol Performance Issues and 1440 Evaluation Considerations", RFC 2501, January 1999. 1442 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1443 Domains without Explicit Tunnels", RFC 2529, March 1999. 1445 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1446 February 2000. 1448 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1449 via IPv4 Clouds", RFC 3056, February 2001. 1451 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1452 Networks", BCP 84, RFC 3704, March 2004. 1454 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1455 RFC 3753, June 2004. 1457 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1458 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1459 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1460 RFC 3819, July 2004. 1462 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1463 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1464 May 2005. 1466 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1467 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1468 September 2005. 1470 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1471 Addresses", RFC 4193, October 2005. 1473 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1474 Internet Protocol", RFC 4301, December 2005. 1476 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1477 Network Address Translations (NATs)", RFC 4380, 1478 February 2006. 1480 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1481 Proxies (ND Proxy)", RFC 4389, April 2006. 1483 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1484 Indicator Parameter for the "tel" URI", RFC 4759, 1485 December 2006. 1487 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1488 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1489 Focus", RFC 4852, April 2007. 1491 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1492 June 2007. 1494 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1495 Extensions for Stateless Address Autoconfiguration in 1496 IPv6", RFC 4941, September 2007. 1498 Appendix A. Duplicate Address Detection (DAD) Considerations 1500 A-priori uniqueness determination (also known as "pre-service DAD") 1501 for an ELA assigned on an enterprise-interior interface would require 1502 either flooding the entire enterprise or somehow discovering a link 1503 in the enterprise on which a node that configures a duplicate address 1504 is attached and performing a localized DAD exchange on that link. 1505 But, the control message overhead for such an enterprise-wide DAD 1506 would be substantial and prone to false-negatives due to packet loss 1507 and intermittent connectivity. An alternative to pre-service DAD is 1508 to autoconfigure pseudo-random ELAs on enterprise-interior interfaces 1509 and employ a passive in-service DAD (e.g., one that monitors routing 1510 protocol messages for duplicate assignments). 1512 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1513 CGAs, IPv6 privacy addresses, etc. with very small probability of 1514 collision. Pseudo-random IPv4 ELAs can be generated through random 1515 assignment from a suitably large IPv4 prefix space. 1517 Consistent operational practices can assure uniqueness for EBG- 1518 aggregated addresses/prefixes, while statistical properties for 1519 pseudo-random address self-generation can assure uniqueness for the 1520 ELAs assigned on an ER's enterprise-interior interfaces. Still, an 1521 ELA delegation authority should be used when available, while a 1522 passive in-service DAD mechanism should be used to detect ELA 1523 duplications when there is no ELA delegation authority. 1525 Appendix B. Change Log 1527 (Note to RFC editor - this section to be removed before publication 1528 as an RFC.) 1530 Changes from -33 to 34: 1532 o Enterprise management models described 1534 o Enterprise security models described 1536 o Clarification of mechanisms based on enterprise management/ 1537 security models 1539 Changes from -32 to 33:: 1541 o Secure Neighbor Discovery Proxy 1543 Changes from -28 to 29: 1545 o Updates on processing/receiving errors. 1547 Changes from -27 to 28: 1549 o Introduced concept of a default mapper. 1551 Changes from -26 to 27: 1553 o Introduced new model for PI prefix management. 1555 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1556 "isado"?) 1558 Changes from -25 to 26: 1560 o Clarifications on Router Discovery and Ingress FIltering. 1562 o Mechanisms for detecting locator liveness 1564 o Mechanisms for avoiding state synchonization requirements. 1566 Changes from -23 to 24: 1568 o Clarifications on router discovery. 1570 Changes from -22 to 23: 1572 o Clarifications on prefix mapping. 1574 Changes from -21 to 22: 1576 o Using SEAL to secure VET 1578 Changes from -20 to 21: 1580 o Enterprise partitioning. 1582 o Mapping and name service management. 1584 Changes from -18 to 20: 1586 o Added support for simple hosts. 1588 o Added EBG name service maintenace procedures 1590 o Added router and prefix maintenace procedures 1592 Changes from -17 to 18: 1594 o adjusted section headings to group autoconf operations under EIR/ 1595 EBR/EBG. 1597 o clarified M/O bits 1599 o clarified EBG roles 1601 Changes from -15 to 17: 1603 o title change to "Virtual Enterprise Traversal (VET)". 1605 o changed document focus from MANET-centric to the much-broader 1606 Enterprise-centric, where "Enterprise" is understood to also cover 1607 a wide range of MANET types. 1609 Changes from -14 to 15: 1611 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1613 o Address review comments 1615 Changes from -12 to 14: 1617 o title change to "The MANET Virtual Ethernet Abstraction". 1619 o Minor section rearrangement. 1621 o Clartifications on portable and self-configured prefixes. 1623 o Clarifications on DHCPv6 prefix delegation procedures. 1625 Changes from -11 to 12: 1627 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1629 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1630 delegation mechanism. 1632 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1634 o fixed editorials based on comments received. 1636 Changes from -10 to 11: 1638 o removed the transparent/opaque VET portal abstractions. 1640 o removed routing header as an option for MANET exit router 1641 selection. 1643 o included IPv6 SLAAC as an endorsed address configuration mechanism 1644 for the VET interface. 1646 Changes from -08 to -09: 1648 o Introduced the term "VET". 1650 o Changed address delegation language to speak of "MNBR-aggregated" 1651 instead of global/local. 1653 o Updated figures 1-3. 1655 o Explained why a MANET interface is "neutral". 1657 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1658 DHCPv4 servers; not relays. 1660 Changes from -07 to -08: 1662 o changed terms "unenhanced" and "enhanced" to "transparent" and 1663 "opaque". 1665 o revised MANET Router diagram. 1667 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1668 interface. 1670 o changed abbreviations to "MNR" and "MNBR". 1672 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1674 o rearranged Section 3.1. 1676 o various minor text cleanups 1678 Changes from -06 to -07: 1680 o added MANET Router diagram. 1682 o added new references 1684 o various minor text cleanups 1686 Changed from -05 to -06: 1688 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1690 o minor changes to preserve generality 1692 Changed from -04 to -05: 1694 o introduced conceptual "virtual ethernet" model. 1696 o support "raw" and "cooked" modes as equivalent access methods on 1697 the virutal ethernet. 1699 Changed from -03 to -04: 1701 o introduced conceptual "imaginary shared link" as a representation 1702 for a MANET. 1704 o discussion of autonomous system and site abstractions for MANETs 1706 o discussion of autoconfiguration of CGAs 1708 o new appendix on IPv6 StateLess Address AutoConfiguration 1710 Changes from -02 to -03: 1712 o updated terminology based on RFC2461 "asymmetric reachability" 1713 link type; IETF67 MANET Autoconf wg discussions. 1715 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1716 Address Detection 1718 o relaxed DHCP server deployment considerations allow DHCP servers 1719 within the MANET itself 1721 Changes from -01 to -02: 1723 o minor updates for consistency with recent developments 1725 Changes from -00 to -01: 1727 o new text on DHCPv6 prefix delegation and multilink subnet 1728 considerations. 1730 o various editorial changes 1732 Author's Address 1734 Fred L. Templin (editor) 1735 Boeing Research and Technology 1736 P.O. Box 3707 MC 7L-49 1737 Seattle, WA 98124 1738 USA 1740 Email: fltemplin@acm.org