idnits 2.17.1 draft-templin-intarea-vet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2009) is 5415 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1481, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1565, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1571, 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) ** Downref: Normative reference to an Informational RFC: RFC 5214 == 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-09 == 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 == Outdated reference: A later version (-05) exists of draft-russert-rangers-00 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-04 == Outdated reference: A later version (-09) exists of draft-templin-ranger-07 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 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 & Technology 4 Intended status: Standards Track June 29, 2009 5 Expires: December 31, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-00.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 December 31, 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Enterprise networks connect routers over various link types, and may 47 also connect to provider networks and/or the global Internet. 48 Enterprise network nodes require a means to automatically provision 49 IP addresses/prefixes and support internetworking operation in a wide 50 variety of use cases including Small Office, Home Office (SOHO) 51 networks, Mobile Ad hoc Networks (MANETs), multi-organizational 52 corporate networks and the interdomain core of the global Internet 53 itself. This document specifies a Virtual Enterprise Traversal (VET) 54 abstraction for autoconfiguration and operation of nodes in 55 enterprise networks. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 10 62 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 63 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 12 64 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 13 65 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 13 66 4.2.2. Provider-Aggregated (PA) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 15 68 4.2.3. Provider-Independent (PI) EID Prefix 69 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 70 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 17 71 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 17 72 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 18 73 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 18 74 5.2. RLOC-Based Communications . . . . . . . . . . . . . . . . 18 75 5.3. EID-Based Communications . . . . . . . . . . . . . . . . . 18 76 5.4. IPv6 Router Discovery and Prefix Registration . . . . . . 18 77 5.4.1. IPv6 Router and Prefix Discovery . . . . . . . . . . . 18 78 5.4.2. IPv6 PA Prefix Registration . . . . . . . . . . . . . 19 79 5.4.3. IPv6 PI Prefix Registration . . . . . . . . . . . . . 20 80 5.4.4. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . 21 81 5.5. IPv4 Router Discovery and Prefix Registration . . . . . . 23 82 5.6. VET Encapsulation . . . . . . . . . . . . . . . . . . . . 24 83 5.7. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 24 84 5.8. Generating Errors . . . . . . . . . . . . . . . . . . . . 25 85 5.9. Processing Errors . . . . . . . . . . . . . . . . . . . . 25 86 5.10. Mobility and Multihoming Considerations . . . . . . . . . 26 87 5.11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 27 88 5.12. Service Discovery . . . . . . . . . . . . . . . . . . . . 28 89 5.13. Enterprise Partitioning . . . . . . . . . . . . . . . . . 28 90 5.14. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 29 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 99 Appendix A. Duplicate Address Detection (DAD) Considerations . . 36 100 Appendix B. Link Layer Multiplexing and Traffic Engineering . . . 36 101 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 104 1. Introduction 106 Enterprise networks [RFC4852] connect routers over various link types 107 (see [RFC4861], Section 2.2). The term "enterprise network" in this 108 context extends to a wide variety of use cases and deployment 109 scenarios. For example, an "enterprise" can be as small as a SOHO 110 network, as complex as a multi-organizational corporation, or as 111 large as the global Internet itself. Mobile Ad hoc Networks (MANETs) 112 [RFC2501] can also be considered as a challenging example of an 113 enterprise network, in that their topologies may change dynamically 114 over time and that they may employ little/no active management by a 115 centralized network administrative authority. These specialized 116 characteristics for MANETs require careful consideration, but the 117 same principles apply equally to other enterprise network scenarios. 119 This document specifies a Virtual Enterprise Traversal (VET) 120 abstraction for autoconfiguration and internetworking operation, 121 where addresses of different scopes may be assigned on various types 122 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 123 [RFC2460] are discussed within this context. The use of standard 124 DHCP [RFC2131] [RFC3315] and neighbor discovery [RFC0826] [RFC1256] 125 [RFC4861] mechanisms is assumed unless otherwise specified. 127 Provider-Edge Interfaces 128 x x x 129 | | | 130 +--------------------+---+--------+----------+ E 131 | | | | | n 132 | I | | .... | | t 133 | n +---+---+--------+---+ | e 134 | t | +--------+ /| | r 135 | e I x----+ | Host | I /*+------+--< p I 136 | r n | |Function| n|**| | r n 137 | n t | +--------+ t|**| | i t 138 | a e x----+ V e|**+------+--< s e 139 | l r . | E r|**| . | e r 140 | f . | T f|**| . | f 141 | V a . | +--------+ a|**| . | I a 142 | i c . | | Router | c|**| . | n c 143 | r e x----+ |Function| e \*+------+--< t e 144 | t s | +--------+ \| | e s 145 | u +---+---+--------+---+ | r 146 | a | | .... | | i 147 | l | | | | o 148 +--------------------+---+--------+----------+ r 149 | | | 150 x x x 151 Enterprise-Edge Interfaces 153 Figure 1: Enterprise Router (ER) Architecture 155 Figure 1 above depicts the architectural model for an Enterprise 156 Router (ER). As shown in the figure, an ER may have a variety of 157 interface types including enterprise-edge, enterprise-interior, 158 provider-edge, internal-virtual, as well as VET interfaces used for 159 IP-in-IP encapsulation. The different types of interfaces are 160 defined, and the autoconfiguration mechanisms used for each type are 161 specified. This architecture applies equally for MANET routers, in 162 which enterprise-interior interfaces correspond to the wireless 163 multihop radio interfaces typically associated with MANETs. Out of 164 scope for this document is the autoconfiguration of provider 165 interfaces, which must be coordinated in a manner specific to the 166 service provider's network. 168 Enterprise networks must have a means for supporting both Provider- 169 Independent (PI) and Provider-Aggregated (PA) IP prefixes. This is 170 especially true for enterprise scenarios that involve mobility and 171 multihoming. Also in scope are ingress filtering for multihomed 172 sites, adaptation based on authenticated ICMP feedback from on-path 173 routers, effective tunnel path MTU mitigations, and routing scaling 174 suppression as required in many enterprise network scenarios. 176 Recognizing that one size does not fit all, the VET specification 177 provides adaptable mechanisms that address these issues, and more, in 178 a wide variety of enterprise network use cases. 180 VET represents a functional superset of 6over4 [RFC2529] and Intra- 181 Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and it 182 further supports additional encapsulations such as IPsec [RFC4301], 183 Subnetwork Encapsulation and Adaptation Layer (SEAL) 184 [I-D.templin-intarea-seal], etc. Together, these technologies serve 185 as functional building blocks for a new Internetworking architecture 186 known as Routing and Addressing in Next Generation EnteRprises 187 [I-D.templin-ranger] [I-D.russert-rangers]. 189 The VET principles can be either directly or indirectly traced to the 190 deliberations of the ROAD group in January 1992, and also to still 191 earlier works including NIMROD [RFC1753], the Catenet model for 192 internetworking [CATENET] [IEN48] [RFC2775], etc. [RFC1955] captures 193 the high-level architectural aspects of the ROAD group deliberations 194 in a "New Scheme for Internet Routing and Addressing (ENCAPS) for 195 IPNG". 197 VET is related to the present-day activities of the IETF INTAREA, 198 AUTOCONF, DHC, IPv6, MANET, and v6OPS working groups, as well as the 199 IRTF RRG working group. 201 2. Terminology 203 The mechanisms within this document build upon the fundamental 204 principles of IP-in-IP encapsulation. The terms "inner" and "outer" 205 are used to, respectively, refer to the innermost IP {address, 206 protocol, header, packet, etc.} *before* encapsulation, and the 207 outermost IP {address, protocol, header, packet, etc.} *after* 208 encapsulation. VET also allows for inclusion of "mid-layer" 209 encapsulations between the inner and outer layers, including IPSec 210 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 211 [I-D.templin-intarea-seal], etc. 213 The terminology in the normative references apply; the following 214 terms are defined within the scope of this document: 216 subnetwork 217 the same as defined in [RFC3819]. 219 enterprise 220 the same as defined in [RFC4852]. An enterprise is also 221 understood to refer to a cooperative networked collective with a 222 commonality of business, social, political, etc. interests. 224 Minimally, the only commonality of interest in some enterprise 225 network scenarios may be the cooperative provisioning of 226 connectivity itself. 228 site 229 a logical and/or physical grouping of interfaces that connect a 230 topological area less than or equal to an enterprise in scope. A 231 site within an enterprise can, in some sense, be considered as an 232 enterprise unto itself. 234 Mobile Ad hoc Network (MANET) 235 a connected topology of mobile or fixed routers that maintain a 236 routing structure among themselves over dynamic links, where a 237 wide variety of MANETs share common properties with enterprise 238 networks. The characteristics of MANETs are defined in [RFC2501], 239 Section 3. 241 enterprise/site/MANET 242 throughout the remainder of this document, the term "enterprise" 243 is used to collectively refer to any of {enterprise, site, MANET}, 244 i.e., the VET mechanisms and operational principles can be applied 245 to enterprises, sites, and MANETs of any size or shape. 247 Enterprise Router (ER) 248 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 249 mobile router that comprises a router function, a host function, 250 one or more enterprise-interior interfaces, and zero or more 251 internal virtual, enterprise-edge, provider-edge, and VET 252 interfaces. At a minimum, an ER forwards outer IP packets over 253 one or more sets of enterprise-interior interfaces, where each set 254 connects to a distinct enterprise. 256 Enterprise Border Router (EBR) 257 an ER that connects edge networks to the enterprise and/or 258 connects multiple enterprises together. An EBR is a tunnel 259 endpoint router, and it configures a separate VET interface over 260 each set of enterprise-interior interfaces that connect the EBR to 261 each distinct enterprise. In particular, an EBR may configure 262 multiple VET interfaces - one for each distinct enterprise. All 263 EBRs are also ERs. 265 Enterprise Border Gateway (EBG) 266 an EBR that connects VET interfaces configured over child 267 enterprises to a provider network - either directly via a 268 provider-edge interface or indirectly via another VET interface 269 configured over a parent enterprise. EBRs may act as EBGs on some 270 VET interfaces and as ordinary EBRs on other VET interfaces. All 271 EBGs are also EBRs. 273 enterprise-interior interface 274 an ER's attachment to a link within an enterprise. Packets sent 275 over enterprise-interior interfaces may be forwarded over multiple 276 additional enterprise-interior interfaces within the enterprise 277 before they are forwarded via an enterprise-edge interface, 278 provider-edge interface, or a VET interface configured over a 279 different enterprise. Enterprise-interior interfaces connect 280 laterally within the IP network hierarchy. 282 enterprise-edge interface 283 an EBR's attachment to a link (e.g., an Ethernet, a wireless 284 personal area network, etc.) on an arbitrarily complex edge 285 network that the EBR connects to an enterprise and/or provider 286 network. Enterprise-edge interfaces connect to lower levels 287 within the IP network hierarchy. 289 provider-edge interface 290 an EBR's attachment to the Internet or to a provider network 291 outside of the enterprise via which the Internet can be reached. 292 Provider-edge interfaces connect to higher levels within the IP 293 network hierarchy. 295 internal-virtual interface 296 an interface that is internal to an EBR and does not in itself 297 directly attach to a tangible physical link, e.g., an Ethernet 298 cable. Examples include a loopback interface, a virtual LAN 299 interface, or some form of tunnel interface. 301 Virtual Enterprise Traversal (VET) 302 an abstraction that uses IP-in-IP encapsulation to create an 303 overlay that spans an enterprise in a single (inner) IP hop. 305 VET interface 306 an EBR's tunnel virtual interface used for Virtual Enterprise 307 Traversal. The EBR configures a VET interface over a set of 308 underlying interfaces belonging to the same enterprise. When 309 there are multiple distinct enterprises (each with their own 310 distinct set of underlying interfaces), the EBR configures a 311 separate VET interface over each set of underlying interfaces, 312 i.e., the EBR configures multiple VET interfaces. 314 The VET interface encapsulates each inner IP packet in any mid- 315 layer headers plus an outer IP header, then it forwards it on an 316 underlying interface such that the Time to Live (TTL) - Hop Limit 317 in the inner header is not decremented as the packet traverses the 318 enterprise. The VET interface therefore presents an automatic 319 tunneling abstraction that represents the enterprise as a single 320 IP hop. 322 VET interfaces in non-multicast environments are Non-Broadcast, 323 Multiple Access (NBMA); VET interfaces in multicast environments 324 are multicast capable. 326 VET host 327 any node (host or router) that configures a VET interface for host 328 operation only. Note that a single node may configure some of its 329 VET interfaces as host interfaces and others as router interfaces. 331 VET node 332 any node that configures and uses a VET interface. 334 Provider-Independent (PI) prefix 335 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 336 that is either self-generated by an ER or delegated to an 337 enterprise by a registry. 339 Provider Aggregated (PA) prefix 340 an IPv6 or IPv4 prefix that is delegated to an enterprise by a 341 provider network. 343 Routing Locator (RLOC) 344 a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix 345 that can appear in enterprise-interior and/or interdomain routing 346 tables. Global-scope RLOC prefixes are delegated to specific 347 enterprises and routable within both the enterprise-interior and 348 interdomain routing regions. Enterprise-local-scope RLOC prefixes 349 (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 privacy 350 addresses [RFC1918], etc.) are self-generated by individual 351 enterprises and routable only within the enterprise-interior 352 routing region. 354 ERs use RLOCs for operating the enterprise-interior routing 355 protocol and for next-hop determination in forwarding packets 356 addressed to other RLOCs. End systems use RLOCs as addresses for 357 communications between endpoints within the same enterprise. VET 358 interfaces treat RLOCs as *outer* IP addresses during IP-in-IP 359 encapsulation. 361 Endpoint Interface iDentifier (EID) 362 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 363 within an enterprise-edge or VET overlay network scope, and may 364 also appear in enterprise-interior and/or interdomain mapping 365 tables. EID prefixes are typically separate and distinct from any 366 RLOC prefix space. 368 Edge network routers use EIDs for operating the enterprise-edge or 369 VET overlay network routing protocol and for next-hop 370 determination in forwarding packets addressed to other EIDs. End 371 systems use EIDs as addresses for communications between endpoints 372 either within the same enterprise or within different enterprises. 373 VET interfaces treat EIDs as *inner* IP addresses during IP-in-IP 374 encapsulation. 376 The following additional acronyms are used throughout the document: 378 CGA - Cryptographically Generated Address 379 DHCP(v4, v6) - Dynamic Host Configuration Protocol 380 FIB - Forwarding Information Base 381 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 382 NBMA - Non-Broadcast, Multiple Access 383 ND - Neighbor Discovery 384 PIO - Prefix Information Option 385 PRL - Potential Router List 386 PRLNAME - Identifying name for the PRL (default is "isatap") 387 RIO - Route Information Option 388 RS/RA - IPv6 ND Router Solicitation/Advertisement 389 SEAL - Subnetwork Encapsulation and Adaptation Layer 390 SLAAC - IPv6 StateLess Address AutoConfiguation 392 3. Enterprise Characteristics 394 Enterprises consist of links that are connected by Enterprise Routers 395 (ERs) as depicted in Figure 1. ERs typically participate in a 396 routing protocol over enterprise-interior interfaces to discover 397 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 398 Enterprise Border Routers (EBRs) are ERs that connect edge networks 399 to the enterprise and/or join multiple enterprises together. 400 Enterprise Border Gateways (EBGs) are EBRs that either directly or 401 indirectly connect enterprises to provider networks. 403 An enterprise may be as simple as a small collection of ERs and their 404 attached edge networks; an enterprise may also contain other 405 enterprises and/or be a subnetwork of a larger enterprise. An 406 enterprise may further encompass a set of branch offices and/or 407 nomadic hosts connected to a home office over one or several service 408 providers, e.g., through Virtual Private Network (VPN) tunnels. 410 Enterprises that comprise link types with sufficiently similar 411 properties (e.g., Layer 2 (L2) address formats, maximum transmission 412 units (MTUs), etc.) can configure a sub-IP layer routing service such 413 that IP sees the enterprise as an ordinary shared link the same as 414 for a (bridged) campus LAN. In that case, a single IP hop is 415 sufficient to traverse the enterprise without IP layer encapsulation. 417 Enterprises that comprise link types with diverse properties and/or 418 configure multiple IP subnets must also provide a routing service 419 that operates as an IP layer mechanism. In that case, multiple IP 420 hops may be necessary to traverse the enterprise such that care must 421 be taken to avoid multi-link subnet issues [RFC4903]. 423 Conceptually, an ER embodies both a host function and router 424 function. The host function supports Endpoint Interface iDentifier 425 (EID)-based and/or Routing LOCator (RLOC)-based communications 426 according to the weak end-system model [RFC1122]. The router 427 function engages in the enterprise-interior routing protocol, 428 connects any of the ER's edge networks to the enterprise, and may 429 also connect the enterprise to provider networks (see Figure 1). 431 In addition to other interface types, VET nodes configure VET 432 interfaces that view all other VET nodes in an enterprise as single- 433 hop neighbors attached to a virtual link. VET nodes configure a 434 separate VET interface for each distinct enterprise to which they 435 connect, and discover other EBRs on each VET interface that can be 436 used for forwarding packets to off-enterprise destinations. 438 For each distinct enterprise, an enterprise trust basis must be 439 established and consistently applied. For example, in enterprises in 440 which EBRs establish symmetric security associations, mechanisms such 441 as IPsec [RFC4301] can be used to assure authentication and 442 confidentiality. In other enterprise network scenarios, asymmetric 443 securing mechanisms such as SEcure Neighbor Discovery (SEND) 444 [RFC3971] may be necessary to authenticate exchanges based on trust 445 anchors. 447 Finally, in enterprises with a centralized management structure 448 (e.g., a corporate campus network), the enterprise name service and a 449 synchronized set of EBGs can provide infrastructure support for 450 virtual enterprise traversal. In that case, the EBGs can provide a 451 "default mapper" [I-D.jen-apt] service used for short-term packet 452 forwarding until EBR neighbor relationships can be established. In 453 enterprises with a distributed management structure (e.g., MANETs), 454 peer-to-peer coordination between the EBRs themselves may be 455 required. Recognizing that various use cases will entail a continuum 456 between a fully distributed and fully centralized approach, the 457 following sections present the mechanisms of Virtual Enterprise 458 Traversal as they apply to a wide variety of scenarios. 460 4. Autoconfiguration 462 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 463 specified in the following subsections. 465 4.1. Enterprise Router (ER) Autoconfiguration 467 ERs configure enterprise-interior interfaces and engage in any 468 routing protocols over those interfaces. 470 When an ER joins an enterprise, it first configures a unique IPv6 471 link-local address on each enterprise-interior interface and 472 configures an IPv4 link-local address on each enterprise-interior 473 interface that requires an IPv4 link-local capability. IPv6 link- 474 local address generation mechanisms that provide sufficient 475 uniqueness include Cryptographically Generated Addresses (CGAs) 476 [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 477 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 478 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 479 provide an IPv4 link-local address generation capability. 481 Next, the ER configures one or more RLOCs and engages in any routing 482 protocols on its enterprise-interior interfaces. The ER can 483 configure RLOCs via explicit management, DHCP autoconfiguration, 484 pseudo-random self-generation from a suitably large address pool, or 485 through an alternate autoconfiguration mechanism. The ER may 486 optionally configure and assign a separate RLOC for each underlying 487 interface, or it may configure only a single RLOC and assign it to a 488 VET interface configured over the underlying interfaces (see Section 489 4.2.1). In the latter case, the ER can use the VET interface for 490 link layer multiplexing and traffic engineering purposes as specified 491 in Appendix B. 493 Alternatively (or in addition), the ER can request RLOC prefix 494 delegations via an automated prefix delegation exchange over an 495 enterprise-interior interface and can assign the prefix(es) on 496 enterprise-edge interfaces. In that case, the ER can use an RLOC 497 assigned to an enterprise-edge interface for enterprise-interior 498 routing protocol operation and next-hop determination purposes. Note 499 that in some cases, the same enterprise-edge interfaces may assign 500 both RLOC and an EID addresses if there is a means for source address 501 selection. In other cases (e.g., for separation of security 502 domains), RLOCs and EIDs must be assigned on separate sets of 503 enterprise-edge interfaces. 505 Self-generation of RLOCs for IPv6 can be from a large IPv6 local-use 506 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 507 generation of RLOCs for IPv4 can be from a large IPv4 private address 508 range (e.g., [RFC1918]). When self-generation is used alone, the ER 509 must continuously monitor the RLOCs for uniqueness, e.g., by 510 monitoring the routing protocol. 512 DHCP generation of RLOCs may require support from relays within the 513 enterprise. For DHCPv6, relays that do not already know the RLOC of 514 a server within the enterprise forward requests to the 515 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For 516 DHCPv4, relays that do not already know the RLOC of a server within 517 the enterprise forward requests to the site-scoped IPv4 multicast 518 group address 'All_DHCPv4_Servers', which should be set to 519 239.255.2.1 unless an alternate multicast group for the site is 520 known. DHCPv4 servers that delegate RLOCs should therefore join the 521 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 522 received for that group. 524 A combined approach using both DHCP and self-generation is also 525 possible when the ER configures both a DHCP client and relay that are 526 connected, e.g., via a pair of back-to-back connected Ethernet 527 interfaces, a tun/tap interface, a loopback interface, inter-process 528 communication, etc. The ER first self-generates a temporary RLOC 529 used only for the purpose of procuring an actual RLOC taken from a 530 disjoint addressing range. The ER then engages in the routing 531 protocol and performs a DHCP client/relay exchange using the 532 temporary RLOC as the address of the relay. When the DHCP server 533 delegates an actual RLOC address/prefix, the ER abandons the 534 temporary RLOC and re-engages in the routing protocol using an RLOC 535 taken from the delegation. 537 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 538 enterprise-interior interfaces as singleton addresses (i.e., as 539 addresses with /32 prefix lengths for IPv4, and as addresses with 540 /128 prefix lengths for IPv6) may be necessary to avoid multi-link 541 subnet issues. 543 4.2. Enterprise Border Router (EBR) Autoconfiguration 545 EBRs are ERs that configure VET interfaces over distinct sets of 546 underlying interfaces belonging to the same enterprise; an EBR can 547 connect to multiple enterprises, in which case it would configure 548 multiple VET interfaces. In addition to the ER autoconfiguration 549 procedures specified in Section 4.1, EBRs perform the following 550 autoconfiguration operations. 552 4.2.1. VET Interface Autoconfiguration 554 VET interface autoconfiguration entails: 1) interface initialization, 555 2) EBG discovery and enterprise identification, and 3) EID 556 configuration. These functions are specified in the following 557 sections. 559 4.2.1.1. Interface Initialization 561 EBRs configure a VET interface over a set of underlying interfaces 562 belonging to the same enterprise, where the VET interface presents a 563 virtual-link abstraction in which all EBRs in the enterprise appear 564 as single-hop neighbors through the use of IP in IP encapsulation. 565 After the EBR configures a VET interface, it initializes the 566 interface and assigns an IPv6 link-local address and an IPv4 link- 567 local address if necessary. 569 When IPv6 and IPv4 are used as the inner/outer protocols 570 (respectively), the EBR autoconfigures an ISATAP link-local address 571 ([RFC5214], Section 6.2) on the VET interface to support packet 572 forwarding and operation of the IPv6 neighbor discovery protocol. 573 The ISATAP link-local address embeds an IPv4 RLOC, and need not be 574 checked for uniqueness since the IPv4 RLOC itself is managed for 575 uniqueness (see Section 4.1). 577 Link-local address configuration for other inner/outer IP protocol 578 combinations is through administrative configuration or through an 579 unspecified alternate method. Link-local address configuration for 580 other inner/outer IP protocol combinations may not be necessary if an 581 EID can be configured through other means (see Section 4.2.1.3). 583 After the EBR initializes a VET interface, it can communicate with 584 other VET nodes as single-hop neighbors on the VET interface from the 585 viewpoint of the inner IP protocol. 587 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 588 Identification 590 The EBR next discovers a list of EBGs for each of its VET interfaces. 591 The list can be discovered through information conveyed in the 592 routing protocol, through the Potential Router List (PRL) discovery 593 mechanisms outlined in Section 8.3.2 of [RFC5214], through DHCP 594 options, etc. In multicast-capable enterprises, EBRs can also listen 595 for advertisements on the 'rasadv' [RASADV] multicast group address. 597 In particular, whether or not routing information is available, the 598 EBR can discover the list of EBGs by resolving an identifying name 599 for the PRL ('PRLNAME') formed as 'hostname.domainname', where 600 'hostname' is an enterprise-specific name string and 'domainname' is 601 an enterprise-specific DNS suffix. The EBR discovers 'PRLNAME' 602 through manual configuration, a DHCP option, 'rasadv' protocol 603 advertisements, link-layer information (e.g., an IEEE 802.11 Service 604 Set Identifier (SSID)), or through some other means specific to the 605 enterprise. In the absence of other information, the EBR sets the 606 'hostname' component of 'PRLNAME' to "isatap" and sets the 607 'domainname' component only if an enterprise-specific DNS suffix 608 "example.com" is known (e.g., as "isatap.example.com"). 610 The global Internet interdomain routing core represents a specific 611 example of an enterprise network scenario, albeit on an enormous 612 scale. The 'PRLNAME' assigned to the global Internet interdomain 613 routing core is "isatap.net". 615 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 616 resolving 'PRLNAME' to a list of RLOC addresses through a name 617 service lookup. For centrally managed enterprises, the EBR resolves 618 'PRLNAME' using an enterprise-local name service (e.g., the 619 enterprise-local DNS). For enterprises with a distributed management 620 structure, the EBR resolves 'PRLNAME' using Link-Local Multicast Name 621 Resolution (LLMNR) [RFC4795] over the VET interface. In that case, 622 all EBGs in the PRL respond to the LLMNR query, and the EBR accepts 623 the union of all responses. 625 Each distinct enterprise must have a unique identity that EBRs can 626 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 627 well as the RLOCs of EBGs and the IP prefixes they aggregate serve as 628 an identifier for the enterprise. 630 4.2.1.3. EID Configuration 632 After EBG discovery, the EBR configures EIDs on its VET interfaces. 633 When IPv6 and IPv4 are used as the inner/outer protocols 634 (respectively), the EBR autoconfigures EIDs as specified in 635 Section 5.4.1. In particular, the EBR acts as a host on its VET 636 interfaces for router and prefix discovery purposes but acts as a 637 router on its VET interfaces for routing protocol operation and 638 packet forwarding purposes. 640 EID configuration for other inner/outer IP protocol combinations is 641 through administrative configuration or through an unspecified 642 alternate method; in some cases, such EID configuration can be 643 performed independently of EBG discovery. 645 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 647 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 648 autoconfiguration exchanges with EBGs over VET interfaces, where each 649 EBG may be configured as either a DHCP relay or DHCP server. 651 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 652 delegation exchange, explicit management, etc. 654 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 655 exchanges. In particular, the EBR (acting as a requesting router) 656 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 657 obtain IPv6 EID prefixes from the server (acting as a delegating 658 router). 660 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 661 exchange [RFC3315]. For example, to perform the 2-message exchange, 662 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 663 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 664 relay (see Section 4.1). The relay then forwards the message over 665 the VET interface to an EBG, which either services the request or 666 relays it further. The forwarded Solicit message will elicit a reply 667 from the server containing PA IPv6 prefix delegations. 669 The EBR can propose a specific prefix to the DHCPv6 server per 670 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 671 available. The server will check the proposed prefix for consistency 672 and uniqueness, then return it in the reply to the EBR if it was able 673 to perform the delegation. 675 After the EBR receives PA prefix delegations, it can provision the 676 prefixes on enterprise-edge interfaces as well as on other VET 677 interfaces for which it is configured as an EBG. It can also 678 provision the prefixes on enterprise-interior interfaces as long as 679 other nodes on those interfaces unambiguously associate the prefixes 680 with the EBR. 682 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 684 Independent of any PA prefixes, EBRs can acquire and use Provider- 685 Independent (PI) EID prefixes that are self-configured (e.g., using 686 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 687 using [I-D.ietf-ipv6-ula-central], etc.). When an EBR acquires a PI 688 prefix, it must also obtain credentials that it can use to prove 689 prefix ownership when it registers the prefixes with EBGs within an 690 enterprise (see Section 5.4 and Section 5.5). 692 After the EBR receives PI prefix delegations, it can provision the 693 prefixes on enterprise-edge interfaces as well as on other VET 694 interfaces for which it is configured as an EBG. It can also 695 provision the prefixes on enterprise-interior interfaces as long as 696 other nodes on those interfaces can unambiguously associate the 697 prefixes with the EBR. 699 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 701 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 703 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 705 EBGs are EBRs that connect child enterprises to provider networks via 706 provider-edge interfaces and/or via VET interfaces configured over 707 parent enterprises. EBGs autoconfigure their provider-edge 708 interfaces in a manner that is specific to the provider connections, 709 and they autoconfigure their VET interfaces that were configured over 710 parent enterprises, using the EBR autoconfiguration procedures 711 specified in Section 4.2. 713 For each of its VET interfaces configured over a child enterprise, 714 the EBG initializes the interface and configures an EID the same as 715 for an ordinary EBR (see Section 4.2.1). It must then arrange to add 716 one or more of its RLOCs associated with the child enterprise to the 717 PRL, and it must maintain these resource records in accordance with 718 [RFC5214], Section 9. In particular, for each VET interface 719 configured over a child enterprise, the EBG adds the RLOCs to name- 720 service resource records for 'PRLNAME'. 722 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 723 configured over child enterprises with a distributed management 724 structure. 726 EBGs configure a DHCP relay/server on VET interfaces configured over 727 child enterprises that require DHCP services. 729 To avoid looping, EBGs must not configure a default route on a VET 730 interface configured over a child interface. 732 4.4. VET Host Autoconfiguration 734 Nodes that cannot be attached via an EBR's enterprise-edge interface 735 (e.g., nomadic laptops that connect to a home office via a Virtual 736 Private Network (VPN)) can instead be configured for operation as a 737 simple host connected to the VET interface. Such VET hosts perform 738 the same VET interface autoconfiguration procedures as specified for 739 EBRs in Section 4.2.1, but they configure their VET interfaces as 740 host interfaces (and not router interfaces). VET hosts can then send 741 packets to the EID addresses of other hosts on the VET interface, or 742 to off-enterprise EID destinations via a next-hop EBR. 744 Note that a node may be configured as a host on some VET interfaces 745 and as an EBR/EBG on other VET interfaces. 747 5. Internetworking Operation 749 Following the autoconfiguration procedures specified in Section 4, 750 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 751 operations as discussed in the following sections. 753 5.1. Routing Protocol Participation 755 Following autoconfiguration, ERs engage in any RLOC-based IP routing 756 protocols and forward IP packets with RLOC addresses. EBRs can 757 additionally engage in any EID-based IP routing protocols and forward 758 IP packets with EID addresses. Note that the EID-based IP routing 759 domains are separate and distinct from any RLOC-based IP routing 760 domains. 762 5.2. RLOC-Based Communications 764 When permitted by policy and supported by routing, end systems can 765 avoid VET interface encapsulation through communications that 766 directly invoke the outer IP protocol using RLOC addresses instead of 767 EID addresses. End systems can use source address selection rules to 768 determine whether to use EID or RLOC addresses based on, e.g., name- 769 service records. 771 5.3. EID-Based Communications 773 In many enterprise scenarios, the use of EID-based communications 774 (i.e., instead of RLOC-based communications) may be necessary and/or 775 beneficial to support address scaling, NAT avoidance, security domain 776 separation, site multihoming, traffic engineering, etc. 778 The remainder of this section discusses internetworking operation for 779 EID-based communications using the VET interface abstraction. 781 5.4. IPv6 Router Discovery and Prefix Registration 783 The following sections discuss router and prefix discovery 784 considerations for the case of IPv6 as the inner IP protocol. 786 5.4.1. IPv6 Router and Prefix Discovery 788 EBGs follow the router and prefix discovery procedures specified in 789 [RFC5214], Section 8.2. They send solicited RAs over VET interfaces 790 for which they are configured as gateways with default router 791 lifetimes, with PIOs that contain PA prefixes for SLAAC, and with any 792 other required options/parameters. The RAs can also include PIOs 793 with the 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' 794 as a hint of an aggregated prefix from which the EBG is willing to 795 delegate longer PA prefixes. When PIOs that contain PA prefixes for 796 SLAAC are included, the 'M' flag in the RA should also be set to 0. 798 VET nodes follow the router and prefix discovery procedures specified 799 in [RFC5214], Section 8.3. They discover EBGs within the enterprise 800 as specified in Section 4.2.1.2, then perform RS/RA exchanges with 801 the EBGs to establish and maintain default routes. In particular, 802 the VET node sends unicast RS messages to EBGs over its VET 803 interface(s) to receive RAs. Depending on the enterprise network 804 trust basis, VET nodes may be required to use SEND to secure the 805 RS/RA exchanges. 807 When the VET node receives an RA, it authenticates the message, then 808 configures a default route based on the Router Lifetime. If the RA 809 contains Prefix Information Options (PIOs) with the 'A' and 'L' bits 810 set to 1, the VET node also autoconfigures IPv6 addresses from the 811 advertised prefixes using SLAAC and assigns them to the VET 812 interface. Thereafter, the VET node accepts packets that are 813 forwarded by EBGs for which it has current default routing 814 information (i.e., ingress filtering is based on the default router 815 trust relationship rather than a prefix-specific ingress filter 816 entry). 818 In enterprises in which DHCPv6 is preferred, DHCPv6 exchanges between 819 EBRs and EBGs may be sufficient to convey default router and prefix 820 information. In that case, RS/RA exchanges may not be necessary. 822 5.4.2. IPv6 PA Prefix Registration 824 After an EBR discovers default routes, it can use DHCP prefix 825 delegation to obtain PA prefixes via an EBG as specified in 826 Section 4.2.2. The DHCP server ensures that the delegations are 827 unique and that the EBG's router function will forward IP packets 828 over the VET interface to the correct EBR. In particular, the EBG 829 must register and track the PA prefixes that are delegated to each 830 EBR. 832 The PA prefix registrations remain active in the EBGs as long as the 833 EBR continues to issue DHCP renewals over the VET interface before 834 lease lifetimes expire. The lease lifetime also keeps the delegation 835 state active even if communications between the EBR and DHCP server 836 are disrupted for a period of time (e.g., due to an enterprise 837 network partition) before being reestablished (e.g., due to an 838 enterprise network merge). 840 5.4.3. IPv6 PI Prefix Registration 842 After an EBR discovers default routes, it must register its PI 843 prefixes by sending RAs to a set of one or more EBGs with Route 844 Information Options (RIOs) [RFC4191] that contain the EBR's PI 845 prefixes. Each RA must include the RLOC of an EBG as the outer IP 846 destination address and a link-local address assigned to the VET 847 interface as the inner IP destination address. For enterprises that 848 use SEND, the RAs also include a CGA link-local inner source address, 849 SEND credentials, plus any certificates needed to prove ownership of 850 the PI prefixes. The EBR additionally tracks the set of EBGs to 851 which it sends RAs so that it can send subsequent RAs to the same 852 set. 854 When the EBG receives the RA, it first authenticates the message; if 855 the authentication fails, the EBG discards the RA. Otherwise, the 856 EBG installs the PI prefixes with their respective lifetimes in its 857 Forwarding Information Base (FIB) and configures them for both 858 ingress filtering [RFC3704] and forwarding purposes. In particular, 859 the EBG configures the FIB entries as ingress filter rules to accept 860 packets received on the VET interface that have a source address 861 taken from the PI prefixes. It also configures the FIB entries to 862 forward packets received on other interfaces with a destination 863 address taken from the PI prefixes to the EBR that registered the 864 prefixes on the VET interface. 866 The EBG then publishes the PI prefixes in a distributed database 867 (e.g., in a private instance of a routing protocol in which only EBGs 868 participate, via an automated name-service update mechanism 869 [RFC3007], etc.). For enterprises that are managed under a 870 centralized administrative authority, the EBG also publishes the PI 871 prefixes in the enterprise-local name-service (e.g., the enterprise- 872 local DNS [RFC1035]). 874 In particular, the EBG publishes each /56 prefix taken from the PI 875 prefixes as a separate Fully Qualified Domain Name (FQDN) that 876 consists of a sequence of 14 nibbles in reverse order (i.e., the same 877 as in [RFC3596], Section 2.5) followed by the string 'ip6' followed 878 by the string 'PRLNAME'. For example, when 'PRLNAME' is 879 "isatap.example.com", the EBG publishes the prefix '2001:DB8::/56' 880 as: 881 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. 883 The EBG includes the outer RLOC source address of the RA (e.g., in a 884 DNS A resource record) in each prefix publication. For enterprises 885 that use SEND, the EBG also includes the inner IPv6 CGA source 886 address (e.g., in a DNS AAAA record) in each prefix publication. If 887 the prefix was already installed in the distributed database, the EBG 888 instead adds the outer RLOC source address (e.g., in an additional 889 DNS A record) to the preexisting publication to support PI prefixes 890 that are multihomed. For enterprises that use SEND, this latter 891 provision requires all EBRs of a multihomed site that advertise the 892 same PI prefixes in RAs to use the same CGA and the same SEND 893 credentials. 895 After the EBG authenticates the RA and publishes the PI prefixes, it 896 next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the 897 VET interfaces configured over any of its parent enterprises, and it 898 relays a proxied RA to the EBGs on those interfaces. (For 899 enterprises that use SEND, the EBG additionally acts as a SEcure 900 Neighbor Discovery Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) 901 EBGs in parent enterprises that receive the proxied RAs in turn act 902 as NDProxys/SENDProxys to relay the RAs to EBGs on their parent 903 enterprises, etc. The RA proxying and PI prefix publication recurses 904 in this fashion and ends when an EBR attached to an interdomain 905 routing core is reached. 907 After the initial PI prefix registration, the EBR that owns the 908 prefix(es) must periodically send additional RAs to its set of EBGs 909 to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in 910 parent enterprises to which it relays the proxied RAs, and should 911 relay subsequent RAs to the same set. 913 This procedure has a direct analogy in the Teredo method of 914 maintaining state in network middleboxes through the periodic 915 transmission of "bubbles" [RFC4380]. 917 5.4.4. IPv6 Next-Hop EBR Discovery 919 VET nodes discover destination-specific next-hop EBRs within the 920 enterprise by querying the name service for the /56 IPv6 PI prefix 921 taken from a packet's destination address, by forwarding packets via 922 a default route to an EBG, or by some other inner-IP-to-outer-IP 923 address mapping mechanism. For example, for the IPv6 destination 924 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 925 node can lookup the domain name: 926 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. 928 If the name-service lookup succeeds, it will return RLOC addresses 929 (e.g., in DNS A records) that correspond to next-hop EBRs to which 930 the VET node can forward packets. (In enterprises that use SEND, it 931 will also return an IPv6 CGA address, e.g., in a DNS AAAA record.) 933 Name-service lookups in enterprises with a centralized management 934 structure use an infrastructure-based service, e.g., an enterprise- 935 local DNS. Name-service lookups in enterprises with a distributed 936 management structure and/or that lack an infrastructure-based name- 937 service instead use LLMNR over the VET interface. When LLMNR is 938 used, the EBR that performs the lookup sends an LLMNR query (with the 939 /56 prefix taken from the IP destination address encoded in dotted- 940 nibble format as shown above) and accepts the union of all replies it 941 receives from other EBRs on the VET interface. When an EBR receives 942 an LLMNR query, it responds to the query IFF it aggregates an IP 943 prefix that covers the prefix in the query. 945 Alternatively, in enterprises with a stable and highly-available set 946 of EBGs, the VET node can simply forward an initial packet via a 947 default route to an EBG. The EBG will forward the packet to a next- 948 hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] 949 (using SEND, if necessary). If the packet's source address is on- 950 link on the VET interface, the EBG returns an ordinary "router-to- 951 host" redirect with the source address of the packet as its 952 destination. If the packet's source address is not on-link, the EBG 953 instead returns a "router-to-router" redirect with the link-local 954 ISATAP address of the previous-hop EBR as its destination. When IPv4 955 is used as the outer IP protocol, the EBG also includes in the 956 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 957 contain the IPv4 RLOCs of potential next-hop EBRs arranged in order 958 from lowest to highest priority (i.e., the first LLAO contains the 959 lowest priority RLOC and the final LLAO option contains the highest 960 priority). These LLAOs are formatted using a modified version of the 961 form specified in Section 5 of [RFC2529], as shown in Figure 2 (the 962 LLAO format for IPv6 as the outer IP protocol is out of scope). 964 +-------+-------+-------+-------+-------+-------+-------+-------+ 965 | Type |Length | TTL | IPv4 Address | 966 +-------+-------+-------+-------+-------+-------+-------+-------+ 968 Figure 2: VET Link-Layer Address Option Format 970 For each such IPv6/IPv4 LLAO, the Type is set to 2 (for Target Link- 971 Layer Address Option), Length is set to 1, and IPv4 Address is set to 972 the IPv4 RLOC of the next-hop EBR. TTL is set to the time in seconds 973 that the recipient may cache the RLOC, where the value 65535 974 represents infinity and the value 0 suspends forwarding through this 975 RLOC. 977 When a VET host receives an ordinary "router-to-host" redirect, it 978 processes the redirect exactly as specified in [RFC4861], Section 8. 979 When an EBR receives a "router-to-router" redirect, it discovers the 980 RLOC addresses of potential next-hop EBRs by examining the LLAOs 981 included in the redirect. The EBR then installs a FIB entry that 982 contains the /56 prefix of the destination address encoded in the 983 redirect and the list of RLOCs of potential next-hop EBRs. The EBR 984 then enables the FIB entry for forwarding to next-hop EBRs but DOES 985 NOT enable it for ingress filtering acceptance of packets from next- 986 hop EBRs (i.e., the forwarding determination is unidirectional). 988 In enterprises in which spoofing is possible, after discovering 989 potential next-hop EBRs (either through name-service lookup or ICMP 990 redirect) the EBR must send authenticating credentials before 991 forwarding packets via the next-hops. To do so, the EBR must send 992 RAs over the VET interface (using SEND, if necessary) to one or more 993 of the potential next-hop EBRs with an RLOC as the outer IP 994 destination address. The RAs must include a Route Information Option 995 (RIO) [RFC4191] that contains the /56 PI prefix of the original 996 packet's source address. After sending the RAs, the EBR can either 997 enable the new FIB entry for forwarding immediately or delay until it 998 receives an explicit acknowledgement that a next-hop EBR received the 999 RA (e.g., using the SEAL explicit acknowledgement mechanism -- see 1000 Section 5.7). 1002 When a next-hop EBR receives the RA, it authenticates the message 1003 then it performs a name-service lookup on the prefix in the RIO if 1004 further authenticating evidence is required. If the name service 1005 returns resource records that are consistent with the inner and outer 1006 IP addresses of the RA, the next-hop EBR then installs the prefix in 1007 the RIO in its FIB and enables the FIB entry for ingress filtering 1008 but DOES NOT enable it for forwarding purposes. After an EBR sends 1009 initial RAs following a redirect, it should send periodic RAs to 1010 refresh the next-hop EBR's ingress filter prefix lifetimes as long as 1011 traffic is flowing. 1013 EBRs retain the FIB entries created as a result of an ICMP redirect 1014 until all RLOC TTLs expire, or until no hints of forward progress 1015 through any of the associated RLOCs are received. In this way, RLOC 1016 liveness detection exactly parallels IPv6 Neighbor Unreachability 1017 Detection ([RFC4861], Section 3). 1019 5.5. IPv4 Router Discovery and Prefix Registration 1021 When IPv4 is used as the inner IP protocol, router discovery and 1022 prefix registration exactly parallel the mechanisms specified for 1023 IPv6 in Section 5.4. To support this, modifications to the ICMPv4 1024 Router Advertisement [RFC1256] function to include SEND constructs 1025 and modifications to the ICMPv4 Redirect [RFC0792] function to 1026 support router-to-router redirects will be specified in a future 1027 document. Additionally, publications for IPv4 prefixes will be in 1028 dotted-nibble format in the 'ip4.isatap.example.com' domain. For 1029 example, the IPv4 prefix 192.0.2/24 would be represented as: 1030 '2.0.0.0.0.c.ip4.isatap.example.com' 1032 5.6. VET Encapsulation 1034 VET nodes forward packets by consulting the FIB to determine a 1035 specific EBR/EBG as the next-hop router on a VET interface. When 1036 multiple next-hop routers are available, VET nodes can use default 1037 router preferences, routing protocol information, traffic engineering 1038 configurations, etc. to select the best exit router. When there is 1039 no FIB information other than "default" available, VET nodes can 1040 discover the next-hop EBR/EBG through the mechanisms specified in 1041 Section 5.4 and Section 5.5. 1043 VET interfaces encapsulate inner IP packets in any mid-layer headers 1044 followed by an outer IP header according to the specific 1045 encapsulation type (e.g., [RFC4301], [RFC5214], 1046 [I-D.templin-intarea-seal], etc.); they next submit the encapsulated 1047 packet to the outer IP forwarding engine for transmission on an 1048 underlying interface. 1050 For forwarding to next-hop addresses over VET interfaces that use 1051 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 1052 address (i.e., the IPv4 RLOC of the next-hop EBR) through static 1053 extraction of the IPv4 address embedded in the next-hop ISATAP 1054 address. For other IP-in-IP encapsulations, determination of the 1055 outer destination address is through administrative configuration or 1056 through an unspecified alternate method. When there are multiple 1057 candidate destination RLOCs available, the VET node should only 1058 select an RLOC for which there is current forwarding information in 1059 the outer IP protocol FIB. 1061 5.7. SEAL Encapsulation 1063 VET nodes should use SEAL encapsulation [I-D.templin-intarea-seal] 1064 over VET interfaces to accommodate path MTU diversity, to defeat 1065 source address spoofing, and to monitor next-hop EBR reachability. 1066 SEAL encapsulation maintains a unidirectional and monotonically 1067 incrementing per-packet identification value known as the 'SEAL_ID'. 1068 When a VET node that uses SEAL encapsulation sends a SEND-protected 1069 Router Advertisement (RA) or Router Solicitation (RS) message to 1070 another VET node, both nodes cache the new SEAL_ID as per-tunnel 1071 state used for maintaining a window of unacknowledged SEAL_IDs. 1073 In terms of security, when a VET node receives an ICMP message, it 1074 can confirm that the packet-in-error within the ICMP message 1075 corresponds to one of its recently sent packets by examining the 1076 SEAL_ID along with source and destination addresses, etc. 1077 Additionally, a next-hop EBR can track the SEAL_ID in packets 1078 received from EBRs for which there is an ingress filter entry and 1079 discard packets that have SEAL_ID values outside of the current 1080 window. 1082 In terms of next-hop reachability, an EBR can set the SEAL 1083 "Acknowledgement Requested" bit in messages to receive confirmation 1084 that a next-hop EBR is reachable. Setting the "Acknowledgement 1085 Requested" bit is also used as the method for maintaining the window 1086 of outstanding SEAL_IDs. 1088 5.8. Generating Errors 1090 When an EBR receives an IPv6 packet over a VET interface and there is 1091 no matching ingress filter entry, it drops the packet and returns an 1092 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 1093 ingress/egress policy" message to the previous-hop EBR subject to 1094 rate limiting. 1096 When an EBR receives an IPv6 packet over a VET interface, and there 1097 is no longest-prefix-match FIB entry for the destination, it returns 1098 an ICMPv6 "Destination Unreachable; No route to destination" message 1099 to the previous hop EBR subject to rate limiting. 1101 When an EBR receives an IPv6 packet over a VET interface and the 1102 longest-prefix-match FIB entry for the destination is via a next-hop 1103 configured over the same VET interface the packet arrived on, the EBR 1104 forwards the packet, then (if the FIB prefix is longer than ::/0) 1105 sends a router-to-router ICMPv6 Redirect message (using SEND, if 1106 necessary) to the previous-hop EBR as specified in Section 5.4.4. 1108 Generation of other ICMP messages [RFC0792] [RFC4443] is the same as 1109 for any IP interface. 1111 5.9. Processing Errors 1113 When an EBR receives an ICMPv6 "Destination Unreachable; Source 1114 address failed ingress/egress policy" message from a next-hop EBR, 1115 and there is a longest-prefix-match FIB entry for the original 1116 packet's destination that is more specific than ::/0, the EBR 1117 discards the message and marks the FIB entry for the destination as 1118 "forwarding suspended" for the RLOC taken from the source address of 1119 the ICMPv6 message. The EBR should then allow subsequent packets to 1120 flow through different RLOCs associated with the FIB entry until it 1121 forwards a new RA to the suspended RLOC. If the EBR receives 1122 excessive ICMPv6 ingress/egress policy errors through multiple RLOCs 1123 associated with the same FIB entry, it should delete the FIB entry 1124 and allow subsequent packets to flow through an EBG if supported in 1125 the specific enterprise scenario. 1127 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1128 to destination" message from a next-hop EBR, it forwards the ICMPv6 1129 message to the source of the original packet as normal. If the EBR 1130 has longest-prefix-match FIB entry for the original packet's 1131 destination that is more specific than ::/0, the EBR also deletes the 1132 FIB entry. 1134 When an EBR receives an authentic ICMPv6 Redirect, it processes the 1135 packet as specified in Section 5.4.4. 1137 When an EBG receives new mapping information for a specific 1138 destination prefix, it can propagate the update to other EBRs/EBGs by 1139 sending an ICMPv6 redirect message to the 'All Routers' link-local 1140 multicast address with an LLAO with the TTL for the unreachable LLAO 1141 set to zero, and with a NULL packet in error. 1143 Additionally, a VET node may receive ICMP "Destination Unreachable; 1144 net / host unreachable" messages from an ER indicating that the path 1145 to a VET neighbor may be failing. The VET node should first check, 1146 e.g., the SEAL_ID, IPsec sequence number, source address of the 1147 original packet if available, etc. to obtain reasonable assurance 1148 that the ICMP message is authentic, then should mark the longest- 1149 prefix-match FIB entry for the destination as "forwarding suspended" 1150 for the RLOC destination address of the ICMP packet-in-error. If the 1151 VET node receives excessive ICMP unreachable errors through multiple 1152 RLOCs associated with the same FIB entry, it should delete the FIB 1153 entry and allow subsequent packets to flow through a different route. 1155 5.10. Mobility and Multihoming Considerations 1157 EBRs that travel between distinct enterprise networks must either 1158 abandon their PA prefixes that are relative to the "old" enterprise 1159 and obtain new ones relative to the "new" enterprise or somehow 1160 coordinate with a "home" enterprise to retain ownership of the 1161 prefixes. In the first instance, the EBR would be required to 1162 coordinate a network renumbering event using the new PA prefixes 1163 [RFC4192]. In the second instance, an ancillary mobility management 1164 mechanism must be used. 1166 EBRs can retain their PI prefixes as they travel between distinct 1167 enterprise networks as long as they register the prefixes with new 1168 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1169 departure. Prefix registration with new EBGs is coordinated exactly 1170 as specified in Section 5.4.3; prefix withdrawal from old EBGs is 1171 simply through re-announcing the PI prefixes with zero lifetimes. 1173 Since EBRs can move about independently of one another, stale FIB 1174 entry state may be left in VET nodes when a neighboring EBR departs. 1175 Additionally, EBRs can lose state for various reasons, e.g., power 1176 failure, machine reboot, etc. For this reason, EBRs are advised to 1177 set relatively short PI prefix lifetimes in RIO options, and to send 1178 additional RAs to refresh lifetimes before they expire. (EBRs should 1179 place conservative limits on the RAs they send to reduce congestion, 1180 however.) 1182 EBRs may register their PI prefixes with multiple EBGs for 1183 multihoming purposes. EBRs should only forward packets via EBGs with 1184 which it has registered its PI prefixes, since other EBGs may drop 1185 the packets and return ICMPv6 "Destination Unreachable; Source 1186 address failed ingress/egress policy" messages. 1188 EBRs can also act as delegating routers to sub-delegate portions of 1189 their PI prefixes to requesting routers on their enterprise-edge 1190 interfaces and on VET interfaces for which they are configured as 1191 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1192 become the PA prefixes for downstream-dependent nodes. Downstream- 1193 dependent nodes that travel with a mobile provider EBR can continue 1194 to use addresses configured from PA prefixes; downstream-dependent 1195 nodes that move away from their provider EBR must perform address/ 1196 prefix renumbering when they associate with a new provider. 1198 The EBGs of a multihomed enterprise should participate in a private 1199 inner IP routing protocol instance between themselves (possibly over 1200 an alternate topology) to accommodate enterprise partitions/merges as 1201 well as intra-enterprise mobility events. These peer EBGs should 1202 accept packets from one another without respect to the destination 1203 (i.e., ingress filtering is based on the peering relationship rather 1204 than a prefix-specific ingress filter entry). 1206 5.11. Multicast 1208 In multicast-capable deployments, ERs provide an enterprise-wide 1209 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1210 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1211 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1212 over their enterprise-interior interfaces such that outer IP 1213 multicast messages of site-scope or greater scope will be propagated 1214 across the enterprise. For such deployments, VET nodes can also 1215 provide an inner IP multicast/broadcast capability over their VET 1216 interfaces through mapping of the inner IP multicast address space to 1217 the outer IP multicast address space. In that case, operation of 1218 link-scoped (or greater scoped) inner IP multicasting services (e.g., 1219 a link-scoped neighbor discovery protocol) over the VET interface is 1220 available, but link-scoped services should be used sparingly to 1221 minimize enterprise-wide flooding. 1223 VET nodes encapsulate inner IP multicast messages sent over the VET 1224 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1225 outer IP header with a site-scoped outer IP multicast address as the 1226 destination. For the case of IPv6 and IPv4 as the inner/outer 1227 protocols (respectively), [RFC2529] provides mappings from the IPv6 1228 multicast address space to a site-scoped IPv4 multicast address space 1229 (for other IP-in-IP encapsulations, mappings are established through 1230 administrative configuration or through an unspecified alternate 1231 static mapping). 1233 Multicast mapping for inner IP multicast groups over outer IP 1234 multicast groups can be accommodated, e.g., through VET interface 1235 snooping of inner multicast group membership and routing protocol 1236 control messages. To support inner-to-outer IP multicast mapping, 1237 the VET interface acts as a virtual outer IP multicast host connected 1238 to its underlying interfaces. When the VET interface detects that an 1239 inner IP multicast group joins or leaves, it forwards corresponding 1240 outer IP multicast group membership reports on an underlying 1241 interface over which the VET interface is configured. If the VET 1242 node is configured as an outer IP multicast router on the underlying 1243 interfaces, the VET interface forwards locally looped-back group 1244 membership reports to the outer IP multicast routing process. If the 1245 VET node is configured as a simple outer IP multicast host, the VET 1246 interface instead forwards actual group membership reports (e.g., 1247 IGMP messages) directly over an underlying interface. 1249 Since inner IP multicast groups are mapped to site-scoped outer IP 1250 multicast groups, the VET node must ensure that the site-scope outer 1251 IP multicast messages received on the underlying interfaces for one 1252 VET interface do not "leak out" to the underlying interfaces of 1253 another VET interface. This is accommodated through normal site- 1254 scoped outer IP multicast group filtering at enterprise boundaries. 1256 5.12. Service Discovery 1258 VET nodes can perform enterprise-wide service discovery using a 1259 suitable name-to-address resolution service. Examples of flooding- 1260 based services include the use of LLMNR [RFC4795] over the VET 1261 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1262 over an underlying interface. More scalable and efficient service 1263 discovery mechanisms are for further study. 1265 5.13. Enterprise Partitioning 1267 EBGs can physically partition an enterprise by configuring multiple 1268 VET interfaces over multiple distinct sets of underlying interfaces. 1269 In that case, each partition (i.e., each VET interface) must 1270 configure its own distinct 'PRLNAME' (e.g., 1271 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1273 EBGs can logically partition an enterprise using a single VET 1274 interface by sending RAs with PIOs containing different IPv6 PA 1275 prefixes to group nodes into different logical partitions. EBGs can 1276 identify partitions, e.g., by examining RLOC prefixes, observing the 1277 interfaces over which RSs are received, etc. In that case, a single 1278 'PRLNAME' can cover all partitions. 1280 5.14. EBG Prefix State Recovery 1282 EBGs must retain explicit state that tracks the inner IP prefixes 1283 owned by EBRs within the enterprise, e.g., so that packets are 1284 delivered to the correct EBRs and not incorrectly "leaked out" of the 1285 enterprise via a default route. For PA prefixes, the state is 1286 maintained via an EBR's DHCP prefix delegation lease renewals, while 1287 for PI prefixes the state is maintained via an EBR's periodic prefix 1288 registration RAs. 1290 When an EBG loses some or all of its state (e.g., due to a power 1291 failure), it must recover the state so that packets can be forwarded 1292 over correct routes. If the EBG aggregates PA prefixes from which 1293 the IP prefixes of all EBRs in the enterprise are sub-delegated, then 1294 the EBG can recover state through DHCP prefix delegation lease 1295 renewals, through bulk lease queries, or through on-demand name- 1296 service lookups based due to IP packet forwarding. If the EBG serves 1297 as an anchor for PI prefixes, however, care must be taken to avoid 1298 looping while state is recovered through prefix registration RAs from 1299 EBRs. In that case, when the EBG that is recovering state forwards 1300 an IP packet for which it has no explicit route other than ::/0, it 1301 must first perform an on-demand name-service lookup to refresh state. 1303 6. IANA Considerations 1305 There are no IANA considerations for this document. 1307 7. Security Considerations 1309 Security considerations for MANETs are found in [RFC2501]. 1311 Security considerations with tunneling that apply also to VET are 1312 found in [RFC2529] [RFC5214]. In particular, VET nodes must verify 1313 that the outer IP source address of a packet received on a VET 1314 interface is correct for the inner IP source address using the 1315 procedures specified in Section 7.3 of [RFC5214] in conjunction with 1316 the ingress filtering mechanisms specified in this document. 1318 SEND [RFC3971], IPsec [RFC4301], and SEAL [I-D.templin-intarea-seal] 1319 provide additional securing mitigations to detect source address 1320 spoofing and bogus RA messages sent by rogue routers. 1322 Rogue routers can send bogus RA messages with spoofed RLOC source 1323 addresses that can consume network resources and cause EBGs to 1324 perform extra work. Nonetheless, EBGs should not "blacklist" such 1325 RLOCs, as that may result in a denial of service to the RLOCs' 1326 legitimate owners. 1328 8. Related Work 1330 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1331 automatic tunneling in [RFC2529]; this concept was later called: 1332 "Virtual Ethernet" and investigated by Quang Nguyen under the 1333 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1334 their colleagues have motivated a number of foundational concepts on 1335 which this work is based. 1337 Telcordia has proposed DHCP-related solutions for MANETs through the 1338 CECOM MOSAIC program. 1340 The Naval Research Lab (NRL) Information Technology Division uses 1341 DHCP in their MANET research testbeds. 1343 Security concerns pertaining to tunneling mechanisms are discussed in 1344 [I-D.ietf-v6ops-tunnel-security-concerns]. 1346 Default router and prefix information options for DHCPv6 are 1347 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1349 An automated IPv4 prefix delegation mechanism is proposed in 1350 [I-D.ietf-dhc-subnet-alloc]. 1352 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1353 [I-D.clausen-manet-autoconf-recommendations]. 1355 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1357 Various proposals within the IETF have suggested similar mechanisms. 1359 9. Acknowledgements 1361 The following individuals gave direct and/or indirect input that was 1362 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1363 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1364 Ralph Droms, Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, 1365 Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe 1366 Macker, David Meyer, Thomas Narten, Pekka Nikander, Dave Oran, 1367 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole 1368 Troan, Michaela Vanderveen, Lixia Zhang, and others in the IETF 1369 AUTOCONF and MANET working groups. Many others have provided 1370 guidance over the course of many years. 1372 10. Contributors 1374 The following individuals have contributed to this document: 1376 Eric Fleischman (eric.fleischman@boeing.com) 1377 Thomas Henderson (thomas.r.henderson@boeing.com) 1378 Steven Russert (steven.w.russert@boeing.com) 1379 Seung Yi (seung.yi@boeing.com) 1381 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1382 of the document. 1384 Jim Bound's foundational work on enterprise networks provided 1385 significant guidance for this effort. We mourn his loss and honor 1386 his contributions. 1388 11. References 1390 11.1. Normative References 1392 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1393 September 1981. 1395 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1396 RFC 792, September 1981. 1398 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1399 converting network protocol addresses to 48.bit Ethernet 1400 address for transmission on Ethernet hardware", STD 37, 1401 RFC 826, November 1982. 1403 [RFC1035] Mockapetris, P., "Domain names - implementation and 1404 specification", STD 13, RFC 1035, November 1987. 1406 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1407 RFC 2131, March 1997. 1409 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1410 (IPv6) Specification", RFC 2460, December 1998. 1412 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1413 Update", RFC 3007, November 2000. 1415 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1416 and M. Carney, "Dynamic Host Configuration Protocol for 1417 IPv6 (DHCPv6)", RFC 3315, July 2003. 1419 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1420 "DNS Extensions to Support IP Version 6", RFC 3596, 1421 October 2003. 1423 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1424 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1425 December 2003. 1427 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1428 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1430 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1431 RFC 3972, March 2005. 1433 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1434 More-Specific Routes", RFC 4191, November 2005. 1436 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1437 Architecture", RFC 4291, February 2006. 1439 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1440 Message Protocol (ICMPv6) for the Internet Protocol 1441 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1443 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1444 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1445 September 2007. 1447 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1448 Address Autoconfiguration", RFC 4862, September 2007. 1450 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1451 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1452 March 2008. 1454 11.2. Informative References 1456 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1457 Switching Networks", May 1974. 1459 [I-D.cheshire-dnsext-multicastdns] 1460 Cheshire, S. and M. Krochmal, "Multicast DNS", 1461 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1462 September 2008. 1464 [I-D.clausen-manet-autoconf-recommendations] 1465 Clausen, T. and U. Herberg, "MANET Router Configuration 1466 Recommendations", 1467 draft-clausen-manet-autoconf-recommendations-00 (work in 1468 progress), February 2009. 1470 [I-D.clausen-manet-linktype] 1471 Clausen, T., "The MANET Link Type", 1472 draft-clausen-manet-linktype-00 (work in progress), 1473 October 2008. 1475 [I-D.droms-dhc-dhcpv6-default-router] 1476 Droms, R. and T. Narten, "Default Router and Prefix 1477 Advertisement Options for DHCPv6", 1478 draft-droms-dhc-dhcpv6-default-router-00 (work in 1479 progress), March 2009. 1481 [I-D.ietf-autoconf-manetarch] 1482 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1483 Network Architecture", draft-ietf-autoconf-manetarch-07 1484 (work in progress), November 2007. 1486 [I-D.ietf-csi-proxy-send] 1487 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1488 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1489 in progress), November 2008. 1491 [I-D.ietf-dhc-subnet-alloc] 1492 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1493 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-09 1494 (work in progress), March 2009. 1496 [I-D.ietf-ipv6-ula-central] 1497 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1498 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1499 progress), June 2007. 1501 [I-D.ietf-manet-smf] 1502 Macker, J. and S. Team, "Simplified Multicast Forwarding 1503 for MANET", draft-ietf-manet-smf-08 (work in progress), 1504 November 2008. 1506 [I-D.ietf-v6ops-tunnel-security-concerns] 1507 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1508 Concerns With IP Tunneling", 1509 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1510 progress), October 2008. 1512 [I-D.jen-apt] 1513 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1514 L. Zhang, "APT: A Practical Transit Mapping Service", 1515 draft-jen-apt-01 (work in progress), November 2007. 1517 [I-D.russert-rangers] 1518 Russert, S., Fleischman, E., and F. Templin, "RANGER 1519 Scenarios", draft-russert-rangers-00 (work in progress), 1520 May 2009. 1522 [I-D.templin-intarea-seal] 1523 Templin, F., "The Subnetwork Encapsulation and Adaptation 1524 Layer (SEAL)", draft-templin-intarea-seal-04 (work in 1525 progress), June 2009. 1527 [I-D.templin-ranger] 1528 Templin, F., "Routing and Addressing in Next-Generation 1529 EnteRprises (RANGER)", draft-templin-ranger-07 (work in 1530 progress), February 2009. 1532 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1533 July 1978. 1535 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1536 Protocol Specification", October 2008. 1538 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1539 Communication Layers", STD 3, RFC 1122, October 1989. 1541 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1542 September 1991. 1544 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1545 Routing and Addressing Architecture", RFC 1753, 1546 December 1994. 1548 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1549 E. Lear, "Address Allocation for Private Internets", 1550 BCP 5, RFC 1918, February 1996. 1552 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1553 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1555 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1556 (MANET): Routing Protocol Performance Issues and 1557 Evaluation Considerations", RFC 2501, January 1999. 1559 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1560 Domains without Explicit Tunnels", RFC 2529, March 1999. 1562 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1563 February 2000. 1565 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1566 via IPv4 Clouds", RFC 3056, February 2001. 1568 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1569 Networks", BCP 84, RFC 3704, March 2004. 1571 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1572 RFC 3753, June 2004. 1574 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1575 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1576 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1577 RFC 3819, July 2004. 1579 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1580 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1581 May 2005. 1583 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1584 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1585 September 2005. 1587 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1588 Addresses", RFC 4193, October 2005. 1590 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1591 Internet Protocol", RFC 4301, December 2005. 1593 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1594 Network Address Translations (NATs)", RFC 4380, 1595 February 2006. 1597 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1598 Proxies (ND Proxy)", RFC 4389, April 2006. 1600 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1601 Multicast Name Resolution (LLMNR)", RFC 4795, 1602 January 2007. 1604 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1605 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1606 Focus", RFC 4852, April 2007. 1608 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1609 June 2007. 1611 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1612 Extensions for Stateless Address Autoconfiguration in 1613 IPv6", RFC 4941, September 2007. 1615 Appendix A. Duplicate Address Detection (DAD) Considerations 1617 A priori uniqueness determination (also known as "pre-service DAD") 1618 for an RLOC assigned on an enterprise-interior interface would 1619 require either flooding the entire enterprise or somehow discovering 1620 a link in the enterprise on which a node that configures a duplicate 1621 address is attached and performing a localized DAD exchange on that 1622 link. But, the control message overhead for such an enterprise-wide 1623 DAD would be substantial and prone to false-negatives due to packet 1624 loss and intermittent connectivity. An alternative to pre-service 1625 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1626 interfaces and employ a passive in-service DAD (e.g., one that 1627 monitors routing protocol messages for duplicate assignments). 1629 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1630 CGAs, IPv6 privacy addresses, etc. with very small probability of 1631 collision. Pseudo-random IPv4 RLOCs can be generated through random 1632 assignment from a suitably large IPv4 prefix space. 1634 Consistent operational practices can assure uniqueness for EBG- 1635 aggregated addresses/prefixes, while statistical properties for 1636 pseudo-random address self-generation can assure uniqueness for the 1637 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1638 RLOC delegation authority should be used when available, while a 1639 passive in-service DAD mechanism should be used to detect RLOC 1640 duplications when there is no RLOC delegation authority. 1642 Appendix B. Link Layer Multiplexing and Traffic Engineering 1644 For each distinct enterprise that it connects to, an EBR configures a 1645 VET interface over possibly multiple underlying interfaces that all 1646 connect to the same enterprise. The VET interface can then use the 1647 underlying interfaces for link layer multiplexing as described in 1648 Section 3.3.4 of [RFC1122]. The VET interface therefore can be 1649 viewed as the EBR's point of attachment to the enterprise. 1651 When an EBR autoconfigures an RLOC address (see Section 4.1), it can 1652 assign the RLOC to the VET interface instead of an underlying 1653 interface. The EBR only needs to obtain a single RLOC address if 1654 there are multiple underlying interfaces, i.e., it does not need to 1655 obtain one for each underlying interface. Each underlying interface 1656 can then either remain unnumbered, or it can configure a randomly 1657 chosen IPv4 link-local address from the prefix 169.254/16 [RFC3927] 1658 if the interface requires a configuration. This address need not be 1659 checked for uniqueness within the enterprise, as it will not normally 1660 be used as the source address for packets. 1662 Section 3.3.4 of [RFC1122] states that "the link-layer device driver" 1663 (i.e., the VET interface device driver) "is responsible for 1664 multiplexing and routing packets across the physical interfaces" 1665 (i.e., the underlying interfaces). The EBR must therefore provision 1666 the VET interface device driver with any RLOC-based routes that it 1667 learns from the enterprise interior routing protocol. 1669 When the EBR discovers an RLOC-based route via the enterprise 1670 interior routing protocol, it configures a preferred route in the IP 1671 FIB that points to the VET interface instead of the underlying 1672 interface. At the same time, the EBR also configures an ancillary 1673 route that points to the underlying interface. If the EBR discovers 1674 that the same RLOC-based route is reachable via multiple underlying 1675 interfaces, the EBR configures multiple ancillary routes (i.e., one 1676 for each interface). If the EBR discovers that the RLOC-based route 1677 is no longer reachable via any underlying interface, it removes the 1678 route in the IP FIB that points to the VET interface. 1680 With these arrangements, all locally-generated packets with RLOC 1681 destinations will flow through the VET interface (and thereby use its 1682 RLOC address as the source address) instead of through the underlying 1683 interfaces. In the same fashion, all forwarded packets with RLOC 1684 destinations will flow through the VET interface instead of through 1685 the underlying interfaces. 1687 This arrangement has several operational advantages that enable a 1688 number of traffic engineering capabilities. First, the VET interface 1689 can insert the SEAL header so that ID-based duplicate packet 1690 detection is enabled within the enterprise. Secondly, SEAL can 1691 dynamically adjust its packet sizing parameters so that an optimum 1692 Maximum Transmission Unit (MTU) can be determined. This is true even 1693 if the VET interface reroutes traffic between underlying interfaces 1694 with different MTUs. 1696 Moreover, the EBR can configure default and more-specific routes on 1697 the VET interface to direct traffic through a specific egress EBR 1698 (eEBR) that may be many hops away. Encapsulation will ensure that a 1699 specific eEBR is chosen, and the best eEBR can be chosen when 1700 multiple are available. Also, local applications see a stable IP 1701 source address even if there are multiple underlying interfaces. 1702 This link-layer multiplexing can therefore provide continuous 1703 operation across failovers between multiple links attached to the 1704 same enterprise without any need for readdressing. Finally, the VET 1705 interface can forward packets with RLOC-based destinations over an 1706 underlying interface without any encapsulation if encapsulation 1707 avoidance is desired. 1709 It must be specifically noted that the above arrangement constitutes 1710 a case in which the same RLOC may be used as both the inner and outer 1711 IP source address. This will not present a problem as long as both 1712 ends configure a VET interface in the same fashion. This can be 1713 determined based on a handshake between nodes, e.g., if one end 1714 supports SEAL encapsulation and the other does not the traffic 1715 engineering approach cannot be used. 1717 It must also be noted that EID-based communications can use the same 1718 VET interface arrangement, except that the EID-based next hop must be 1719 mapped to an RLOC-based next-hop within the VET interface. For IPvX- 1720 in-IPvX encapsulation, as well as for IPv4-in-IPv6 encapsulation, 1721 this requires a VET interface specific address mapping database. For 1722 IPv6-in-IPv4 encapsulation, the mapping is accomplished through 1723 simple static extraction of an IPv4 address embedded in an IPv6 1724 ISATAP address. 1726 Appendix C. Change Log 1728 (Note to RFC editor - this section to be removed before publication 1729 as an RFC.) 1731 Changes from RFC5558 to -00: 1733 o New appendix on RLOC configuration on VET intefaces. 1735 Author's Address 1737 Fred L. Templin (editor) 1738 Boeing Research & Technology 1739 P.O. Box 3707 MC 7L-49 1740 Seattle, WA 98124 1741 USA 1743 Email: fltemplin@acm.org