idnits 2.17.1 draft-templin-intarea-vet-29.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 14, 2011) is 4539 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 1742, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-36 ** 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-07 -- 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 14, 2011 5 Expires: May 17, 2012 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-29.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 17, 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 . . . . . . . . . . 25 83 5.6. Neighbor Coordination on VET Interfaces that use SEAL . . 26 84 5.6.1. Router Discovery . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . . . . . 35 102 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . . . . . . . . . . . 46 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]. 1111 5.5.4. Outer IP Header Encapsulation 1113 Following any mid-layer and/or UDP encapsulations, the VET interface 1114 adds an outer IP header. Outer IP header construction is the same as 1115 specified for ordinary IP encapsulation (e.g., [RFC1070][RFC2003], 1116 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1117 Service/Traffic Class" and "Congestion Experienced" values in the 1118 inner network layer header are copied into the corresponding fields 1119 in the outer IP header. The VET interface also sets the IP protocol 1120 number to the appropriate value for the first protocol layer within 1121 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1122 as the outer IP protocol, the VET interface sets the flow label value 1123 in the outer IPv6 header the same as described in 1124 [I-D.carpenter-flow-ecmp]. 1126 5.5.5. Decapsulation and Re-Encapsulation 1128 When a VET node receives an encapsulated packet, it retains the outer 1129 headers, processes the SEAL header (if present) as specified in 1130 [I-D.templin-intarea-seal], then performs next hop determination on 1131 the packet's inner destination address. If the inner packet will be 1132 forwarded out a different interface than it arrived on, the VET node 1133 copies the "Congestion Experienced" value in the outer IP header into 1134 the corresponding field in the inner network layer header. The VET 1135 node then forwards the packet to the next inner network layer hop, or 1136 delivers the packet locally if the inner packet is addressed to 1137 itself. 1139 If the inner packet will be forwarded out the same VET interface that 1140 it arrived on, however, the VET node copies the "TTL/Hop Limit", 1141 "Type of Service/Traffic Class" and "Congestion Experienced" values 1142 in the outer IP header of the received packet into the corresponding 1143 fields in the outer IP header of the packet to be forwarded (i.e., 1144 the values are transferred between outer headers and *not* copied 1145 from the inner network layer header). This is true even if the outer 1146 IP protocol version of the received packet is different than the 1147 outer IP protocol version of the packet to be forwarded, i.e., the 1148 same as for bridging dissimilar L2 media segments. This re- 1149 encapsulation procedure is necessary to support diagnostic functions 1150 (e.g., 'traceroute'), and to ensure that the TTL/Hop Limit eventually 1151 decrements to 0 in case of transient routing loops. 1153 5.6. Neighbor Coordination on VET Interfaces that use SEAL 1155 VET interfaces that use SEAL use the SEAL Control Message Protocol 1156 (SCMP) as specified in Section 4.6 of [I-D.templin-intarea-seal] to 1157 coordinate reachability, routing information, and mappings between 1158 the inner and outer network layer protocols. SCMP parallels the IPv6 1159 Neighbor Discovery (ND) [RFC4861] and ICMPv6 [RFC4443] protocols, but 1160 operates from within the tunnel and supports operation for any 1161 combinations of inner and outer network layer protocols. 1163 When a VET interface that uses SEAL prepares a neighbor coordination 1164 SCMP message, the message is formatted the same as described for the 1165 corresponding IPv6 ND message, except that the message is preceded by 1166 a SEAL header the same as for SCMP error messages. The interface 1167 sets the SEAL header flags to (C=1; P=1; R=0; U=0; Z=0), and sets T=1 1168 if the message requires an extended integrity check; otherwise it 1169 sets T=0. The interface then sets the NEXTHDR field to 0 the same as 1170 for SEAL error messages, sets the LINK_ID and PKT_ID values to values 1171 appropriate for the neighbor, sets LEVEL to an appropriate maximum 1172 nesting level value, and sets PREFLEN to the length of the prefix 1173 that appears in the PREFIX field. 1175 The VET interface finally write an inner network layer prefix into 1176 the PREFIX field, then calculates the SEAL header/trailer Integrity 1177 Check Vectors (ICVs). The PREFIX is used to identify the source VET 1178 node when the target VET node cannot unambiguously identify the 1179 source by its outer network layer addresses (e.g., when the source 1180 VET node is behind a NAT, when the source is mobile, etc.). 1182 VET and SEAL are specifically designed for encapsulation of inner 1183 network layer payloads over outer IPv4 and IPv6 networks as a link 1184 layer. VET interfaces that use SCMP therefore require a new Source/ 1185 Target Link-Layer Address Option (S/TLLAO) format that encapsulates 1186 IPv4 addresses as shown in Figure 2 and IPv6 addresses as shown in 1187 Figure 3: 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Type = 2 | Length = 1 | Reserved | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | IPv4 address (bytes 0 thru 3) | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Figure 2: SCMP S/TLLAO Option for IPv4 RLOCs 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 = 3 | Reserved | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Reserved | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | IPv6 address (bytes 0 thru 3) | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | IPv6 address (bytes 4 thru 7) | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | IPv6 address (bytes 8 thru 11) | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | IPv6 address (bytes 12 thru 15) | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Figure 3: SCMP S/TLLAO Option for IPv6 RLOCs 1217 The following subsections discuss VET interface neighbor coordination 1218 using SCMP: 1220 5.6.1. Router Discovery 1222 VET hosts and VBRs can send SCMP Router Solicitation (SRS) messages 1223 to one or more VBGs in the PRL to receive solicited SCMP Router 1224 Advertisements (SRAs). 1226 When a VBG receives an SRS message on a VET interface, it prepares a 1227 solicited SRA message. The SRA includes Router Lifetimes, Default 1228 Router Preferences, PIOs and any other options/parameters that the 1229 VBG is configured to include. 1231 The VBG finally includes one or more SLLAOs formatted as specified 1232 above that encode the IPv6 and/or IPv4 RLOC unicast addresses of its 1233 own enterprise-interior interfaces or the enterprise-interior 1234 interfaces of other nearby VBGs. 1236 5.6.2. Neighbor Unreachability Detection 1238 VET nodes perform Neighbor Unreachability Detection (NUD) by 1239 monitoring hints of forward progress. The VET node can periodically 1240 set the 'A' bit in the header of SEAL data packets to elicit SCMP 1241 responses from the neighbor. The VET node can also send SCMP 1242 Neighbor Solicitation (SNS) messages to the neighbor to elicit SCMP 1243 Neighbor Advertisement (SNA) messages. 1245 Responsiveness to routing changes is directly related to the delay in 1246 detecting that a neighbor has gone unreachable. In order to provide 1247 responsiveness comparable to dynamic routing protocols, a reasonably 1248 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1250 Additionally, a VET node may receive outer IP ICMP "Destination 1251 Unreachable; net / host unreachable" messages from an ER on the path 1252 indicating that the path to a neighbor may be failing. The VET node 1253 SHOULD first check the packet-in-error to obtain reasonable assurance 1254 that the ICMP message is authentic. If the node receives excessive 1255 ICMP unreachable errors through multiple RLOCs associated with the 1256 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1257 packets to flow through a different route (e.g., a default route with 1258 a VBG as the next hop). 1260 5.6.3. Redirection 1262 The VET node connected to the source EUN (i.e., the source VET node) 1263 can set R=1 in the SEAL header of a data packet to be forwarded as a 1264 "predirect" indication that SCMP Redirect (SRD) messages will be 1265 accepted from the VET node connected to the destination EUN (i.e., 1266 the target VET node). Each VBG on the VET interface chain to the 1267 target preserves the state of the R bit when it re-encapsulates and 1268 forwards the packet. 1270 When the target VET node receives the predirect indication, it 1271 returns an SRD message similar to the manner described in AERO 1272 [I-D.templin-aero]. The SRD message is formatted the same as for an 1273 ICMPv6 Redirect message as shown in Section 4.5 of[RFC4861]. The 1274 target includes Target Link Layer Address Options (TLLAOs) formatted 1275 as specified above, then adds a Redirected Header Option (RHO) that 1276 includes the leading portion of the SEAL data packet that triggered 1277 the redirection event beginning immediately following the SEAL 1278 header. 1280 The target VET node then creates a 128-bit secret key value (T_Key) 1281 that it will use to validate the SEAL header/trailer ICVs in future 1282 packets it will receive from the (redirected) source VET node. The 1283 target encrypts T_Key with the secret key it uses to validate the 1284 ICVs in SEAL packets received from the previous VET interface hop 1285 (P_Key(N)). It then writes the encrypted value in the "Target" field 1286 of the SRD message, i.e., instead of an IPv6 address. 1288 The target VET node then encapsulates the SRD message in a SEAL 1289 header/trailer as specified above, except that it sets P=0 and does 1290 not include a PREFIX field. The target also writes the prefix length 1291 associated with the inner destination address of the SEAL data packet 1292 that triggered the redirection event in the PREFLEN field of the SEAL 1293 header. For example, if the destination address is 2001:db8::1 and 1294 the destination prefix is 2001:db8::/48, the target sets the PREFLEN 1295 field to the value 48. The target then calculates the SEAL ICVs and 1296 returns the message to the previous hop VBG on the chain toward the 1297 source. 1299 When the target returns the SRD message, each intermediate VBG in the 1300 chain toward the source relays the message by examining the source 1301 address of the inner packet within the RHO to determine the previous 1302 hop toward the source. Each intermediate VBG in the chain verifies 1303 the SRD message SEAL ICVs and decrypts the T_Key value in the SRD 1304 message "Target" field using its own secret key (P_Key(i)). The VBG 1305 then re-encrypts T_Key using the key corresponding to the next hop 1306 toward the source (P_Key(i-1)), then re-calculates the SEAL ICVs and 1307 sends the SRD message to the previous hop. This relaying process is 1308 the same as for SCMP error message relaying specified in Section 4.6 1309 of [I-D.templin-intarea-seal]. 1311 When the source VET node receives the SRD message, it discovers both 1312 the PREFLEN and candidate link layer addresses for this new 1313 (unidirectional) target VET node. The source node also caches the 1314 T_Key value, and uses it to calculate the ICVs it will include in the 1315 SEAL header/trailer of subsequent packets it sends to the target. 1317 The source then applies the PREFLEN to the inner destination address 1318 of the packet that triggered the redirection event, then installs the 1319 resulting prefix in a forwarding table entry with the target as the 1320 next hop. 1322 The source can subsequently send packets destined to an address 1323 covered by the destination prefix using SEAL encapsulation via the 1324 target as the next hop. The target can then use the ICVs in the SEAL 1325 data packets for inner source address validation 1326 [I-D.ietf-savi-framework], but it need not also check the outer 1327 source addresses/port numbers of the packets. Therefore, the outer 1328 addresses may change over time even if the inner source address stays 1329 the same. 1331 Following redirection, if the source is subsequently unable to reach 1332 the target via the route-optimized path, it deletes the destination 1333 prefix forwarding table entry and installs a new forwarding table 1334 entry for the destination prefix with a default router as the next 1335 hop. The source VET node thereafter sets R=0 in the SEAL headers of 1336 data packets that it sends toward the destination prefix, but it may 1337 attempt redirection again at a later time by again setting R=1. 1339 Finally, the source and target VET nodes should set an expiration 1340 timer on the destination forwarding table entry so that stale entries 1341 are deleted in a timely fashion. 1343 5.6.4. Bidirectional Neighbor Synchronization 1345 The tunnel neighbor relationship between a pair of VET interface 1346 tunnel neighbors can be either unidirectional or bidirectional. A 1347 unidirectional relationship (see: Section 5.6.3) can be established 1348 when the source VET node 'A' will tunnel data packets directly to a 1349 target VET node 'B', but 'B' will not tunnel data packets directly to 1350 'A'. A bidirectional relationship is necessary when a Client VET 1351 node establishes a connection to a Serving VBG . 1353 In order to establish a bidirectional tunnel neighbor relationship, 1354 the Client (call it "A") performs a reliable exchange (e.g., a short 1355 TCP transaction, a DHCP client/server exchange, etc.) with the Server 1356 (call it "B"). The application layer details of the transaction are 1357 out of scope for this document, and indeed need not be standardized 1358 as long as both the Client and Server observe the same 1359 specifications. Note that a short transaction instead of a 1360 persistent connection is advised if the outer network layer protocol 1361 addresses may change, e.g., due to a mobility event, due to loss of 1362 state in network middleboxes, etc. If there is assurance that the 1363 outer network layer protocol addresses will not change, then a 1364 persistent connection may be used. 1366 During the transaction, "A" and "B" first authenticate themselves to 1367 each other, then exchange information regarding the inner network 1368 layer prefixes that will be used for conveying inner packets that 1369 will be forwarded over the tunnel. In this process, the Client 1370 registers one or more link identifiers (LINK_IDs) with the Server to 1371 provide "handles" for the Client's outer IP connection addresses. 1372 This implies that, while the Client may be either behind a NAT or 1373 mobile (or both), the Server must be stable and publicly addressable. 1375 Following this bidirectional tunnel neighbor establishment, the 1376 neighbors monitor the soft state for liveness, e.g., using Neighbor 1377 Unreachability Detection hints of forward progress. When one of the 1378 neighbors wishes to terminate the relationship, it performs another 1379 short transaction to request the termination, then both neighbors 1380 delete their respective tunnel soft state. 1382 5.7. Neighbor Coordination on VET Interfaces using IPsec 1384 VET interfaces that use IPsec encapsulation [RFC4301] use the 1385 Internet Key Exchange protocol, version 2 (IKEv2) [RFC4306] to manage 1386 security association setup and maintenance. IKEv2 provides a logical 1387 equivalent of the SCMP in terms of VET interface neighbor 1388 coordinations; for example, IKEv2 also provides mechanisms for 1389 redirection [RFC5685] and mobility [RFC4555]. 1391 IPsec additionally provides an extended Identification field and ICV; 1392 these features allow IPsec to utilize outer IP fragmentation and 1393 reassembly with less risk of exposure to data corruption due to 1394 reassembly misassociations. 1396 5.8. Mobility and Multihoming Considerations 1398 VBRs that travel between distinct enterprise networks must either 1399 abandon their PA prefixes that are relative to the "old" network and 1400 obtain PA prefixes relative to the "new" network, or somehow 1401 coordinate with a "home" network to retain ownership of the prefixes. 1402 In the first instance, the VBR would be required to coordinate a 1403 network renumbering event on its attached networks using the new PA 1404 prefixes [RFC4192][RFC5887]. In the second instance, an adjunct 1405 mobility management mechanism is required. 1407 VBRs can retain their CPs as they travel between distinct network 1408 points of attachment as long as they continue to refresh their CP-to- 1409 RLOC address mappings with their serving VBG as described in 1410 [I-D.templin-ironbis]. (When the VBR moves far from its serving VBG, 1411 it can also select a new VBG in order to maintain optimal routing.) 1412 In this way, VBRs can update their CP-to-RLOC mappings in real time 1413 and without requiring an adjunct mobility management mechanism. 1415 VBRs that have true PI prefixes can withdraw the prefixes from former 1416 Internet points of attachment and re-advertise them at new points of 1417 attachment as they move. However, this method has been shown to 1418 produce excessive routing churn in the global internet BGP tables, 1419 and should be avoided for any mobility scenarios that may occur along 1420 short timescales. The alternative is to employ a system in which the 1421 true PI prefixes are not injected into the Internet routing system, 1422 but rather managed through some separate global mapping database. 1423 This latter method is employed by the LISP proposal [I-D.ietf-lisp]. 1425 The VBGs of a multihomed enterprise network participate in a private 1426 inner network layer routing protocol instance (e.g., via an interior 1427 BGP instance) to accommodate network partitions/merges as well as 1428 intra-enterprise mobility events. 1430 5.9. Multicast 1432 5.9.1. Multicast over (Non)Multicast Enterprise Networks 1434 Whether or not the underlying enterprise network supports a native 1435 multicasting service, the VET node can act as an inner network layer 1436 IGMP/MLD proxy [RFC4605] on behalf of its attached EUNs and convey 1437 its multicast group memberships over the VET interface to a VBG 1438 acting as a multicast router. Its inner network layer multicast 1439 transmissions will therefore be encapsulated in outer headers with 1440 the unicast address of the VBG as the destination. 1442 5.9.2. Multicast Over Multicast-Capable Enterprise Networks 1444 In multicast-capable enterprise networks, ERs provide an enterprise- 1445 wide multicasting service (e.g., Simplified Multicast Forwarding 1446 (SMF) [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) 1447 routing, Distance Vector Multicast Routing Protocol (DVMRP) routing, 1448 etc.) over their enterprise-interior interfaces such that outer IP 1449 multicast messages of site-scope or greater scope will be propagated 1450 across the enterprise network. For such deployments, VET nodes can 1451 optionally provide a native inner multicast/broadcast capability over 1452 their VET interfaces through mapping of the inner multicast address 1453 space to the outer multicast address space. In that case, operation 1454 of link-or greater-scoped inner multicasting services (e.g., a link- 1455 scoped neighbor discovery protocol) over the VET interface is 1456 available, but SHOULD be used sparingly to minimize enterprise-wide 1457 flooding. 1459 VET nodes encapsulate inner multicast messages sent over the VET 1460 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1461 followed by an outer IP header with a site-scoped outer IP multicast 1462 address as the destination. For the case of IPv6 and IPv4 as the 1463 inner/outer protocols (respectively), [RFC2529] provides mappings 1464 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1465 address space (for other encapsulations, mappings are established 1466 through administrative configuration or through an unspecified 1467 alternate static mapping). 1469 Multicast mapping for inner multicast groups over outer IP multicast 1470 groups can be accommodated, e.g., through VET interface snooping of 1471 inner multicast group membership and routing protocol control 1472 messages. To support inner-to-outer multicast address mapping, the 1473 VET interface acts as a virtual outer IP multicast host connected to 1474 its underlying interfaces. When the VET interface detects that an 1475 inner multicast group joins or leaves, it forwards corresponding 1476 outer IP multicast group membership reports on an underlying 1477 interface over which the VET interface is configured. If the VET 1478 node is configured as an outer IP multicast router on the underlying 1479 interfaces, the VET interface forwards locally looped-back group 1480 membership reports to the outer IP multicast routing process. If the 1481 VET node is configured as a simple outer IP multicast host, the VET 1482 interface instead forwards actual group membership reports (e.g., 1483 IGMP messages) directly over an underlying interface. 1485 Since inner multicast groups are mapped to site-scoped outer IP 1486 multicast groups, the VET node MUST ensure that the site-scoped outer 1487 IP multicast messages received on the underlying interfaces for one 1488 VET interface do not "leak out" to the underlying interfaces of 1489 another VET interface. This is accommodated through normal site- 1490 scoped outer IP multicast group filtering at enterprise network 1491 boundaries. 1493 5.10. Service Discovery 1495 VET nodes can perform enterprise-wide service discovery using a 1496 suitable name-to-address resolution service. Examples of flooding- 1497 based services include the use of LLMNR [RFC4795] over the VET 1498 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1499 over an underlying interface. More scalable and efficient service 1500 discovery mechanisms (e.g., anycast) are for further study. 1502 5.11. VET Link Partitioning 1504 A VET link can be partitioned into multiple distinct logical 1505 groupings. In that case, each partition configures its own distinct 1506 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1507 'isatapv2.zone2.example.com', etc.). 1509 VBGs can further create multiple IP subnets within a partition, e.g., 1510 by sending SRAs with PIOs containing different IP prefixes to 1511 different groups of VET hosts. VBGs can identify subnets, e.g., by 1512 examining RLOC prefixes, observing the enterprise-interior interfaces 1513 over which SRSs are received, etc. 1515 In the limiting case, VBGs can advertise a unique set of IP prefixes 1516 to each VET host such that each host belongs to a different subnet 1517 (or set of subnets) on the VET interface. 1519 5.12. VBG Prefix State Recovery 1521 VBGs retain explicit state that tracks the inner network layer 1522 prefixes delegated to VBRs connected to the VET link, e.g., so that 1523 packets are delivered to the correct VBRs. When a VBG loses some or 1524 all of its state (e.g., due to a power failure), client VBRs must 1525 refresh the VBG's state so that packets can be forwarded over correct 1526 routes. 1528 5.13. Legacy ISATAP Services 1530 VBGs can support legacy ISATAP services according to the 1531 specifications in [RFC5214]. In particular, VBGs can configure 1532 legacy ISATAP interfaces and VET interfaces over the same sets of 1533 underlying interfaces as long as the PRLs and IPv6 prefixes 1534 associated with the ISATAP/VET interfaces are distinct. 1536 Legacy ISATAP hosts acquire addresses and/or prefixes in the same 1537 manner and using the same mechanisms as described for VET hosts in 1538 Section 4.4 above. 1540 6. IANA Considerations 1542 There are no IANA considerations for this document. 1544 7. Security Considerations 1546 Security considerations for MANETs are found in [RFC2501]. 1548 The security considerations found in [RFC2529][RFC5214][RFC6324] also 1549 apply to VET. 1551 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1552 where attacks on the neighbor coordination protocol are possible. 1553 SEAL [I-D.templin-intarea-seal] supports path MTU discovery, and 1554 provides per-packet authenticating information for data origin 1555 authentication, anti-replay and message header integrity. 1557 Rogue neighbor coordination messages with spoofed RLOC source 1558 addresses can consume network resources and cause VET nodes to 1559 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1560 such RLOCs, as that may result in a denial of service to the RLOCs' 1561 legitimate owners. 1563 VBRs and VBGs observe the recommendations for network ingress 1564 filtering [RFC2827]. 1566 8. Related Work 1568 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1569 automatic tunneling in [RFC2529]; this concept was later called: 1570 "Virtual Ethernet" and investigated by Quang Nguyen under the 1571 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1572 their colleagues have motivated a number of foundational concepts on 1573 which this work is based. 1575 Telcordia has proposed DHCP-related solutions for MANETs through the 1576 CECOM MOSAIC program. 1578 The Naval Research Lab (NRL) Information Technology Division uses 1579 DHCP in their MANET research testbeds. 1581 Security concerns pertaining to tunneling mechanisms are discussed in 1582 [I-D.ietf-v6ops-tunnel-security-concerns]. 1584 Default router and prefix information options for DHCPv6 are 1585 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1587 An automated IPv4 prefix delegation mechanism is proposed in 1588 [I-D.ietf-dhc-subnet-alloc]. 1590 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1591 [I-D.clausen-manet-autoconf-recommendations]. 1593 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1595 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1596 decapsulation issues and other aspects of tunneling. 1598 Various proposals within the IETF have suggested similar mechanisms. 1600 9. Acknowledgements 1602 The following individuals gave direct and/or indirect input that was 1603 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1604 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1605 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1606 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1607 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1608 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1609 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1610 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1611 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1612 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1613 working groups. Many others have provided guidance over the course 1614 of many years. 1616 Discussions with colleagues following the publication of RFC5558 have 1617 provided useful insights that have resulted in significant 1618 improvements to this, the Second Edition of VET. 1620 10. Contributors 1622 The following individuals have contributed to this document: 1624 Eric Fleischman (eric.fleischman@boeing.com) 1625 Thomas Henderson (thomas.r.henderson@boeing.com) 1626 Steven Russert (steven.w.russert@boeing.com) 1627 Seung Yi (seung.yi@boeing.com) 1629 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1630 of the document. 1632 Jim Bound's foundational work on enterprise networks provided 1633 significant guidance for this effort. We mourn his loss and honor 1634 his contributions. 1636 11. References 1638 11.1. Normative References 1640 [I-D.templin-intarea-seal] 1641 Templin, F., "The Subnetwork Encapsulation and Adaptation 1642 Layer (SEAL)", draft-templin-intarea-seal-36 (work in 1643 progress), October 2011. 1645 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1646 September 1981. 1648 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1649 RFC 792, September 1981. 1651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1652 Requirement Levels", BCP 14, RFC 2119, March 1997. 1654 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1655 RFC 2131, March 1997. 1657 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1658 (IPv6) Specification", RFC 2460, December 1998. 1660 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1661 Defeating Denial of Service Attacks which employ IP Source 1662 Address Spoofing", BCP 38, RFC 2827, May 2000. 1664 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1665 Messages", RFC 3118, June 2001. 1667 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1668 and M. Carney, "Dynamic Host Configuration Protocol for 1669 IPv6 (DHCPv6)", RFC 3315, July 2003. 1671 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1672 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1673 December 2003. 1675 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1676 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1678 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1679 RFC 3972, March 2005. 1681 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1682 Architecture", RFC 4291, February 2006. 1684 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1685 Message Protocol (ICMPv6) for the Internet Protocol 1686 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1688 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1689 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1690 September 2007. 1692 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1693 Address Autoconfiguration", RFC 4862, September 2007. 1695 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1696 for IEEE 802 Parameters", BCP 141, RFC 5342, 1697 September 2008. 1699 11.2. Informative References 1701 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1702 Switching Networks", May 1974. 1704 [I-D.carpenter-flow-ecmp] 1705 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1706 for equal cost multipath routing and link aggregation in 1707 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 1708 October 2010. 1710 [I-D.cheshire-dnsext-multicastdns] 1711 Cheshire, S. and M. Krochmal, "Multicast DNS", 1712 draft-cheshire-dnsext-multicastdns-14 (work in progress), 1713 February 2011. 1715 [I-D.clausen-manet-autoconf-recommendations] 1716 Clausen, T. and U. Herberg, "MANET Router Configuration 1717 Recommendations", 1718 draft-clausen-manet-autoconf-recommendations-00 (work in 1719 progress), February 2009. 1721 [I-D.clausen-manet-linktype] 1722 Clausen, T., "The MANET Link Type", 1723 draft-clausen-manet-linktype-00 (work in progress), 1724 October 2008. 1726 [I-D.droms-dhc-dhcpv6-default-router] 1727 Droms, R. and T. Narten, "Default Router and Prefix 1728 Advertisement Options for DHCPv6", 1729 draft-droms-dhc-dhcpv6-default-router-00 (work in 1730 progress), March 2009. 1732 [I-D.ietf-6man-udpzero] 1733 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 1734 Considerations", draft-ietf-6man-udpzero-04 (work in 1735 progress), October 2011. 1737 [I-D.ietf-dhc-subnet-alloc] 1738 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1739 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-12 1740 (work in progress), June 2011. 1742 [I-D.ietf-grow-va] 1743 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1744 L. Zhang, "FIB Suppression with Virtual Aggregation", 1745 draft-ietf-grow-va-05 (work in progress), June 2011. 1747 [I-D.ietf-lisp] 1748 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1749 "Locator/ID Separation Protocol (LISP)", 1750 draft-ietf-lisp-16 (work in progress), November 2011. 1752 [I-D.ietf-manet-smf] 1753 Macker, J., "Simplified Multicast Forwarding", 1754 draft-ietf-manet-smf-12 (work in progress), July 2011. 1756 [I-D.ietf-savi-framework] 1757 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1758 "Source Address Validation Improvement Framework", 1759 draft-ietf-savi-framework-05 (work in progress), 1760 July 2011. 1762 [I-D.ietf-v6ops-tunnel-security-concerns] 1763 Krishnan, S., Thaler, D., and J. Hoagland, "Security 1764 Concerns With IP Tunneling", 1765 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 1766 progress), October 2010. 1768 [I-D.jen-apt] 1769 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1770 L. Zhang, "APT: A Practical Transit Mapping Service", 1771 draft-jen-apt-01 (work in progress), November 2007. 1773 [I-D.templin-aero] 1774 Templin, F., "Asymmetric Extended Route Optimization 1775 (AERO)", draft-templin-aero-04 (work in progress), 1776 October 2011. 1778 [I-D.templin-ironbis] 1779 Templin, F., "The Internet Routing Overlay Network 1780 (IRON)", draft-templin-ironbis-07 (work in progress), 1781 October 2011. 1783 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1784 July 1978. 1786 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1787 Protocol Specification", October 2008. 1789 [RFC0994] International Organization for Standardization (ISO) and 1790 American National Standards Institute (ANSI), "Final text 1791 of DIS 8473, Protocol for Providing the Connectionless- 1792 mode Network Service", RFC 994, March 1986. 1794 [RFC1035] Mockapetris, P., "Domain names - implementation and 1795 specification", STD 13, RFC 1035, November 1987. 1797 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1798 a subnetwork for experimentation with the OSI network 1799 layer", RFC 1070, February 1989. 1801 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1802 Communication Layers", STD 3, RFC 1122, October 1989. 1804 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1805 Routing and Addressing Architecture", RFC 1753, 1806 December 1994. 1808 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1809 E. Lear, "Address Allocation for Private Internets", 1810 BCP 5, RFC 1918, February 1996. 1812 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1813 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1815 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1816 October 1996. 1818 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1819 Extensions", RFC 2132, March 1997. 1821 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1822 IPv6 Specification", RFC 2473, December 1998. 1824 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1825 over Non-Broadcast Multiple Access (NBMA) networks", 1826 RFC 2491, January 1999. 1828 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1829 (MANET): Routing Protocol Performance Issues and 1830 Evaluation Considerations", RFC 2501, January 1999. 1832 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1833 Domains without Explicit Tunnels", RFC 2529, March 1999. 1835 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1836 February 2000. 1838 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1839 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1840 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1841 RFC 3819, July 2004. 1843 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1844 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1845 May 2005. 1847 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1848 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1849 January 2005. 1851 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1852 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1853 RFC 3948, January 2005. 1855 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1856 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1857 September 2005. 1859 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1860 Addresses", RFC 4193, October 2005. 1862 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1863 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1865 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1866 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1868 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1869 Internet Protocol", RFC 4301, December 2005. 1871 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1872 RFC 4306, December 2005. 1874 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1875 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1876 May 2006. 1878 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1879 (MOBIKE)", RFC 4555, June 2006. 1881 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1882 System", RFC 4592, July 2006. 1884 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1885 "Internet Group Management Protocol (IGMP) / Multicast 1886 Listener Discovery (MLD)-Based Multicast Forwarding 1887 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1889 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1890 Multicast Name Resolution (LLMNR)", RFC 4795, 1891 January 2007. 1893 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1894 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1895 Focus", RFC 4852, April 2007. 1897 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1898 June 2007. 1900 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1901 Extensions for Stateless Address Autoconfiguration in 1902 IPv6", RFC 4941, September 2007. 1904 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1905 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1906 March 2008. 1908 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1909 for IPv6", RFC 5340, July 2008. 1911 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1912 Infrastructures (6rd)", RFC 5569, January 2010. 1914 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1915 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1916 RFC 5685, November 2009. 1918 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1919 Global Enterprise Recursion (RANGER)", RFC 5720, 1920 February 2010. 1922 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1923 Still Needs Work", RFC 5887, May 2010. 1925 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1926 Infrastructures (6rd) -- Protocol Specification", 1927 RFC 5969, August 2010. 1929 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 1930 Addressing in Networks with Global Enterprise Recursion 1931 (RANGER) Scenarios", RFC 6139, February 2011. 1933 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1934 IPv6 Automatic Tunnels: Problem Statement and Proposed 1935 Mitigations", RFC 6324, August 2011. 1937 Appendix A. Duplicate Address Detection (DAD) Considerations 1939 A priori uniqueness determination (also known as "pre-service DAD") 1940 for an RLOC assigned on an enterprise-interior interface would 1941 require either flooding the entire enterprise network or somehow 1942 discovering a link in the network on which a node that configures a 1943 duplicate address is attached and performing a localized DAD exchange 1944 on that link. But, the control message overhead for such an 1945 enterprise-wide DAD would be substantial and prone to false-negatives 1946 due to packet loss and intermittent connectivity. An alternative to 1947 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1948 enterprise-interior interfaces and employ a passive in-service DAD 1949 (e.g., one that monitors routing protocol messages for duplicate 1950 assignments). 1952 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1953 CGAs, IPv6 privacy addresses, etc. with very small probability of 1954 collision. Pseudo-random IPv4 RLOCs can be generated through random 1955 assignment from a suitably large IPv4 prefix space. 1957 Consistent operational practices can assure uniqueness for VBG- 1958 aggregated addresses/prefixes, while statistical properties for 1959 pseudo-random address self-generation can assure uniqueness for the 1960 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1961 RLOC delegation authority should be used when available, while a 1962 passive in-service DAD mechanism should be used to detect RLOC 1963 duplications when there is no RLOC delegation authority. 1965 Appendix B. Anycast Services 1967 Some of the IPv4 addresses that appear in the Potential Router List 1968 may be anycast addresses, i.e., they may be configured on the VET 1969 interfaces of multiple VBRs/VBGs. In that case, each VET router 1970 interface that configures the same anycast address must exhibit 1971 equivalent outward behavior. 1973 Use of an anycast address as the IP destination address of tunneled 1974 packets can have subtle interactions with tunnel path MTU and 1975 neighbor discovery. For example, if the initial fragments of a 1976 fragmented tunneled packet with an anycast IP destination address are 1977 routed to different egress tunnel endpoints than the remaining 1978 fragments, the multiple endpoints will be left with incomplete 1979 reassembly buffers. This issue can be mitigated by ensuring that 1980 each egress tunnel endpoint implements a proactive reassembly buffer 1981 garbage collection strategy. Additionally, ingress tunnel endpoints 1982 that send packets with an anycast IP destination address must use the 1983 minimum path MTU for all egress tunnel endpoints that configure the 1984 same anycast address as the tunnel MTU. Finally, ingress tunnel 1985 endpoints should treat ICMP unreachable messages from a router within 1986 the tunnel as at most a weak indication of neighbor unreachability, 1987 since the failures may only be transient and a different path to an 1988 alternate anycast router quickly selected through reconvergence of 1989 the underlying routing protocol. 1991 Use of an anycast address as the IP source address of tunneled 1992 packets can lead to more serious issues. For example, when the IP 1993 source address of a tunneled packet is anycast, ICMP messages 1994 produced by routers within the tunnel might be delivered to different 1995 ingress tunnel endpoints than the ones that produced the packets. In 1996 that case, functions such as path MTU discovery and neighbor 1997 unreachability detection may experience non-deterministic behavior 1998 that can lead to communications failures. Additionally, the 1999 fragments of multiple tunneled packets produced by multiple ingress 2000 tunnel endpoints may be delivered to the same reassembly buffer at a 2001 single egress tunnel endpoint. In that case, data corruption may 2002 result due to fragment misassociation during reassembly. 2004 In view of these considerations, VBGs that configure an anycast 2005 address should also configure one or more unicast addresses from the 2006 Potential Router List; they should further accept tunneled packets 2007 destined to any of their anycast or unicast addresses, but should 2008 send tunneled packets using a unicast address as the source address. 2010 Appendix C. Change Log 2012 (Note to RFC editor - this section to be removed before publication 2013 as an RFC.) 2015 Changes from -14 to -15: 2017 o new insights into default route configuration and next-hop 2018 determination 2020 Changes from -13 to -14: 2022 o fixed Idnits 2024 Changes from -12 to -13: 2026 o Changed "VGL" *back* to "PRL" 2028 o More changes for multi-protocol support 2029 o Changes to Redirect function 2031 Changes from -11 to -12: 2033 o Major section rearrangement 2035 o Changed "PRL" to "VGL" 2037 o Brought back text that was lost in the -10 to -11 transition 2039 Changes from -10 to -11: 2041 o Major changes with significant simplifications 2043 o Now support stateless PD using 6rd mechanisms 2045 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2047 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2049 Changes from -09 to -10: 2051 o Changed "enterprise" to "enterprise network" throughout 2053 o dropped "inner IP", since inner layer may be non-IP 2055 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2056 messages remain *within* the tunnel interface instead of being 2057 exposed to the inner network layer protocol engine. 2059 Changes from -08 to -09: 2061 o Expanded discussion of encapsulation/decapsulation procedures 2063 o cited IRON 2065 Changes from -07 to -08: 2067 o Specified the approach to global mapping using virtual aggregation 2068 and BGP 2070 Changes from -06 to -07: 2072 o reworked redirect function 2074 o created new section on VET interface encapsulation 2075 o clarifications on nexthop selection 2077 o fixed several bugs 2079 Changed from -05 to -06: 2081 o reworked VET interface ND 2083 o anycast clarifications 2085 Changes from -03 to -04: 2087 o security consideration clarifications 2089 Changes from -02 to -03: 2091 o security consideration clarifications 2093 o new PRLNAME for VET is "isatav2.example.com" 2095 o VET now uses SEAL natively 2097 o EBGs can support both legacy ISATAP and VET over the same 2098 underlying interfaces. 2100 Changes from -01 to -02: 2102 o Defined CGA and privacy address configuration on VET interfaces 2104 o Interface identifiers added to routing protocol control messages 2105 for link-layer multiplexing 2107 Changes from -00 to -01: 2109 o Section 4.1 clarifications on link-local assignment and RLOC 2110 autoconfiguration. 2112 o Appendix B clarifications on Weak End System Model 2114 Changes from RFC5558 to -00: 2116 o New appendix on RLOC configuration on VET interfaces. 2118 Author's Address 2120 Fred L. Templin (editor) 2121 Boeing Research & Technology 2122 P.O. Box 3707 MC 7L-49 2123 Seattle, WA 98124 2124 USA 2126 Email: fltemplin@acm.org