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