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