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