idnits 2.17.1 draft-templin-intarea-vet-31.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 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 299 has weird spacing: '...ET host any n...' -- The document date (November 18, 2011) is 4515 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-grow-va' is defined on line 1751, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-38 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** 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) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-14 == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-04 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-12 == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-05 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-16 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-12 == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-05 == Outdated reference: A later version (-12) exists of draft-templin-aero-04 == Outdated reference: A later version (-16) exists of draft-templin-ironbis-08 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 5 errors (**), 0 flaws (~~), 14 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 & Technology 4 Intended status: Standards Track November 18, 2011 5 Expires: May 21, 2012 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-31.txt 10 Abstract 12 Enterprise networks connect hosts and routers over various link 13 types, and often also connect to provider networks and/or the global 14 Internet. Enterprise network nodes require a means to automatically 15 provision addresses/prefixes and support internetworking operation in 16 a wide variety of use cases including Small Office, Home Office 17 (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, 18 multi-organizational corporate networks and the interdomain core of 19 the global Internet itself. This document specifies a Virtual 20 Enterprise Traversal (VET) abstraction for autoconfiguration and 21 operation of nodes in enterprise networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 21, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Enterprise Network Characteristics . . . . . . . . . . . . . . 11 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 13 61 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 13 62 4.2. VET Border Router (VBR) Autoconfiguration . . . . . . . . 15 63 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 15 64 4.2.2. Potential Router List (PRL) Discovery . . . . . . . . 16 65 4.2.3. Provider-Aggregated (PA) EID Prefix 66 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 67 4.2.4. ISP-Independent EID Prefix Autoconfiguration . . . . . 18 68 4.3. VET Border Gateway (VBG) Autoconfiguration . . . . . . . . 19 69 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 19 70 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 20 71 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 20 72 5.1.1. PI Prefix Routing Considerations . . . . . . . . . . . 21 73 5.1.2. Client Prefix (CP) Routing Considerations . . . . . . 21 74 5.2. Default Route Configuration and Selection . . . . . . . . 21 75 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 22 76 5.4. Next Hop Determination . . . . . . . . . . . . . . . . . . 22 77 5.5. VET Interface Encapsulation/Decapsulation . . . . . . . . 23 78 5.5.1. Inner Network Layer Protocol . . . . . . . . . . . . . 24 79 5.5.2. SEAL Encapsulation . . . . . . . . . . . . . . . . . . 24 80 5.5.3. Outer Transport-Layer Header Encapsulation . . . . . . 24 81 5.5.4. Outer IP Header Encapsulation . . . . . . . . . . . . 25 82 5.5.5. Decapsulation and Re-Encapsulation . . . . . . . . . . 26 83 5.6. Neighbor Coordination on VET Interfaces that use SEAL . . 26 84 5.6.1. Router Discovery . . . . . . . . . . . . . . . . . . . 28 85 5.6.2. Neighbor Unreachability Detection . . . . . . . . . . 28 86 5.6.3. Redirection . . . . . . . . . . . . . . . . . . . . . 28 87 5.6.4. Bidirectional Neighbor Synchronization . . . . . . . . 30 88 5.7. Neighbor Coordination on VET Interfaces using IPsec . . . 31 89 5.8. Mobility and Multihoming Considerations . . . . . . . . . 31 90 5.9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 32 91 5.9.1. Multicast over (Non)Multicast Enterprise Networks . . 32 92 5.9.2. Multicast Over Multicast-Capable Enterprise 93 Networks . . . . . . . . . . . . . . . . . . . . . . . 32 94 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 33 95 5.11. VET Link Partitioning . . . . . . . . . . . . . . . . . . 34 96 5.12. VBG Prefix State Recovery . . . . . . . . . . . . . . . . 34 97 5.13. Legacy ISATAP Services . . . . . . . . . . . . . . . . . . 34 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 100 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 35 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 102 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 37 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 38 106 Appendix A. Duplicate Address Detection (DAD) Considerations . . 43 107 Appendix B. Anycast Services . . . . . . . . . . . . . . . . . . 43 108 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 44 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 111 1. Introduction 113 Enterprise networks [RFC4852] connect hosts and routers over various 114 link types (see [RFC4861], Section 2.2). The term "enterprise 115 network" in this context extends to a wide variety of use cases and 116 deployment scenarios. For example, an "enterprise" can be as small 117 as a Small Office, Home Office (SOHO) network, as complex as a multi- 118 organizational corporation, or as large as the global Internet 119 itself. Internet Service Provider (ISP) networks are another example 120 use case that fits well with the VET enterprise network model. 121 Mobile Ad hoc Networks (MANETs) [RFC2501] can also be considered as a 122 challenging example of an enterprise network, in that their 123 topologies may change dynamically over time and that they may employ 124 little/no active management by a centralized network administrative 125 authority. These specialized characteristics for MANETs require 126 careful consideration, but the same principles apply equally to other 127 enterprise network scenarios. 129 This document specifies a Virtual Enterprise Traversal (VET) 130 abstraction for autoconfiguration and internetworking operation, 131 where addresses of different scopes may be assigned on various types 132 of interfaces with diverse properties. Both IPv4/ICMPv4 133 [RFC0791][RFC0792] and IPv6/ICMPv6 [RFC2460][RFC4443] are discussed 134 within this context (other network layer protocols are also 135 considered). The use of standard DHCP [RFC2131] [RFC3315] is assumed 136 unless otherwise specified. 138 Provider-Edge Interfaces 139 x x x 140 | | | 141 +--------------------+---+--------+----------+ E 142 | | | | | n 143 | I | | .... | | t 144 | n +---+---+--------+---+ | e 145 | t | +--------+ /| | r 146 | e I x----+ | Host | I /*+------+--< p I 147 | r n | |Function| n|**| | r n 148 | n t | +--------+ t|**| | i t 149 | a e x----+ V e|**+------+--< s e 150 | l r . | E r|**| . | e r 151 | f . | T f|**| . | f 152 | V a . | +--------+ a|**| . | I a 153 | i c . | | Router | c|**| . | n c 154 | r e x----+ |Function| e \*+------+--< t e 155 | t s | +--------+ \| | e s 156 | u +---+---+--------+---+ | r 157 | a | | .... | | i 158 | l | | | | o 159 +--------------------+---+--------+----------+ r 160 | | | 161 x x x 162 Enterprise-Edge Interfaces 164 Figure 1: Enterprise Router (ER) Architecture 166 Figure 1 above depicts the architectural model for an Enterprise 167 Router (ER). As shown in the figure, an ER may have a variety of 168 interface types including enterprise-edge, enterprise-interior, 169 provider-edge, internal-virtual, as well as VET interfaces used for 170 encapsulating inner network layer protocol packets for transmission 171 over outer IPv4 or IPv6 networks. The different types of interfaces 172 are defined, and the autoconfiguration mechanisms used for each type 173 are specified. This architecture applies equally for MANET routers, 174 in which enterprise-interior interfaces typically correspond to the 175 wireless multihop radio interfaces associated with MANETs. Out of 176 scope for this document is the autoconfiguration of provider 177 interfaces, which must be coordinated in a manner specific to the 178 service provider's network. 180 The VET framework builds on a Non-Broadcast Multiple Access (NBMA) 181 [RFC2491] virtual interface model in a manner similar to other 182 automatic tunneling technologies [RFC2529][RFC5214]. VET interfaces 183 support the encapsulation of inner network layer protocol packets 184 over IP networks (i.e., either IPv4 or IPv6), and provide an NBMA 185 interface abstraction for coordination between tunnel endpoint 186 "neighbors". VET is also compatible with mid-layer encapsulation 187 technologies including IPsec [RFC4301], and supports both stateful 188 and stateless prefix delegation. 190 VET and its associated technologies (including the Subnetwork 191 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] 192 and Asymmetric Extended Route Optimization (AERO) [I-D.templin-aero]) 193 are functional building blocks for a new Internetworking architecture 194 known as the Internet Routing Overlay Network (IRON) 195 [I-D.templin-ironbis] and Routing and Addressing in Networks with 196 Global Enterprise Recursion (RANGER) [RFC5720][RFC6139]. Many of the 197 VET principles can be traced to the deliberations of the ROAD group 198 in January 1992, and also to still earlier initiatives including 199 NIMROD [RFC1753] and the Catenet model for internetworking [CATENET] 200 [IEN48] [RFC2775]. The high-level architectural aspects of the ROAD 201 group deliberations are captured in a "New Scheme for Internet 202 Routing and Addressing (ENCAPS) for IPNG" [RFC1955]. 204 VET is related to the present-day activities of the IETF INTAREA, 205 AUTOCONF, DHC, IPv6, MANET, RENUM and V6OPS working groups, as well 206 as the IRTF RRG working group. 208 2. Terminology 210 The mechanisms within this document build upon the fundamental 211 principles of IP encapsulation. The term "inner" refers to the 212 innermost {address, protocol, header, packet, etc.} *before* 213 encapsulation, and the term "outer" refers to the outermost {address, 214 protocol, header, packet, etc.} *after* encapsulation. VET also 215 accommodates "mid-layer" encapsulations including SEAL 216 [I-D.templin-intarea-seal], IPsec [RFC4301], etc. 218 The terminology in the normative references apply; the following 219 terms are defined within the scope of this document: 221 Virtual Enterprise Traversal (VET) 222 an abstraction that uses encapsulation to create virtual overlays 223 for transporting inner network layer packets over outer IPv4 and 224 IPv6 enterprise networks. 226 enterprise network 227 the same as defined in [RFC4852]. An enterprise network is 228 further understood to refer to a cooperative networked collective 229 of devices within a structured IP routing and addressing plan and 230 with a commonality of business, social, political, etc., 231 interests. Minimally, the only commonality of interest in some 232 enterprise network scenarios may be the cooperative provisioning 233 of connectivity itself. 235 subnetwork 236 the same as defined in [RFC3819]. 238 site 239 a logical and/or physical grouping of interfaces that connect a 240 topological area less than or equal to an enterprise network in 241 scope. From a network organizational standpoint, a site within an 242 enterprise network can be considered as an enterprise network unto 243 itself. 245 Mobile Ad hoc Network (MANET) 246 a connected topology of mobile or fixed routers that maintain a 247 routing structure among themselves over links that often have 248 dynamic connectivity properties. The characteristics of MANETs 249 are described in [RFC2501], Section 3, and a wide variety of 250 MANETs share common properties with enterprise networks. 252 enterprise/site/MANET 253 throughout the remainder of this document, the term "enterprise 254 network" is used to collectively refer to any of {enterprise, 255 site, MANET}, i.e., the VET mechanisms and operational principles 256 can be applied to enterprises, sites, and MANETs of any size or 257 shape. 259 VET link 260 a virtual link that uses automatic tunneling to create an overlay 261 network that spans an enterprise network routing region. VET 262 links can be segmented (e.g., by filtering gateways) into multiple 263 distinct segments that can be joined together by bridges or IP 264 routers the same as for any link. Bridging would view the 265 multiple (bridged) segments as a single VET link, whereas IP 266 routing would view the multiple segments as multiple distinct VET 267 links. VET links can further be partitioned into multiple logical 268 areas, where each area is identified by a distinct set of border 269 nodes. 271 VET links configured over non-multicast enterprise networks 272 support only Non-Broadcast, Multiple Access (NBMA) services; VET 273 links configured over enterprise networks that support multicast 274 can support both NBMA and native multicast services. All nodes 275 connected to the same VET link appear as neighbors from the 276 standpoint of the inner network layer. 278 Enterprise Router (ER) 279 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 280 mobile router that comprises a router function, a host function, 281 one or more enterprise-interior interfaces, and zero or more 282 internal virtual, enterprise-edge, provider-edge, and VET 283 interfaces. At a minimum, an ER forwards outer IP packets over 284 one or more sets of enterprise-interior interfaces, where each set 285 connects to a distinct enterprise network. 287 VET Border Router (VBR) 288 an ER that connects end user networks (EUNs) to VET links and/or 289 connects multiple VET links together. A VBR is a tunnel endpoint 290 router, and it configures a separate VET interface for each 291 distinct VET link. All VBRs are also ERs. 293 VET Border Gateway (VBG) 294 a VBR that connects VET links to provider networks. A VBG may 295 alternately act as a "half-gateway", and forward the packets it 296 receives from neighbors on the VET link to another VBG on the same 297 VET link. All VBGs are also VBRs. 299 VET host any node (host or router) that configures a VET interface 300 for host-operation only. Note that a node may configure some of 301 its VET interfaces as host interfaces and others as router 302 interfaces. 304 VET node 305 any node (host or router) that configures and uses a VET 306 interface. 308 enterprise-interior interface 309 an ER's attachment to a link within an enterprise network. 310 Packets sent over enterprise-interior interfaces may be forwarded 311 over multiple additional enterprise-interior interfaces before 312 they reach either their final destination or a border router/ 313 gateway. Enterprise-interior interfaces connect laterally within 314 the IP network hierarchy. 316 enterprise-edge interface 317 a VBR's attachment to a link (e.g., an Ethernet, a wireless 318 personal area network, etc.) on an arbitrarily complex EUN that 319 the VBR connects to a VET link and/or a provider network. 320 Enterprise-edge interfaces connect to lower levels within the IP 321 network hierarchy. 323 provider-edge interface 324 a VBR's attachment to the Internet or to a provider network via 325 which the Internet can be reached. Provider-edge interfaces 326 connect to higher levels within the IP network hierarchy. 328 internal-virtual interface 329 an interface that is internal to a VET node and does not in itself 330 directly attach to a tangible link, e.g., a loopback interface. 332 VET interface 333 a VET node's attachment to a VET link. VET nodes configure each 334 VET interface over a set of underlying enterprise-interior 335 interfaces that connect to a routing region spanned by a single 336 VET link. When there are multiple distinct VET links (each with 337 their own distinct set of underlying interfaces), the VET node 338 configures a separate VET interface for each link. 340 The VET interface encapsulates each inner packet in any mid-layer 341 headers followed by an outer IP header, then forwards the packet 342 on an underlying interface such that the Time to Live (TTL) - Hop 343 Limit in the inner header is not decremented as the packet 344 traverses the link. The VET interface therefore presents an 345 automatic tunneling abstraction that represents the VET link as a 346 single hop to the inner network layer. 348 Provider Aggregated (PA) prefix 349 a network layer protocol prefix that is delegated to a VET node by 350 a provider network. 352 Provider Independent (PI) prefix 353 a network layer protocol prefix that is delegated to a VET node by 354 an independent registration authority. The VET node then becomes 355 solely responsible for representing the PI prefix into the global 356 Internet routing system on its own behalf. 358 Client Prefix (CP) 359 a network layer protocol prefix that is delegated to a VET node by 360 a Virtual Service Provider (VSP) that may operate independently of 361 the node's provider networks. The term "Client Prefix (CP)" is 362 the same as used in IRON [I-D.templin-ironbis]. 364 Routing Locator (RLOC) 365 a public-scope or enterprise-local-scope IP address that can 366 appear in enterprise-interior and/or interdomain routing tables. 367 Public-scope RLOCs are delegated to specific enterprise networks 368 and routable within both the enterprise-interior and interdomain 369 routing regions. Enterprise-local-scope RLOCs (e.g., IPv6 Unique 370 Local Addresses [RFC4193], IPv4 privacy addresses [RFC1918], etc.) 371 are self-generated by individual enterprise networks and routable 372 only within the enterprise-interior routing region. 374 ERs use RLOCs for operating the enterprise-interior routing 375 protocol and for next-hop determination in forwarding packets 376 addressed to other RLOCs. End systems can use RLOCs as addresses 377 for end-to-end communications between peers within the same 378 enterprise network. VET interfaces treat RLOCs as *outer* IP 379 addresses during encapsulation. 381 Endpoint Interface iDentifier (EID) 382 a public-scope network layer address that is routable within 383 enterprise-edge and/or VET overlay networks. In a pure mapping 384 system, EID prefixes are not routable within the interdomain 385 routing system. In a hybrid routing/mapping system, EID prefixes 386 may be represented within the same interdomain routing instances 387 that distribute RLOC prefixes. In either case, EID prefixes are 388 separate and distinct from any RLOC prefix space, but they are 389 mapped to RLOC addresses to support packet forwarding over VET 390 interfaces. 392 VBRs participate in any EID-based routing instances and use EID 393 addresses for next-hop determination. End systems can use EIDs as 394 addresses for end-to-end communications between peers either 395 within the same enterprise network or within different enterprise 396 networks. VET interfaces treat EIDs as *inner* network layer 397 addresses during encapsulation. 399 Note that an EID can also be used as an *outer* network layer 400 address if there are nested encapsulations. In that case, the EID 401 would appear as an RLOC to the innermost encapsulation. 403 The following additional acronyms are used throughout the document: 405 CGA - Cryptographically Generated Address 406 DHCP(v4, v6) - Dynamic Host Configuration Protocol 407 ECMP - Equal Cost Multi Path 408 EUN - End User Network 409 FIB - Forwarding Information Base 410 ICMP - either ICMPv4 or ICMPv6 411 IP - either IPv4 or IPv6 412 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 413 NBMA - Non-Broadcast, Multiple Access 414 ND - Neighbor Discovery 415 PIO - Prefix Information Option 416 PRL - Potential Router List 417 PRLNAME - Identifying name for the PRL 418 RIB - Routing Information Base 419 RIO - Route Information Option 420 SCMP - SEAL Control Message Protocol 421 SEAL - Subnetwork Encapsulation and Adaptation Layer 422 SLAAC - IPv6 StateLess Address AutoConfiguration 423 SNS/SNA - SCMP Neighbor Solicitation/Advertisement 424 SRD - SCMP Redirect 425 SRS/SRA - SCMP Router Solicitation/Advertisement 427 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 428 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 429 document are to be interpreted as described in [RFC2119]. When used 430 in lower case (e.g., must, must not, etc.), these words MUST NOT be 431 interpreted as described in [RFC2119], but are rather interpreted as 432 they would be in common English. 434 3. Enterprise Network Characteristics 436 Enterprise networks consist of links that are connected by Enterprise 437 Routers (ERs) as depicted in Figure 1. ERs typically participate in 438 a routing protocol over enterprise-interior interfaces to discover 439 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 440 VET Border Routers (VBRs) are ERs that connect End User Networks 441 (EUNs) to VET links that span enterprise networks. VET Border 442 Gateways (VBGs) are VBRs that connect VET links to provider networks. 444 Conceptually, an ER embodies both a host function and router 445 function, and supports communications according to the weak end- 446 system model [RFC1122]. The router function engages in the 447 enterprise-interior routing protocol on its enterprise-interior 448 interfaces, connects any of the ER's EUNs to its VET links, and may 449 also connect the VET links to provider networks (see Figure 1). The 450 host function typically supports network management applications, but 451 may also support diverse applications typically associated with 452 general-purpose computing platforms. 454 An enterprise network may be as simple as a small collection of ERs 455 and their attached EUNs; an enterprise network may also contain other 456 enterprise networks and/or be a subnetwork of a larger enterprise 457 network. An enterprise network may further encompass a set of branch 458 offices and/or nomadic hosts connected to a home office over one or 459 several service providers, e.g., through Virtual Private Network 460 (VPN) tunnels. Finally, an enterprise network may contain many 461 internal partitions that are logical or physical groupings of nodes 462 for the purpose of load balancing, organizational separation, etc. 463 In that case, each internal partition resembles an individual segment 464 of a bridged LAN. 466 Enterprise networks that comprise link types with sufficiently 467 similar properties (e.g., Layer 2 (L2) address formats, maximum 468 transmission units (MTUs), etc.) can configure a subnetwork routing 469 service such that the network layer sees the underlying network as an 470 ordinary shared link the same as for a (bridged) campus LAN (this is 471 often the case with large cellular operator networks). In that case, 472 a single network layer hop is sufficient to traverse the underlying 473 network. Enterprise networks that comprise link types with diverse 474 properties and/or configure multiple IP subnets must also provide an 475 enterprise-interior routing service that operates as an IP layer 476 mechanism. In that case, multiple network layer hops may be 477 necessary to traverse the underlying network. 479 In addition to other interface types, VET nodes configure VET 480 interfaces that view all other nodes on the VET link as neighbors on 481 a virtual NBMA link. VET nodes configure a separate VET interface 482 for each distinct VET link to which they connect, and discover 483 neighbors on the link that can be used for forwarding packets to off- 484 link destinations. VET interface neighbor relationships may be 485 either unidirectional or bidirectional. 487 A unidirectional neighbor relationship is typically established and 488 maintained as a result of network layer control protocol messaging in 489 a manner that parallels IPv6 neighbor discovery [RFC4861]. A 490 bidirectional neighbor relationship is typically established and 491 maintained as result of a short transaction between the neighbors 492 (see: Section 5.6.4). 494 For each distinct VET link , a trust basis must be established and 495 consistently applied. For example, for VET links configured over 496 enterprise networks in which VBRs establish symmetric security 497 associations, mechanisms such as IPsec [RFC4301] can be used to 498 assure authentication and confidentiality. In other enterprise 499 network scenarios, VET links may require asymmetric securing 500 mechanisms such as SEcure Neighbor Discovery (SEND) [RFC3971]. VET 501 links configured over still other enterprise networks may find it 502 sufficient to employ ancillary encapsulations (e.g., SEAL 503 [I-D.templin-intarea-seal]) that provide minimal authentication 504 services such as source address validation [I-D.ietf-savi-framework]. 506 Finally, for VET links configured over enterprise networks with a 507 centralized management structure (e.g., a corporate campus network, 508 an ISP network, etc.), a hybrid routing/mapping service can be 509 deployed using a synchronized set of VBGs. In that case, the VBGs 510 can provide a "default mapper" [I-D.jen-apt] service used for short- 511 term packet forwarding until route-optimized paths can be 512 established. For VET links configured over enterprise networks with 513 a distributed management structure (e.g., disconnected MANETs), peer- 514 to-peer coordination between the VET nodes themselves without the 515 assistance of VBGs may be required. Recognizing that various use 516 cases may entail a continuum between a fully centralized and fully 517 distributed approach, the following sections present the mechanisms 518 of Virtual Enterprise Traversal as they apply to a wide variety of 519 scenarios. 521 4. Autoconfiguration 523 ERs, VBRs, VBGs, and VET hosts configure themselves for operation as 524 specified in the following subsections. 526 4.1. Enterprise Router (ER) Autoconfiguration 528 ERs configure enterprise-interior interfaces and engage in any 529 routing protocols over those interfaces. 531 When an ER joins an enterprise network, it first configures an IPv6 532 link-local address on each enterprise-interior interface that 533 requires an IPv6 link-local capability and configures an IPv4 link- 534 local address on each enterprise-interior interface that requires an 535 IPv4 link-local capability. IPv6 link-local address generation 536 mechanisms include Cryptographically Generated Addresses (CGAs) 537 [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 538 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 539 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 540 provide an IPv4 link-local address generation capability. 542 Next, the ER configures one or more RLOCs and engages in any routing 543 protocols on its enterprise-interior interfaces. The ER can 544 configure RLOCs via administrative configuration, pseudo-random self- 545 generation from a suitably large address pool, SLAAC, DHCP 546 autoconfiguration, or through an alternate autoconfiguration 547 mechanism. 549 Pseudo-random self-generation of IPv6 RLOCs can be from a large 550 public or local-use IPv6 address range (e.g., IPv6 Unique Local 551 Addresses [RFC4193]). Pseudo-random self-generation of IPv4 RLOCs 552 can be from a large public or local-use IPv4 address range (e.g., 553 [RFC1918]). When self-generation is used alone, the ER continuously 554 monitors the RLOCs for uniqueness, e.g., by monitoring the 555 enterprise-interior routing protocol. (Note however that anycast 556 RLOCs may be assigned to multiple enterprise-interior interfaces; 557 hence, monitoring for uniqueness applies only to RLOCs that are 558 provisioned as unicast.) 560 SLAAC autoconfiguration of RLOCs can be through the receipt of IPv6 561 Router Advertisements (RAs) followed by the stateless configuration 562 of addresses based on any included Prefix Information Options (PIOs) 563 [RFC4861][RFC4862]. 565 DHCP autoconfiguration of RLOCs uses standard DHCP procedures, 566 however ERs acting as DHCP clients SHOULD also use DHCP 567 Authentication [RFC3118] [RFC3315] as discussed further below. In 568 typical enterprise network scenarios (i.e., those with stable links), 569 it may be sufficient to configure one or a few DHCP relays on each 570 link that does not include a DHCP server. In more extreme scenarios 571 (e.g., MANETs that include links with dynamic connectivity 572 properties), DHCP operation may require any ERs that have already 573 configured RLOCs to act as DHCP relays to ensure that client DHCP 574 requests eventually reach a DHCP server. This may result in 575 considerable DHCP message relaying until a server is located, but the 576 DHCP Authentication Replay Detection vector provides relays with a 577 means for avoiding message duplication. 579 In all enterprise network scenarios, the amount of DHCP relaying 580 required can be significantly reduced if each relay has a way of 581 contacting a DHCP server directly. In particular, if the relay can 582 discover the unicast addresses for one or more servers (e.g., by 583 discovering the unicast RLOC addresses of VBGs as described in 584 Section 4.2.2) it can forward DHCP requests directly to the unicast 585 address(es) of the server(s). If the relay does not know the unicast 586 address of a server, it can forward DHCP requests to a site-scoped 587 DHCP server multicast address if the enterprise network supports 588 site-scoped multicast services. For DHCPv6, relays can forward 589 requests to the site-scoped IPv6 multicast group address 590 'All_DHCP_Servers' [RFC3315]. For DHCPv4, relays can forward 591 requests to the site-scoped IPv4 multicast group address 592 'All_DHCPv4_Servers', which SHOULD be set to 239.255.2.1 unless an 593 alternate multicast group for the enterprise network is known. 594 DHCPv4 servers that delegate RLOCs SHOULD therefore join the 595 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 596 received for that group. 598 A combined approach using both DHCP and self-generation is also 599 possible when the ER configures both a DHCP client and relay that are 600 connected, e.g., via a pair of back-to-back connected Ethernet 601 interfaces, a tun/tap interface, a loopback interface, inter-process 602 communication, etc. The ER first self-generates an RLOC taken from a 603 temporary addressing range used only for the bootstrapping purpose of 604 procuring an actual RLOC taken from a delegated addressing range. 605 The ER then engages in the enterprise-interior routing protocol and 606 performs a DHCP exchange as above using the temporary RLOC as the 607 address of its relay function. When the DHCP server delegates an 608 actual RLOC address/prefix, the ER abandons the temporary RLOC and 609 re-engages in the enterprise-interior routing protocol using an RLOC 610 taken from the delegation. 612 Alternatively (or in addition to the above), the ER can request RLOC 613 prefix delegations via an automated prefix delegation exchange over 614 an enterprise-interior interface and can assign the prefix(es) on 615 enterprise-edge interfaces. Note that in some cases, the same 616 enterprise-edge interfaces may assign both RLOC and EID addresses if 617 there is a means for source address selection. In other cases (e.g., 618 for separation of security domains), RLOCs and EIDs are assigned on 619 separate sets of enterprise-edge interfaces. 621 In some enterprise network scenarios (e.g., MANETs that include links 622 with dynamic connectivity properties), assignment of RLOCs on 623 enterprise-interior interfaces as singleton addresses (i.e., as 624 addresses with /32 prefix lengths for IPv4, or as addresses with /128 625 prefix lengths for IPv6) MAY be necessary to avoid multi-link subnet 626 issues [RFC4903]. 628 4.2. VET Border Router (VBR) Autoconfiguration 630 VBRs are ERs that configure and use one or more VET interfaces. In 631 addition to the ER autoconfiguration procedures specified in 632 Section 4.1, VBRs perform the following autoconfiguration operations. 634 4.2.1. VET Interface Initialization 636 VBRs configure a separate VET interface for each VET link, where each 637 VET link spans a distinct sets of underlying links belonging to the 638 same enterprise network. All nodes on the VET link appear as single- 639 hop neighbors from the standpoint of the inner network layer protocol 640 through the use of encapsulation. 642 The VBR binds each VET interface to one or more underlying 643 interfaces, and uses the underlying interface addresses as RLOCs to 644 serve as the outer source addresses for encapsulated packets. The 645 VBR then assigns a link-local address to each VET interface if 646 necessary. When IPv6 and IPv4 are used as the inner/outer protocols 647 (respectively), the VBR can autoconfigure an IPv6 link-local address 648 on the VET interface using a modified EUI-64 interface identifier 649 based on an IPv4 RLOC address (see Section 2.2.1 of [RFC5342]). 650 Link-local address configuration for other inner/outer protocol 651 combinations is through administrative configuration, random self- 652 generation (e.g., [RFC4941], etc.) or through an unspecified 653 alternate method. 655 4.2.2. Potential Router List (PRL) Discovery 657 After initializing the VET interface, the VBR next discovers a 658 Potential Router List (PRL) for the VET link that includes the RLOC 659 addresses of VBGs. The PRL can be discovered through administrative 660 configuration, information conveyed in the enterprise-interior 661 routing protocol, an anycast VBG discovery message exchange, a DHCP 662 option, etc. In multicast-capable enterprise networks, VBRs can also 663 listen for advertisements on the 'rasadv' [RASADV] multicast group 664 address. 666 When no other information is available, the VBR can resolve an 667 identifying name for the PRL ('PRLNAME') formed as 668 'hostname.domainname', where 'hostname' is an enterprise-specific 669 name string and 'domainname' is an enterprise-specific Domain Name 670 System (DNS) suffix [RFC1035]. The VBR discovers 'PRLNAME' through 671 administrative configuration, the DHCP Domain Name option [RFC2132], 672 'rasadv' protocol advertisements, link-layer information (e.g., an 673 IEEE 802.11 Service Set Identifier (SSID)), or through some other 674 means specific to the enterprise network. The VBR can also obtain 675 'PRLNAME' as part of an arrangement with a private-sector Virtual 676 Service Provider (VSP) (see: Section 4.2.4). 678 In the absence of other information, the VBR sets the 'hostname' 679 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 680 component to an enterprise-specific DNS suffix (e.g., "example.com"). 681 Isolated enterprise networks that do not connect to the outside world 682 may have no enterprise-specific DNS suffix, in which case the 683 'PRLNAME' consists only of the 'hostname' component. (Note that the 684 default hostname "isatapv2" is intentionally distinct from the 685 convention specified in [RFC5214].) 687 After discovering 'PRLNAME', the VBR resolves the name into a list of 688 RLOC addresses through a name service lookup. For centrally managed 689 enterprise networks, the VBR resolves 'PRLNAME' using an enterprise- 690 local name service (e.g., the DNS). For enterprises with no 691 centralized management structure, the VBR resolves 'PRLNAME' using a 692 distributed name service query such as Link-Local Multicast Name 693 Resolution (LLMNR) [RFC4795] over the VET interface. In that case, 694 all VBGs in the PRL respond to the query, and the VBR accepts the 695 union of all responses. 697 4.2.3. Provider-Aggregated (PA) EID Prefix Autoconfiguration 699 VBRs that connect their enterprise networks to a provider network can 700 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 701 stateless autoconfiguration mechanisms. The stateful and stateless 702 approaches are discussed in the following subsections. 704 4.2.3.1. Stateful Prefix Delegation 706 For IPv4, VBRs acquire IPv4 PA EID prefixes through administrative 707 configuration, an automated IPv4 prefix delegation exchange, etc. 709 For IPv6, VBRs acquire IPv6 PA EID prefixes through administrative 710 configuration or through DHCPv6 Prefix Delegation exchanges with a 711 VBG acting as a DHCP relay/server. In particular, the VBR (acting as 712 a requesting router) can use DHCPv6 prefix delegation [RFC3633] over 713 the VET interface to obtain prefixes from the VBG (acting as a 714 delegating router). The VBR obtains prefixes using either a 715 2-message or 4-message DHCPv6 exchange [RFC3315]. When the VBR acts 716 as a DHCPv6 client, it maps the IPv6 717 "All_DHCP_Relay_Agents_and_Servers" link- scoped multicast address to 718 the VBG's outer RLOC address. 720 To perform the 2-message exchange, the VBR's DHCPv6 client function 721 can send a Solicit message with an IA_PD option either directly or 722 via the VBR's own DHCPv6 relay function (see Section 4.1). The VBR's 723 VET interface then forwards the message using VET encapsulation (see: 724 Section 5.4) to a VBG which either services the request or relays it 725 further. The forwarded Solicit message will elicit a Reply message 726 from the server containing prefix delegations. The VBR can also 727 propose a specific prefix to the DHCPv6 server per Section 7 of 728 [RFC3633]. The server will check the proposed prefix for consistency 729 and uniqueness, then return it in the Reply message if it was able to 730 perform the delegation. 732 After the VBR receives IPv4 and/or IPv6 prefix delegations, it can 733 provision the prefixes on enterprise-edge interfaces as well as on 734 other VET interfaces configured over child enterprise networks for 735 which it acts as a VBG. The VBR can also provision the prefixes on 736 enterprise-interior interfaces to service directly-attached hosts on 737 the enterprise-interior link. 739 The prefix delegations remain active as long as the VBR continues to 740 renew them via the delegating VBG before lease lifetimes expire. The 741 lease lifetime also keeps the delegation state active even if 742 communications between the VBR and delegating VBG are disrupted for a 743 period of time (e.g., due to an enterprise network partition, power 744 failure, etc.). Note however that if the VBR abandons or otherwise 745 loses continuity with the prefixes, it may be obliged to perform 746 network-wide renumbering if it subsequently receives a new and 747 different set of prefixes. 749 Stateful prefix delegation for non-IP protocols is out of scope. 751 4.2.3.2. Stateless Prefix Delegation 753 When IPv6 and IPv4 are used as the inner and outer protocols, 754 respectively, a stateless IPv6 PA prefix delegation capability is 755 available using the mechanisms specified in 756 [RFC5214][RFC5569][RFC5969]. VBRs can use these mechanisms to 757 statelessly configure IPv6 PA prefixes that embed one of the VBR's 758 IPv4 RLOCs. 760 Using this stateless prefix delegation, if the IPv4 RLOC changes the 761 IPv6 prefix also changes and the VBR is obliged to renumber any 762 interfaces on which sub-prefixes from the delegated prefix are 763 assigned. This method may therefore be most suitable for enterprise 764 networks in which IPv4 RLOC assignments rarely change, or in 765 enterprise networks in which only services that do not depend on a 766 long-term stable IPv6 prefix (e.g., client-side web browsing) are 767 used. 769 Stateless prefix delegation for other protocol combinations is out of 770 scope. 772 4.2.4. ISP-Independent EID Prefix Autoconfiguration 774 VBRs can acquire ISP-independent prefixes to facilitate multihoming, 775 mobility and traffic engineering without requiring site-wide 776 renumbering events due to a change in ISP connections. 778 VBRs that connect major enterprise networks (e.g., large 779 corporations, academic campuses, ISP networks, etc.) to the global 780 Internet can acquire short Provider-Independent (PI) prefixes (e.g., 781 an IPv6 ::/32, an IPv4 /16, etc.) through a registration authority 782 such as the Internet Assigned Numbers Authority (IANA) or a major 783 regional Internet registry. The VBR then advertises the PI prefixes 784 into the global Internet on the behalf of its enterprise network 785 without the assistance of an ISP. 787 VBRs that connect enterprise networks to a provider network can 788 acquire longer Client Prefixes (CPs) (e.g., an IPv6 ::/56, an IPv4 789 /24, etc.) through arrangements with a Virtual Service Provider (VSP) 790 that may or may not be associated with a specific ISP. The VBR then 791 coordinates its CPs with a VSP independently of any of its directly 792 attached ISPs. (In many cases, the "VSP" may in fact be a major 793 enterprise network that delegates CPs from its PI prefixes.) 795 After a VBR receives prefix delegations, it can sub-delegate portions 796 of the prefixes on enterprise-edge interfaces, on child VET 797 interfaces for which it is configured as a VBG and on enterprise- 798 interior interfaces to service directly-attached hosts on the 799 enterprise-interior link. The VBR can also sub-delegate portions of 800 its prefixes to requesting routers connected to child enterprise 801 networks. These requesting routers consider their sub-delegated 802 prefixes as PA, and consider the delegating routers as their points 803 of connection to a provider network. 805 4.3. VET Border Gateway (VBG) Autoconfiguration 807 VBGs are VBRs that connect VET links configured over child enterprise 808 networks to provider networks via provider-edge interfaces and/or via 809 VET links configured over parent enterprise networks. A VBG may also 810 act as a "half-gateway", in that it may need to forward the packets 811 it receives from neighbors on the VET link via another VBG associated 812 with the same VET link. This arrangement is seen in the IRON 813 [I-D.templin-ironbis] Client/Server/Relay architecture, in which a 814 Server "half-gateway" is a VBG that forwards packets with enterprise- 815 external destinations via a Relay "half-gateway" that connects the 816 VET link to the provider network. 818 VBGs autoconfigure their provider-edge interfaces in a manner that is 819 specific to the provider connections, and they autoconfigure their 820 VET interfaces that were configured over parent VET links using the 821 VBR autoconfiguration procedures specified in Section 4.2. For each 822 of its VET interfaces connected to child VET links, the VBG 823 initializes the interface the same as for an ordinary VBR (see 824 Section 4.2.1). It then arranges to add one or more of its RLOCs 825 associated with the child VET link to the PRL. 827 VBGs configure a DHCP relay/server on VET interfaces connected to 828 child VET links that require DHCP services. VBGs may also engage in 829 an unspecified anycast VBG discovery message exchange if they are 830 configured to do so. Finally, VBGs respond to distributed name 831 service queries for 'PRLNAME' on VET interfaces connected to VET 832 links that span child enterprise networks with a distributed 833 management structure. 835 4.4. VET Host Autoconfiguration 837 Nodes that cannot be attached via a VBR's enterprise-edge interface 838 (e.g., nomadic laptops that connect to a home office via a Virtual 839 Private Network (VPN)) can instead be configured for operation as a 840 simple host on the VET link. Each VET host performs the same 841 enterprise interior interface RLOC configuration procedures as 842 specified for ERs in Section 4.1. The VET host next performs the 843 same VET interface initialization and PRL discovery procedures as 844 specified for VBRs in Section 4.2, except that it configures its VET 845 interfaces as host interfaces (and not router interfaces). Note also 846 that a node may be configured as a host on some VET interfaces and as 847 a VBR/VBG on other VET interfaces. 849 A VET host may receive non-link-local addresses and/or prefixes to 850 assign to the VET interface via DHCP exchanges and/or through SLAAC 851 information conveyed in RAs. If prefixes are provided, however, 852 there must be assurance that either 1) the VET link will not 853 partition, or 2) that each VET host interface connected to the VET 854 link will configure a unique set of prefixes. VET hosts therefore 855 depend on DHCP and/or RA exchanges to provide only addresses/prefixes 856 that are appropriate for assignment to the VET interface according to 857 these specific cases, and depend on the VBGs within the enterprise 858 keeping track of which addresses/prefixes were assigned to which 859 hosts. 861 When the VET host solicits a DHCP-assigned EID address/prefix over a 862 (non-multicast) VET interface, it maps the DHCP relay/server 863 multicast inner destination address to the outer RLOC address of a 864 VBG that it has selected as a default router. The VET host then 865 assigns any resulting DHCP-delegated addresses/prefixes to the VET 866 interface for use as the source address of inner packets. The host 867 will subsequently send all packets destined to EID correspondents via 868 a default router on the VET link, and may discover more-specific 869 routes based on any redirect messages it receives. 871 5. Internetworking Operation 873 Following the autoconfiguration procedures specified in Section 4, 874 ERs, VBRs, VBGs, and VET hosts engage in normal internetworking 875 operations as discussed in the following sections. 877 5.1. Routing Protocol Participation 879 ERs engage in any RLOC-based routing protocols over enterprise- 880 interior interfaces to exchange routing information for forwarding IP 881 packets with RLOC addresses. VBRs and VBGs can additionally engage 882 in any EID-based routing protocols over VET, enterprise-edge and 883 provider-edge interfaces to exchange routing information for 884 forwarding inner network layer packets with EID addresses. Note that 885 any EID-based routing instances are separate and distinct from any 886 RLOC-based routing instances. 888 VBR/VBG routing protocol participation on non-multicast VET 889 interfaces uses the NBMA interface model, e.g., in the same manner as 890 for OSPF over NBMA interfaces [RFC5340]. (VBR/VBG routing protocol 891 participation on multicast-capable VET interfaces can alternatively 892 use the standard multicast interface model, but this may result in 893 excessive multicast control message overhead.) 894 VBRs can use the list of VBGs in the PRL (see: Section 4.2.1) as an 895 initial list of neighbors for EID-based routing protocol 896 participation. VBRs can alternatively use the list of VBGs as 897 potential default routers instead of engaging in an EID-based routing 898 protocol instance. In that case, when the VBR forwards a packet via 899 a VBG it may receive a redirect message indicating a different VET 900 node as a better next hop. 902 5.1.1. PI Prefix Routing Considerations 904 VBRs that connect large enterprise networks to the global Internet 905 advertise their EID PI prefixes directly into the Internet default- 906 free RIB via the Border Gateway Protocol (BGP) [RFC4271] on their own 907 behalf the same as for a major service provider network. VBRs that 908 connect large enterprise networks to provider networks can instead 909 advertise their EID PI prefixes into their providers' routing 910 system(s) if the provider networks are configured to accept them. 912 5.1.2. Client Prefix (CP) Routing Considerations 914 VBRs that obtain CPs from a VSP can register them with a serving VBG 915 in the VSP's network (e.g., through a vendor-specific short TCP 916 transaction). The VSP network then acts as a virtual "home" 917 enterprise network that connects its customer enterprise networks to 918 the Internet routing system. The customer enterprise networks in 919 turn appear as mobile components of the VSP's network, while the 920 customer network uses its ISP connections solely as transits. (In 921 many cases, the "VSP" may itself be a major enterprise network that 922 delegates CPs from its PI prefixes to child enterprise networks.) 924 5.2. Default Route Configuration and Selection 926 Configuration of default routes in the presence of VET interfaces 927 must be carefully coordinated according to the inner and outer 928 network protocols. If the inner and outer protocols are different 929 (e.g., IPv6 within IPv4) then default routes of the inner protocol 930 version can be configured with next-hops corresponding to default 931 routers on a VET interface while default routes of the outer protocol 932 version can be configured with next-hops corresponding to default 933 routers on an underlying interface. 935 If the inner and outer protocols are the same (e.g., IPv4 within 936 IPv4), care must be taken in setting the default route to avoid 937 ambiguity. For example, if default routes are configured on the VET 938 interface then more-specific routes could be configured on underlying 939 interfaces to avoid looping. Alternatively, multiple default routes 940 can be configured with some having next-hops corresponding to (EID- 941 based) default routers on VET interfaces and others having next-hops 942 corresponding to (RLOC-based) default routers on underlying 943 interfaces. In that case, special next-hop determination rules must 944 be used (see: Section 5.4). 946 5.3. Address Selection 948 When permitted by policy and supported by enterprise-interior 949 routing, VET nodes can avoid encapsulation through communications 950 that directly invoke the outer IP protocol using RLOC addresses 951 instead of EID addresses for end-to-end communications. For example, 952 an enterprise network that provides native IPv4 intra-enterprise 953 services can provide continued support for native IPv4 communications 954 even when encapsulated IPv6 services are available for inter- 955 enterprise communications. 957 In other enterprise network scenarios, the use of EID-based 958 communications (i.e., instead of RLOC-based communications) may be 959 necessary and/or beneficial to support address scaling, transparent 960 Network Address Translator (NAT) traversal, security domain 961 separation, site multihoming, traffic engineering, etc. . 963 VET nodes can use source address selection rules (e.g., based on name 964 service information) to determine whether to use EID-based or RLOC- 965 based addressing. The remainder of this section discusses 966 internetworking operation for EID-based communications using the VET 967 interface abstraction. 969 5.4. Next Hop Determination 971 VET nodes perform normal next-hop determination via longest prefix 972 match, and send packets according to the most-specific matching entry 973 in the FIB. If the FIB entry has multiple next-hop addresses, the 974 VET node selects the next-hop with the best metric value. If 975 multiple next hops have the same metric value, the VET node can use 976 Equal Cost Multi Path (ECMP) to forward different flows via different 977 next-hop addresses, where flows are determined, e.g., by computing a 978 hash of the inner packet's source address, destination address and 979 flow label fields. 981 If the VET node has multiple default routes of the same inner and 982 outer protocol versions, with some corresponding to EID-based default 983 routers and others corresponding to RLOC-based default routers, it 984 must perform source address based selection of a default route. In 985 particular, if the packet's source address is taken from an EID 986 prefix the VET node selects a default route configured over the VET 987 interface; otherwise, it selects a default route configured over an 988 underlying interface. 990 As a last resort when there is no matching entry in the FIB (i.e., 991 not even default), VET nodes can discover neighbors within the 992 enterprise network through on-demand name service queries for the 993 packet's destination address (or, by some other inner address to 994 outer address mapping distribution system). For example, for the 995 IPv6 destination address '2001:DB8:1:2::1' and 'PRLNAME' 996 "isatapv2.example.com" the VET node can perform a name service lookup 997 for the domain name: 998 '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6. 999 isatapv2.example.com'. 1001 The name service can employ wildcard matching (e.g., [RFC4592]) to 1002 determine the most-specific matching entry. For example, if the 1003 most-specific prefix that covers the IPv6 destination address is 1004 '2001:DB8:1::/48' the matching entry is: 1006 '*.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 1008 If the name-service lookup succeeds, it will return RLOC addresses 1009 (e.g., in DNS A records) that correspond to neighbors to which the 1010 VET node can forward packets. 1012 Name-service lookups in enterprise networks with a centralized 1013 management structure use an infrastructure-based service, e.g., an 1014 enterprise-local DNS. Name-service lookups in enterprise networks 1015 with a distributed management structure and/or that lack an 1016 infrastructure-based name service instead use a distributed name 1017 service such as LLMNR over the VET interface. When a distributed 1018 name service is used, the VBR that performs the lookup sends a 1019 multicast query and accepts the union of all replies it receives from 1020 neighbors on the VET interface. When a VET node receives the query, 1021 it responds IFF it aggregates an IP prefix that covers the prefix in 1022 the query. 1024 5.5. VET Interface Encapsulation/Decapsulation 1026 VET interfaces encapsulate inner network layer packets in any 1027 necessary mid-layer headers and trailers (e.g., IPsec, SEAL, etc.) 1028 followed by an outer transport-layer header such as UDP (if 1029 necessary) followed by an outer IP header. Following all 1030 encapsulations, the VET interface submits the encapsulated packet to 1031 the outer IP forwarding engine for transmission on an underlying 1032 interface. The following sections provide further details on 1033 encapsulation: 1035 5.5.1. Inner Network Layer Protocol 1037 The inner network layer protocol sees the VET interface as an 1038 ordinary network interface, and views the outer network layer 1039 protocol as an ordinary L2 transport. The inner- and outer network 1040 layer protocol types are mutually independent and can be used in any 1041 combination. Inner network layer protocol types include IPv6 1042 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 1043 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 1045 5.5.2. SEAL Encapsulation 1047 VET interfaces that use SEAL encapsulate the inner packet in a SEAL 1048 header/trailer as specified in [I-D.templin-intarea-seal]. SEAL 1049 encapsulation must be applied uniformly between all neighbors on the 1050 VET link. Note that when a VET node sends a SEAL-encapsulated packet 1051 to a neighbor that does not use SEAL encapsulation, it may receive an 1052 ICMP "port unreachable" or "protocol unreachable" message. 1054 VET interfaces use SEAL encapsulation on VET links that require path 1055 MTU mitigations due to encapsulation overhead and/or mechanisms for 1056 VET interface neighbor coordination and error message handling. When 1057 SEAL encapsulation is used, the VET interface sets the 'NEXTHDR' 1058 value in the SEAL header to the IP protocol number associated with 1059 the protocol number of the inner network layer. The VET interface 1060 sets the other fields in the SEAL header as specified in 1061 [I-D.templin-intarea-seal]. 1063 5.5.3. Outer Transport-Layer Header Encapsulation 1065 Following SEAL encapsulation, VET interfaces that use a transport 1066 layer encapsulation such as UDP add an outer transport layer header. 1067 Inclusion of an outer UDP header must be applied uniformly between 1068 all neighbors on the VET link. Note that when a VET node sends a 1069 UDP-encapsulated packet to a neighbor that does not recognize the UDP 1070 port number, it may receive an ICMP "port unreachable" message. 1072 VET interfaces use UDP encapsulation on VET links that may traverse 1073 NATs and/or traffic conditioning network gear (e.g., Equal Cost 1074 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc.) 1075 that only recognize well-known network layer protocols. When UDP 1076 encapsulation is used, the VET interface encapsulates the mid-layer 1077 packet in an outer UDP header then sets the UDP port numbers as 1078 specified for the outermost mid-layer protocol (e.g., IPsec 1079 [RFC3947][RFC3948], etc.). 1081 When SEAL encapsulation [I-D.templin-intarea-seal] is also used, the 1082 VET interface maintains per-neighbor local and remote UDP port 1083 numbers. For bidirectional neighbors, the VET interface sets the 1084 local UDP port number to the value reserved for SEAL and sets the 1085 remote UDP port number to the observed UDP source port number in 1086 packets that it receives from the neighbor. In cases in which one of 1087 the bidirectional neighbors is behind a NAT, this implies that the 1088 one behind the NAT initiates the neighbor relationship. If both 1089 neighbors have a way of knowing that there are no NATs in the path, 1090 then they may select and set port numbers as for unidirectional 1091 neighbors. 1093 For unidirectional neighbors, the VET interface sets both the local 1094 and remote UDP port numbers to the value reserved for SEAL, and 1095 additionally selects a small set of dynamic port number values for 1096 use as additional local UDP port numbers. The VET interface then 1097 selects one of this set of local port numbers for the UDP source port 1098 for each inner packet it sends, where the port number can be 1099 determined e.g., by a hash calculated over the inner network layer 1100 addresses and inner transport layer port numbers. The VET interface 1101 uses a hash function of its own choosing when selecting a dynamic 1102 port number value, but it should choose a function that provides 1103 uniform distribution between the set of values, and it should be 1104 consistent in the manner in which the hash is applied. 1106 Finally, for VET links configured over IPv4 enterprise networks, the 1107 TE sets the UDP checksum field to zero. For VET links configured 1108 over IPv6 enterprise networks, considerations for setting the UDP 1109 checksum are discussed in [I-D.ietf-6man-udpzero]. If SEAL 1110 encapsulation is used, the TE sets the UDP checksum field to zero 1111 regardless of the IP protocol version, since SEAL provides an 1112 integrity check vector that covers the leading 128 bytes of the 1113 packet beginning with the UDP header. 1115 5.5.4. Outer IP Header Encapsulation 1117 Following any mid-layer and/or UDP encapsulations, the VET interface 1118 adds an outer IP header. Outer IP header construction is the same as 1119 specified for ordinary IP encapsulation (e.g., [RFC1070][RFC2003], 1120 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1121 Service/Traffic Class" and "Congestion Experienced" values in the 1122 inner network layer header are copied into the corresponding fields 1123 in the outer IP header. The VET interface also sets the IP protocol 1124 number to the appropriate value for the first protocol layer within 1125 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1126 as the outer IP protocol, the VET interface sets the flow label value 1127 in the outer IPv6 header the same as described in 1128 [I-D.carpenter-flow-ecmp]. 1130 5.5.5. Decapsulation and Re-Encapsulation 1132 When a VET node receives an encapsulated packet, it retains the outer 1133 headers, processes the SEAL header (if present) as specified in 1134 [I-D.templin-intarea-seal], then performs next hop determination on 1135 the packet's inner destination address. If the inner packet will be 1136 forwarded out a different interface than it arrived on, the VET node 1137 copies the "Congestion Experienced" value in the outer IP header into 1138 the corresponding field in the inner network layer header. The VET 1139 node then forwards the packet to the next inner network layer hop, or 1140 delivers the packet locally if the inner packet is addressed to 1141 itself. 1143 If the inner packet will be forwarded out the same VET interface that 1144 it arrived on, however, the VET node copies the "TTL/Hop Limit", 1145 "Type of Service/Traffic Class" and "Congestion Experienced" values 1146 in the outer IP header of the received packet into the corresponding 1147 fields in the outer IP header of the packet to be forwarded (i.e., 1148 the values are transferred between outer headers and *not* copied 1149 from the inner network layer header). This is true even if the outer 1150 IP protocol version of the received packet is different than the 1151 outer IP protocol version of the packet to be forwarded, i.e., the 1152 same as for bridging dissimilar L2 media segments. This re- 1153 encapsulation procedure is necessary to support diagnostic functions 1154 (e.g., 'traceroute'), and to ensure that the TTL/Hop Limit eventually 1155 decrements to 0 in case of transient routing loops. 1157 5.6. Neighbor Coordination on VET Interfaces that use SEAL 1159 VET interfaces that use SEAL use the SEAL Control Message Protocol 1160 (SCMP) as specified in Section 4.6 of [I-D.templin-intarea-seal] to 1161 coordinate reachability, routing information, and mappings between 1162 the inner and outer network layer protocols. SCMP parallels the IPv6 1163 Neighbor Discovery (ND) [RFC4861] and ICMPv6 [RFC4443] protocols, but 1164 operates from within the tunnel and supports operation for any 1165 combinations of inner and outer network layer protocols. 1167 When a VET interface that uses SEAL prepares a neighbor coordination 1168 SCMP message, the message is formatted the same as described for the 1169 corresponding IPv6 ND message, except that the message is preceded by 1170 a SEAL header the same as for SCMP error messages. The interface 1171 sets the SEAL header flags to (C=1; A=0; P=1; R=0; T=0; Z=0). The 1172 interface then sets the NEXTHDR field to 0 the same as for SEAL error 1173 messages, sets the LINK_ID and PKT_ID values to values appropriate 1174 for the neighbor, sets LEVEL to an appropriate maximum nesting level 1175 value, and sets PREFLEN to the length of the prefix that appears in 1176 the PREFIX field. 1178 The VET interface next writes an inner network layer prefix into the 1179 PREFIX field. The PREFIX is used to identify the source VET node 1180 when the target VET node cannot unambiguously identify the source by 1181 its outer network layer addresses (e.g., when the source VET node is 1182 behind a NAT, when the source is mobile, etc.). 1184 The VET interface next fills out the SCMP message header fields the 1185 same as for SCMP error messages, calculates the SCMP message 1186 Checksum, encapsulates the message in the requisite outer headers, 1187 then calculates the SEAL header Integrity Check Vector (ICV) value 1188 and places the result in the ICV1 field. The VET interface finally 1189 sends the message to the neighbor, which will verify the ICV and 1190 Checksum before accepting the message. 1192 VET and SEAL are specifically designed for encapsulation of inner 1193 network layer payloads over outer IPv4 and IPv6 networks as a link 1194 layer. VET interfaces that use SCMP therefore require a new Source/ 1195 Target Link-Layer Address Option (S/TLLAO) format that encapsulates 1196 IPv4 addresses as shown in Figure 2 and IPv6 addresses as shown in 1197 Figure 3: 1199 0 1 2 3 1200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Type = 2 | Length = 1 | Reserved | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | IPv4 address (bytes 0 thru 3) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Figure 2: SCMP S/TLLAO Option for IPv4 RLOCs 1209 0 1 2 3 1210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Type = 2 | Length = 3 | Reserved | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Reserved | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | IPv6 address (bytes 0 thru 3) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | IPv6 address (bytes 4 thru 7) | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | IPv6 address (bytes 8 thru 11) | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | IPv6 address (bytes 12 thru 15) | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Figure 3: SCMP S/TLLAO Option for IPv6 RLOCs 1227 The following subsections discuss VET interface neighbor coordination 1228 using SCMP: 1230 5.6.1. Router Discovery 1232 VET hosts and VBRs can send SCMP Router Solicitation (SRS) messages 1233 to one or more VBGs in the PRL to receive solicited SCMP Router 1234 Advertisements (SRAs). 1236 When a VBG receives an SRS message on a VET interface, it prepares a 1237 solicited SRA message. The SRA includes Router Lifetimes, Default 1238 Router Preferences, PIOs and any other options/parameters that the 1239 VBG is configured to include. 1241 The VBG finally includes one or more SLLAOs formatted as specified 1242 above that encode the IPv6 and/or IPv4 RLOC unicast addresses of its 1243 own enterprise-interior interfaces or the enterprise-interior 1244 interfaces of other nearby VBGs. 1246 5.6.2. Neighbor Unreachability Detection 1248 VET nodes perform Neighbor Unreachability Detection (NUD) by 1249 monitoring hints of forward progress. The VET node can periodically 1250 set the 'A' bit in the header of SEAL data packets to elicit SCMP 1251 responses from the neighbor. The VET node can also send SCMP 1252 Neighbor Solicitation (SNS) messages to the neighbor to elicit SCMP 1253 Neighbor Advertisement (SNA) messages. 1255 Responsiveness to routing changes is directly related to the delay in 1256 detecting that a neighbor has gone unreachable. In order to provide 1257 responsiveness comparable to dynamic routing protocols, a reasonably 1258 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1260 Additionally, a VET node may receive outer IP ICMP "Destination 1261 Unreachable; net / host unreachable" messages from an ER on the path 1262 indicating that the path to a neighbor may be failing. The VET node 1263 SHOULD first check the packet-in-error to obtain reasonable assurance 1264 that the ICMP message is authentic. If the node receives excessive 1265 ICMP unreachable errors through multiple RLOCs associated with the 1266 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1267 packets to flow through a different route (e.g., a default route with 1268 a VBG as the next hop). 1270 5.6.3. Redirection 1272 The VET node connected to the source EUN (i.e., the source VET node) 1273 can set R=1 in the SEAL header of a data packet to be forwarded as a 1274 "predirect" indication that SCMP Redirect (SRD) messages will be 1275 accepted from the VET node connected to the destination EUN (i.e., 1276 the target VET node). Each VBG on the VET interface chain to the 1277 target preserves the state of the R bit when it re-encapsulates and 1278 forwards the packet. 1280 When the target VET node receives the predirect indication, it 1281 returns an SRD message similar to the manner described in AERO 1282 [I-D.templin-aero]. The SRD message is formatted the same as for an 1283 ICMPv6 Redirect message as shown in Section 4.5 of[RFC4861]. The 1284 target includes Target Link Layer Address Options (TLLAOs) formatted 1285 as specified above, then adds a Redirected Header Option (RHO) that 1286 includes the leading portion of the SEAL data packet that triggered 1287 the redirection event beginning immediately following the SEAL 1288 header. 1290 The target VET node then creates a 128-bit secret key value (T_Key) 1291 that it will use to validate the SEAL header ICV in future packets it 1292 will receive from the (redirected) source VET node. The target 1293 encrypts T_Key with the secret key it uses to validate the ICV in 1294 SEAL packets received from the previous VET interface hop (P_Key(N)). 1295 It then writes the encrypted value in the "Target" field of the SRD 1296 message, i.e., instead of an IPv6 address. 1298 The target VET node then encapsulates the SRD message in a SEAL 1299 header as specified above, except that it sets P=0 and does not 1300 include a PREFIX field. The target also writes the prefix length 1301 associated with the inner destination address of the SEAL data packet 1302 that triggered the redirection event in the PREFLEN field of the SEAL 1303 header. For example, if the destination address is 2001:db8::1 and 1304 the destination prefix is 2001:db8::/48, the target sets the PREFLEN 1305 field to the value 48. The target then calculates the SEAL ICVs and 1306 returns the message to the previous hop VBG on the chain toward the 1307 source. 1309 When the target returns the SRD message, each intermediate VBG in the 1310 chain toward the source relays the message by examining the source 1311 address of the inner packet within the RHO to determine the previous 1312 hop toward the source. Each intermediate VBG in the chain verifies 1313 the SRD message SEAL ICV and Checksum, and decrypts the T_Key value 1314 in the SRD message "Target" field using its own secret key 1315 (P_Key(i)). The VBG then re-encrypts T_Key using the key 1316 corresponding to the next hop toward the source (P_Key(i-1)), then 1317 re-calculates the SEAL ICV and sends the SRD message to the previous 1318 hop. This relaying process is the same as for SCMP error message 1319 relaying specified in Section 4.6 of [I-D.templin-intarea-seal]. 1321 When the source VET node receives the SRD message, it discovers both 1322 the PREFLEN and candidate link layer addresses for this new 1323 (unidirectional) target VET node. The source node also caches the 1324 T_Key value, and uses it to calculate the ICVs it will include in the 1325 SEAL header/trailer of subsequent packets it sends to the target. 1327 The source then applies the PREFLEN to the inner destination address 1328 of the packet that triggered the redirection event, then installs the 1329 resulting prefix in a forwarding table entry with the target as the 1330 next hop. 1332 The source can subsequently send packets destined to an address 1333 covered by the destination prefix using SEAL encapsulation via the 1334 target as the next hop. The target can then use the ICVs in the SEAL 1335 data packets for inner source address validation 1336 [I-D.ietf-savi-framework], but it need not also check the outer 1337 source addresses/port numbers of the packets. Therefore, the outer 1338 addresses may change over time even if the inner source address stays 1339 the same. 1341 Following redirection, if the source is subsequently unable to reach 1342 the target via the route-optimized path, it deletes the destination 1343 prefix forwarding table entry and installs a new forwarding table 1344 entry for the destination prefix with a default router as the next 1345 hop. The source VET node thereafter sets R=0 in the SEAL headers of 1346 data packets that it sends toward the destination prefix, but it may 1347 attempt redirection again at a later time by again setting R=1. 1349 Finally, the source and target VET nodes should set an expiration 1350 timer on the destination forwarding table entry so that stale entries 1351 are deleted in a timely fashion. 1353 5.6.4. Bidirectional Neighbor Synchronization 1355 The tunnel neighbor relationship between a pair of VET interface 1356 tunnel neighbors can be either unidirectional or bidirectional. A 1357 unidirectional relationship (see: Section 5.6.3) can be established 1358 when the source VET node 'A' will tunnel data packets directly to a 1359 target VET node 'B', but 'B' will not tunnel data packets directly to 1360 'A'. A bidirectional relationship is necessary when a Client VET 1361 node establishes a connection to a Serving VBG . 1363 In order to establish a bidirectional tunnel neighbor relationship, 1364 the Client (call it "A") performs a reliable exchange (e.g., a short 1365 TCP transaction, a DHCP client/server exchange, etc.) with the Server 1366 (call it "B"). The application layer details of the transaction are 1367 out of scope for this document, and indeed need not be standardized 1368 as long as both the Client and Server observe the same 1369 specifications. Note that a short transaction instead of a 1370 persistent connection is advised if the outer network layer protocol 1371 addresses may change, e.g., due to a mobility event, due to loss of 1372 state in network middleboxes, etc. If there is assurance that the 1373 outer network layer protocol addresses will not change, then a 1374 persistent connection may be used. 1376 During the transaction, "A" and "B" first authenticate themselves to 1377 each other, then exchange information regarding the inner network 1378 layer prefixes that will be used for conveying inner packets that 1379 will be forwarded over the tunnel. In this process, the Client 1380 registers one or more link identifiers (LINK_IDs) with the Server to 1381 provide "handles" for the Client's outer IP connection addresses. 1382 This implies that, while the Client may be either behind a NAT or 1383 mobile (or both), the Server must be stable and publicly addressable. 1385 Following this bidirectional tunnel neighbor establishment, the 1386 neighbors monitor the soft state for liveness, e.g., using Neighbor 1387 Unreachability Detection hints of forward progress. When one of the 1388 neighbors wishes to terminate the relationship, it performs another 1389 short transaction to request the termination, then both neighbors 1390 delete their respective tunnel soft state. 1392 5.7. Neighbor Coordination on VET Interfaces using IPsec 1394 VET interfaces that use IPsec encapsulation [RFC4301] use the 1395 Internet Key Exchange protocol, version 2 (IKEv2) [RFC4306] to manage 1396 security association setup and maintenance. IKEv2 provides a logical 1397 equivalent of the SCMP in terms of VET interface neighbor 1398 coordinations; for example, IKEv2 also provides mechanisms for 1399 redirection [RFC5685] and mobility [RFC4555]. 1401 IPsec additionally provides an extended Identification field and ICV; 1402 these features allow IPsec to utilize outer IP fragmentation and 1403 reassembly with less risk of exposure to data corruption due to 1404 reassembly misassociations. 1406 5.8. Mobility and Multihoming Considerations 1408 VBRs that travel between distinct enterprise networks must either 1409 abandon their PA prefixes that are relative to the "old" network and 1410 obtain PA prefixes relative to the "new" network, or somehow 1411 coordinate with a "home" network to retain ownership of the prefixes. 1412 In the first instance, the VBR would be required to coordinate a 1413 network renumbering event on its attached networks using the new PA 1414 prefixes [RFC4192][RFC5887]. In the second instance, an adjunct 1415 mobility management mechanism is required. 1417 VBRs can retain their CPs as they travel between distinct network 1418 points of attachment as long as they continue to refresh their CP-to- 1419 RLOC address mappings with their serving VBG as described in 1420 [I-D.templin-ironbis]. (When the VBR moves far from its serving VBG, 1421 it can also select a new VBG in order to maintain optimal routing.) 1422 In this way, VBRs can update their CP-to-RLOC mappings in real time 1423 and without requiring an adjunct mobility management mechanism. 1425 VBRs that have true PI prefixes can withdraw the prefixes from former 1426 Internet points of attachment and re-advertise them at new points of 1427 attachment as they move. However, this method has been shown to 1428 produce excessive routing churn in the global internet BGP tables, 1429 and should be avoided for any mobility scenarios that may occur along 1430 short timescales. The alternative is to employ a system in which the 1431 true PI prefixes are not injected into the Internet routing system, 1432 but rather managed through some separate global mapping database. 1433 This latter method is employed by the LISP proposal [I-D.ietf-lisp]. 1435 The VBGs of a multihomed enterprise network participate in a private 1436 inner network layer routing protocol instance (e.g., via an interior 1437 BGP instance) to accommodate network partitions/merges as well as 1438 intra-enterprise mobility events. 1440 5.9. Multicast 1442 5.9.1. Multicast over (Non)Multicast Enterprise Networks 1444 Whether or not the underlying enterprise network supports a native 1445 multicasting service, the VET node can act as an inner network layer 1446 IGMP/MLD proxy [RFC4605] on behalf of its attached EUNs and convey 1447 its multicast group memberships over the VET interface to a VBG 1448 acting as a multicast router. Its inner network layer multicast 1449 transmissions will therefore be encapsulated in outer headers with 1450 the unicast address of the VBG as the destination. 1452 5.9.2. Multicast Over Multicast-Capable Enterprise Networks 1454 In multicast-capable enterprise networks, ERs provide an enterprise- 1455 wide multicasting service (e.g., Simplified Multicast Forwarding 1456 (SMF) [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) 1457 routing, Distance Vector Multicast Routing Protocol (DVMRP) routing, 1458 etc.) over their enterprise-interior interfaces such that outer IP 1459 multicast messages of site-scope or greater scope will be propagated 1460 across the enterprise network. For such deployments, VET nodes can 1461 optionally provide a native inner multicast/broadcast capability over 1462 their VET interfaces through mapping of the inner multicast address 1463 space to the outer multicast address space. In that case, operation 1464 of link-or greater-scoped inner multicasting services (e.g., a link- 1465 scoped neighbor discovery protocol) over the VET interface is 1466 available, but SHOULD be used sparingly to minimize enterprise-wide 1467 flooding. 1469 VET nodes encapsulate inner multicast messages sent over the VET 1470 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1471 followed by an outer IP header with a site-scoped outer IP multicast 1472 address as the destination. For the case of IPv6 and IPv4 as the 1473 inner/outer protocols (respectively), [RFC2529] provides mappings 1474 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1475 address space (for other encapsulations, mappings are established 1476 through administrative configuration or through an unspecified 1477 alternate static mapping). 1479 Multicast mapping for inner multicast groups over outer IP multicast 1480 groups can be accommodated, e.g., through VET interface snooping of 1481 inner multicast group membership and routing protocol control 1482 messages. To support inner-to-outer multicast address mapping, the 1483 VET interface acts as a virtual outer IP multicast host connected to 1484 its underlying interfaces. When the VET interface detects that an 1485 inner multicast group joins or leaves, it forwards corresponding 1486 outer IP multicast group membership reports on an underlying 1487 interface over which the VET interface is configured. If the VET 1488 node is configured as an outer IP multicast router on the underlying 1489 interfaces, the VET interface forwards locally looped-back group 1490 membership reports to the outer IP multicast routing process. If the 1491 VET node is configured as a simple outer IP multicast host, the VET 1492 interface instead forwards actual group membership reports (e.g., 1493 IGMP messages) directly over an underlying interface. 1495 Since inner multicast groups are mapped to site-scoped outer IP 1496 multicast groups, the VET node MUST ensure that the site-scoped outer 1497 IP multicast messages received on the underlying interfaces for one 1498 VET interface do not "leak out" to the underlying interfaces of 1499 another VET interface. This is accommodated through normal site- 1500 scoped outer IP multicast group filtering at enterprise network 1501 boundaries. 1503 5.10. Service Discovery 1505 VET nodes can perform enterprise-wide service discovery using a 1506 suitable name-to-address resolution service. Examples of flooding- 1507 based services include the use of LLMNR [RFC4795] over the VET 1508 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1509 over an underlying interface. More scalable and efficient service 1510 discovery mechanisms (e.g., anycast) are for further study. 1512 5.11. VET Link Partitioning 1514 A VET link can be partitioned into multiple distinct logical 1515 groupings. In that case, each partition configures its own distinct 1516 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1517 'isatapv2.zone2.example.com', etc.). 1519 VBGs can further create multiple IP subnets within a partition, e.g., 1520 by sending SRAs with PIOs containing different IP prefixes to 1521 different groups of VET hosts. VBGs can identify subnets, e.g., by 1522 examining RLOC prefixes, observing the enterprise-interior interfaces 1523 over which SRSs are received, etc. 1525 In the limiting case, VBGs can advertise a unique set of IP prefixes 1526 to each VET host such that each host belongs to a different subnet 1527 (or set of subnets) on the VET interface. 1529 5.12. VBG Prefix State Recovery 1531 VBGs retain explicit state that tracks the inner network layer 1532 prefixes delegated to VBRs connected to the VET link, e.g., so that 1533 packets are delivered to the correct VBRs. When a VBG loses some or 1534 all of its state (e.g., due to a power failure), client VBRs must 1535 refresh the VBG's state so that packets can be forwarded over correct 1536 routes. 1538 5.13. Legacy ISATAP Services 1540 VBGs can support legacy ISATAP services according to the 1541 specifications in [RFC5214]. In particular, VBGs can configure 1542 legacy ISATAP interfaces and VET interfaces over the same sets of 1543 underlying interfaces as long as the PRLs and IPv6 prefixes 1544 associated with the ISATAP/VET interfaces are distinct. 1546 Legacy ISATAP hosts acquire addresses and/or prefixes in the same 1547 manner and using the same mechanisms as described for VET hosts in 1548 Section 4.4 above. 1550 6. IANA Considerations 1552 There are no IANA considerations for this document. 1554 7. Security Considerations 1556 Security considerations for MANETs are found in [RFC2501]. 1558 The security considerations found in [RFC2529][RFC5214][RFC6324] also 1559 apply to VET. 1561 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1562 where attacks on the neighbor coordination protocol are possible. 1563 SEAL [I-D.templin-intarea-seal] supports path MTU discovery, and 1564 provides per-packet authenticating information for data origin 1565 authentication, anti-replay and message header integrity. 1567 Rogue neighbor coordination messages with spoofed RLOC source 1568 addresses can consume network resources and cause VET nodes to 1569 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1570 such RLOCs, as that may result in a denial of service to the RLOCs' 1571 legitimate owners. 1573 VBRs and VBGs observe the recommendations for network ingress 1574 filtering [RFC2827]. 1576 8. Related Work 1578 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1579 automatic tunneling in [RFC2529]; this concept was later called: 1580 "Virtual Ethernet" and investigated by Quang Nguyen under the 1581 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1582 their colleagues have motivated a number of foundational concepts on 1583 which this work is based. 1585 Telcordia has proposed DHCP-related solutions for MANETs through the 1586 CECOM MOSAIC program. 1588 The Naval Research Lab (NRL) Information Technology Division uses 1589 DHCP in their MANET research testbeds. 1591 Security concerns pertaining to tunneling mechanisms are discussed in 1592 [I-D.ietf-v6ops-tunnel-security-concerns]. 1594 Default router and prefix information options for DHCPv6 are 1595 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1597 An automated IPv4 prefix delegation mechanism is proposed in 1598 [I-D.ietf-dhc-subnet-alloc]. 1600 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1601 [I-D.clausen-manet-autoconf-recommendations]. 1603 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1605 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1606 decapsulation issues and other aspects of tunneling. 1608 Various proposals within the IETF have suggested similar mechanisms. 1610 9. Acknowledgements 1612 The following individuals gave direct and/or indirect input that was 1613 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1614 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1615 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1616 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1617 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1618 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1619 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1620 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1621 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1622 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1623 working groups. Many others have provided guidance over the course 1624 of many years. 1626 Discussions with colleagues following the publication of RFC5558 have 1627 provided useful insights that have resulted in significant 1628 improvements to this, the Second Edition of VET. 1630 10. Contributors 1632 The following individuals have contributed to this document: 1634 Eric Fleischman (eric.fleischman@boeing.com) 1635 Thomas Henderson (thomas.r.henderson@boeing.com) 1636 Steven Russert (steven.w.russert@boeing.com) 1637 Seung Yi (seung.yi@boeing.com) 1639 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1640 of the document. 1642 Jim Bound's foundational work on enterprise networks provided 1643 significant guidance for this effort. We mourn his loss and honor 1644 his contributions. 1646 11. References 1647 11.1. Normative References 1649 [I-D.templin-intarea-seal] 1650 Templin, F., "The Subnetwork Encapsulation and Adaptation 1651 Layer (SEAL)", draft-templin-intarea-seal-38 (work in 1652 progress), November 2011. 1654 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1655 September 1981. 1657 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1658 RFC 792, September 1981. 1660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1661 Requirement Levels", BCP 14, RFC 2119, March 1997. 1663 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1664 RFC 2131, March 1997. 1666 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1667 (IPv6) Specification", RFC 2460, December 1998. 1669 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1670 Defeating Denial of Service Attacks which employ IP Source 1671 Address Spoofing", BCP 38, RFC 2827, May 2000. 1673 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1674 Messages", RFC 3118, June 2001. 1676 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1677 and M. Carney, "Dynamic Host Configuration Protocol for 1678 IPv6 (DHCPv6)", RFC 3315, July 2003. 1680 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1681 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1682 December 2003. 1684 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1685 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1687 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1688 RFC 3972, March 2005. 1690 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1691 Architecture", RFC 4291, February 2006. 1693 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1694 Message Protocol (ICMPv6) for the Internet Protocol 1695 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1697 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1698 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1699 September 2007. 1701 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1702 Address Autoconfiguration", RFC 4862, September 2007. 1704 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1705 for IEEE 802 Parameters", BCP 141, RFC 5342, 1706 September 2008. 1708 11.2. Informative References 1710 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1711 Switching Networks", May 1974. 1713 [I-D.carpenter-flow-ecmp] 1714 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1715 for equal cost multipath routing and link aggregation in 1716 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 1717 October 2010. 1719 [I-D.cheshire-dnsext-multicastdns] 1720 Cheshire, S. and M. Krochmal, "Multicast DNS", 1721 draft-cheshire-dnsext-multicastdns-14 (work in progress), 1722 February 2011. 1724 [I-D.clausen-manet-autoconf-recommendations] 1725 Clausen, T. and U. Herberg, "MANET Router Configuration 1726 Recommendations", 1727 draft-clausen-manet-autoconf-recommendations-00 (work in 1728 progress), February 2009. 1730 [I-D.clausen-manet-linktype] 1731 Clausen, T., "The MANET Link Type", 1732 draft-clausen-manet-linktype-00 (work in progress), 1733 October 2008. 1735 [I-D.droms-dhc-dhcpv6-default-router] 1736 Droms, R. and T. Narten, "Default Router and Prefix 1737 Advertisement Options for DHCPv6", 1738 draft-droms-dhc-dhcpv6-default-router-00 (work in 1739 progress), March 2009. 1741 [I-D.ietf-6man-udpzero] 1742 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 1743 Considerations", draft-ietf-6man-udpzero-04 (work in 1744 progress), October 2011. 1746 [I-D.ietf-dhc-subnet-alloc] 1747 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1748 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-12 1749 (work in progress), June 2011. 1751 [I-D.ietf-grow-va] 1752 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1753 L. Zhang, "FIB Suppression with Virtual Aggregation", 1754 draft-ietf-grow-va-05 (work in progress), June 2011. 1756 [I-D.ietf-lisp] 1757 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1758 "Locator/ID Separation Protocol (LISP)", 1759 draft-ietf-lisp-16 (work in progress), November 2011. 1761 [I-D.ietf-manet-smf] 1762 Macker, J., "Simplified Multicast Forwarding", 1763 draft-ietf-manet-smf-12 (work in progress), July 2011. 1765 [I-D.ietf-savi-framework] 1766 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1767 "Source Address Validation Improvement Framework", 1768 draft-ietf-savi-framework-05 (work in progress), 1769 July 2011. 1771 [I-D.ietf-v6ops-tunnel-security-concerns] 1772 Krishnan, S., Thaler, D., and J. Hoagland, "Security 1773 Concerns With IP Tunneling", 1774 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 1775 progress), October 2010. 1777 [I-D.jen-apt] 1778 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1779 L. Zhang, "APT: A Practical Transit Mapping Service", 1780 draft-jen-apt-01 (work in progress), November 2007. 1782 [I-D.templin-aero] 1783 Templin, F., "Asymmetric Extended Route Optimization 1784 (AERO)", draft-templin-aero-04 (work in progress), 1785 October 2011. 1787 [I-D.templin-ironbis] 1788 Templin, F., "The Internet Routing Overlay Network 1789 (IRON)", draft-templin-ironbis-08 (work in progress), 1790 November 2011. 1792 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1793 July 1978. 1795 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1796 Protocol Specification", October 2008. 1798 [RFC0994] International Organization for Standardization (ISO) and 1799 American National Standards Institute (ANSI), "Final text 1800 of DIS 8473, Protocol for Providing the Connectionless- 1801 mode Network Service", RFC 994, March 1986. 1803 [RFC1035] Mockapetris, P., "Domain names - implementation and 1804 specification", STD 13, RFC 1035, November 1987. 1806 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1807 a subnetwork for experimentation with the OSI network 1808 layer", RFC 1070, February 1989. 1810 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1811 Communication Layers", STD 3, RFC 1122, October 1989. 1813 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1814 Routing and Addressing Architecture", RFC 1753, 1815 December 1994. 1817 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1818 E. Lear, "Address Allocation for Private Internets", 1819 BCP 5, RFC 1918, February 1996. 1821 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1822 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1824 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1825 October 1996. 1827 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1828 Extensions", RFC 2132, March 1997. 1830 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1831 IPv6 Specification", RFC 2473, December 1998. 1833 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1834 over Non-Broadcast Multiple Access (NBMA) networks", 1835 RFC 2491, January 1999. 1837 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1838 (MANET): Routing Protocol Performance Issues and 1839 Evaluation Considerations", RFC 2501, January 1999. 1841 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1842 Domains without Explicit Tunnels", RFC 2529, March 1999. 1844 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1845 February 2000. 1847 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1848 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1849 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1850 RFC 3819, July 2004. 1852 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1853 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1854 May 2005. 1856 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1857 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1858 January 2005. 1860 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1861 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1862 RFC 3948, January 2005. 1864 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1865 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1866 September 2005. 1868 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1869 Addresses", RFC 4193, October 2005. 1871 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1872 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1874 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1875 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1877 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1878 Internet Protocol", RFC 4301, December 2005. 1880 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1881 RFC 4306, December 2005. 1883 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1884 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1885 May 2006. 1887 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1888 (MOBIKE)", RFC 4555, June 2006. 1890 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1891 System", RFC 4592, July 2006. 1893 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1894 "Internet Group Management Protocol (IGMP) / Multicast 1895 Listener Discovery (MLD)-Based Multicast Forwarding 1896 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1898 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1899 Multicast Name Resolution (LLMNR)", RFC 4795, 1900 January 2007. 1902 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1903 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1904 Focus", RFC 4852, April 2007. 1906 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1907 June 2007. 1909 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1910 Extensions for Stateless Address Autoconfiguration in 1911 IPv6", RFC 4941, September 2007. 1913 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1914 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1915 March 2008. 1917 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1918 for IPv6", RFC 5340, July 2008. 1920 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1921 Infrastructures (6rd)", RFC 5569, January 2010. 1923 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1924 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1925 RFC 5685, November 2009. 1927 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1928 Global Enterprise Recursion (RANGER)", RFC 5720, 1929 February 2010. 1931 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1932 Still Needs Work", RFC 5887, May 2010. 1934 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1935 Infrastructures (6rd) -- Protocol Specification", 1936 RFC 5969, August 2010. 1938 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 1939 Addressing in Networks with Global Enterprise Recursion 1940 (RANGER) Scenarios", RFC 6139, February 2011. 1942 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1943 IPv6 Automatic Tunnels: Problem Statement and Proposed 1944 Mitigations", RFC 6324, August 2011. 1946 Appendix A. Duplicate Address Detection (DAD) Considerations 1948 A priori uniqueness determination (also known as "pre-service DAD") 1949 for an RLOC assigned on an enterprise-interior interface would 1950 require either flooding the entire enterprise network or somehow 1951 discovering a link in the network on which a node that configures a 1952 duplicate address is attached and performing a localized DAD exchange 1953 on that link. But, the control message overhead for such an 1954 enterprise-wide DAD would be substantial and prone to false-negatives 1955 due to packet loss and intermittent connectivity. An alternative to 1956 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1957 enterprise-interior interfaces and employ a passive in-service DAD 1958 (e.g., one that monitors routing protocol messages for duplicate 1959 assignments). 1961 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1962 CGAs, IPv6 privacy addresses, etc. with very small probability of 1963 collision. Pseudo-random IPv4 RLOCs can be generated through random 1964 assignment from a suitably large IPv4 prefix space. 1966 Consistent operational practices can assure uniqueness for VBG- 1967 aggregated addresses/prefixes, while statistical properties for 1968 pseudo-random address self-generation can assure uniqueness for the 1969 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1970 RLOC delegation authority should be used when available, while a 1971 passive in-service DAD mechanism should be used to detect RLOC 1972 duplications when there is no RLOC delegation authority. 1974 Appendix B. Anycast Services 1976 Some of the IPv4 addresses that appear in the Potential Router List 1977 may be anycast addresses, i.e., they may be configured on the VET 1978 interfaces of multiple VBRs/VBGs. In that case, each VET router 1979 interface that configures the same anycast address must exhibit 1980 equivalent outward behavior. 1982 Use of an anycast address as the IP destination address of tunneled 1983 packets can have subtle interactions with tunnel path MTU and 1984 neighbor discovery. For example, if the initial fragments of a 1985 fragmented tunneled packet with an anycast IP destination address are 1986 routed to different egress tunnel endpoints than the remaining 1987 fragments, the multiple endpoints will be left with incomplete 1988 reassembly buffers. This issue can be mitigated by ensuring that 1989 each egress tunnel endpoint implements a proactive reassembly buffer 1990 garbage collection strategy. Additionally, ingress tunnel endpoints 1991 that send packets with an anycast IP destination address must use the 1992 minimum path MTU for all egress tunnel endpoints that configure the 1993 same anycast address as the tunnel MTU. Finally, ingress tunnel 1994 endpoints should treat ICMP unreachable messages from a router within 1995 the tunnel as at most a weak indication of neighbor unreachability, 1996 since the failures may only be transient and a different path to an 1997 alternate anycast router quickly selected through reconvergence of 1998 the underlying routing protocol. 2000 Use of an anycast address as the IP source address of tunneled 2001 packets can lead to more serious issues. For example, when the IP 2002 source address of a tunneled packet is anycast, ICMP messages 2003 produced by routers within the tunnel might be delivered to different 2004 ingress tunnel endpoints than the ones that produced the packets. In 2005 that case, functions such as path MTU discovery and neighbor 2006 unreachability detection may experience non-deterministic behavior 2007 that can lead to communications failures. Additionally, the 2008 fragments of multiple tunneled packets produced by multiple ingress 2009 tunnel endpoints may be delivered to the same reassembly buffer at a 2010 single egress tunnel endpoint. In that case, data corruption may 2011 result due to fragment misassociation during reassembly. 2013 In view of these considerations, VBGs that configure an anycast 2014 address should also configure one or more unicast addresses from the 2015 Potential Router List; they should further accept tunneled packets 2016 destined to any of their anycast or unicast addresses, but should 2017 send tunneled packets using a unicast address as the source address. 2019 Appendix C. Change Log 2021 (Note to RFC editor - this section to be removed before publication 2022 as an RFC.) 2024 Changes from -14 to -15: 2026 o new insights into default route configuration and next-hop 2027 determination 2029 Changes from -13 to -14: 2031 o fixed Idnits 2033 Changes from -12 to -13: 2035 o Changed "VGL" *back* to "PRL" 2037 o More changes for multi-protocol support 2039 o Changes to Redirect function 2041 Changes from -11 to -12: 2043 o Major section rearrangement 2045 o Changed "PRL" to "VGL" 2047 o Brought back text that was lost in the -10 to -11 transition 2049 Changes from -10 to -11: 2051 o Major changes with significant simplifications 2053 o Now support stateless PD using 6rd mechanisms 2055 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2057 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2059 Changes from -09 to -10: 2061 o Changed "enterprise" to "enterprise network" throughout 2063 o dropped "inner IP", since inner layer may be non-IP 2065 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2066 messages remain *within* the tunnel interface instead of being 2067 exposed to the inner network layer protocol engine. 2069 Changes from -08 to -09: 2071 o Expanded discussion of encapsulation/decapsulation procedures 2073 o cited IRON 2075 Changes from -07 to -08: 2077 o Specified the approach to global mapping using virtual aggregation 2078 and BGP 2080 Changes from -06 to -07: 2082 o reworked redirect function 2084 o created new section on VET interface encapsulation 2086 o clarifications on nexthop selection 2088 o fixed several bugs 2090 Changed from -05 to -06: 2092 o reworked VET interface ND 2094 o anycast clarifications 2096 Changes from -03 to -04: 2098 o security consideration clarifications 2100 Changes from -02 to -03: 2102 o security consideration clarifications 2104 o new PRLNAME for VET is "isatav2.example.com" 2106 o VET now uses SEAL natively 2108 o EBGs can support both legacy ISATAP and VET over the same 2109 underlying interfaces. 2111 Changes from -01 to -02: 2113 o Defined CGA and privacy address configuration on VET interfaces 2115 o Interface identifiers added to routing protocol control messages 2116 for link-layer multiplexing 2118 Changes from -00 to -01: 2120 o Section 4.1 clarifications on link-local assignment and RLOC 2121 autoconfiguration. 2123 o Appendix B clarifications on Weak End System Model 2124 Changes from RFC5558 to -00: 2126 o New appendix on RLOC configuration on VET interfaces. 2128 Author's Address 2130 Fred L. Templin (editor) 2131 Boeing Research & Technology 2132 P.O. Box 3707 MC 7L-49 2133 Seattle, WA 98124 2134 USA 2136 Email: fltemplin@acm.org