idnits 2.17.1 draft-templin-intarea-vet-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 6, 2010) is 4889 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-24 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-12 == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-02 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-11 == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-03 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-10 == Outdated reference: A later version (-17) exists of draft-templin-iron-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) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Standards Track December 6, 2010 5 Expires: June 9, 2011 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-19.txt 10 Abstract 12 Enterprise networks connect hosts and routers over various link 13 types, and often also connect to provider networks and/or the global 14 Internet. Enterprise network nodes require a means to automatically 15 provision addresses/prefixes and support internetworking operation in 16 a wide variety of use cases including Small Office, Home Office 17 (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, 18 multi-organizational corporate networks and the interdomain core of 19 the global Internet itself. This document specifies a Virtual 20 Enterprise Traversal (VET) abstraction for autoconfiguration and 21 operation of nodes in enterprise networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 9, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Enterprise Network Characteristics . . . . . . . . . . . . . . 11 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 61 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 13 62 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 14 63 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 15 64 4.2.2. Provider-Aggregated (PA) EID Prefix 65 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 66 4.2.3. Provider-(In)dependent (PI) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 68 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 18 69 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 19 70 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 19 71 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 19 72 5.1.1. PI Prefix Routing Considerations . . . . . . . . . . . 20 73 5.2. Default Route Configuration and Selection . . . . . . . . 20 74 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 21 75 5.4. Next Hop Determination . . . . . . . . . . . . . . . . . . 21 76 5.5. VET Interface Encapsulation/Decapsulation . . . . . . . . 22 77 5.5.1. Inner Network Layer Protocol . . . . . . . . . . . . . 22 78 5.5.2. Mid-Layer Encapsulation . . . . . . . . . . . . . . . 23 79 5.5.3. SEAL Encapsulation . . . . . . . . . . . . . . . . . . 23 80 5.5.4. Outer UDP Header Encapsulation . . . . . . . . . . . . 23 81 5.5.5. Outer IP Header Encapsulation . . . . . . . . . . . . 24 82 5.5.6. Decapsulation . . . . . . . . . . . . . . . . . . . . 24 83 5.6. Mobility and Multihoming Considerations . . . . . . . . . 25 84 5.7. Neighbor Coordination on VET Interfaces using SEAL . . . . 25 85 5.7.1. Router Discovery . . . . . . . . . . . . . . . . . . . 27 86 5.7.2. Neighbor Unreachability Detection . . . . . . . . . . 28 87 5.7.3. Redirect Function . . . . . . . . . . . . . . . . . . 28 88 5.8. Neighbor Coordination on VET Interfaces using IPsec . . . 30 89 5.9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 30 90 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 91 5.11. Enterprise Network Partitioning . . . . . . . . . . . . . 31 92 5.12. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 32 93 5.13. Support for Legacy ISATAP Services . . . . . . . . . . . . 32 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 96 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 102 Appendix A. Duplicate Address Detection (DAD) Considerations . . 40 103 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 41 104 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 43 105 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 44 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 108 1. Introduction 110 Enterprise networks [RFC4852] connect hosts and routers over various 111 link types (see [RFC4861], Section 2.2). The term "enterprise 112 network" in this context extends to a wide variety of use cases and 113 deployment scenarios. For example, an "enterprise" can be as small 114 as a SOHO network, as complex as a multi-organizational corporation, 115 or as large as the global Internet itself. Internet Service Provider 116 (ISP) networks are another example use case that fits well with the 117 VET enterprise network model. Mobile Ad hoc Networks (MANETs) 118 [RFC2501] can also be considered as a challenging example of an 119 enterprise network, in that their topologies may change dynamically 120 over time and that they may employ little/no active management by a 121 centralized network administrative authority. These specialized 122 characteristics for MANETs require careful consideration, but the 123 same principles apply equally to other enterprise network scenarios. 125 This document specifies a Virtual Enterprise Traversal (VET) 126 abstraction for autoconfiguration and internetworking operation, 127 where addresses of different scopes may be assigned on various types 128 of interfaces with diverse properties. Both IPv4/ICMPv4 129 [RFC0791][RFC0792] and IPv6/ICMPv6 [RFC2460][RFC4443] are discussed 130 within this context (other network layer protocols are also 131 considered). The use of standard DHCP [RFC2131] [RFC3315] is assumed 132 unless otherwise specified. 134 Provider-Edge Interfaces 135 x x x 136 | | | 137 +--------------------+---+--------+----------+ E 138 | | | | | n 139 | I | | .... | | t 140 | n +---+---+--------+---+ | e 141 | t | +--------+ /| | r 142 | e I x----+ | Host | I /*+------+--< p I 143 | r n | |Function| n|**| | r n 144 | n t | +--------+ t|**| | i t 145 | a e x----+ V e|**+------+--< s e 146 | l r . | E r|**| . | e r 147 | f . | T f|**| . | f 148 | V a . | +--------+ a|**| . | I a 149 | i c . | | Router | c|**| . | n c 150 | r e x----+ |Function| e \*+------+--< t e 151 | t s | +--------+ \| | e s 152 | u +---+---+--------+---+ | r 153 | a | | .... | | i 154 | l | | | | o 155 +--------------------+---+--------+----------+ r 156 | | | 157 x x x 158 Enterprise-Edge Interfaces 160 Figure 1: Enterprise Router (ER) Architecture 162 Figure 1 above depicts the architectural model for an Enterprise 163 Router (ER). As shown in the figure, an ER may have a variety of 164 interface types including enterprise-edge, enterprise-interior, 165 provider-edge, internal-virtual, as well as VET interfaces used for 166 encapsulating inner network layer protocol packets for transmission 167 over outer IPv4 or IPv6 networks. The different types of interfaces 168 are defined, and the autoconfiguration mechanisms used for each type 169 are specified. This architecture applies equally for MANET routers, 170 in which enterprise-interior interfaces correspond to the wireless 171 multihop radio interfaces typically associated with MANETs. Out of 172 scope for this document is the autoconfiguration of provider 173 interfaces, which must be coordinated in a manner specific to the 174 service provider's network. 176 Enterprise networks require a means for supporting both Provider- 177 (In)dependent (PI) and Provider-Aggregated (PA) addressing. This is 178 especially true for enterprise network scenarios that involve 179 mobility and multihoming. The VET specification provides adaptable 180 mechanisms that address these and other issues in a wide variety of 181 enterprise network use cases. 183 The VET framework builds on a Non-Broadcast Multiple Access (NBMA) 184 [RFC2491] virtual interface model in a manner similar to other 185 automatic tunneling technologies [RFC2529][RFC5214]. VET interfaces 186 support the encapsulation of inner network layer protocol packets 187 over IP networks (i.e., either IPv4 or IPv6). VET is also compatible 188 with mid-layer encapsulation technologies including IPsec [RFC4301], 189 and supports both stateful and stateless prefix delegation. 191 VET and its associated technologies (including the Subnetwork 192 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal]) 193 are functional building blocks for a new Internetworking architecture 194 based on the Internet Routing Overlay Network (IRON) 195 [I-D.templin-iron] and Routing and Addressing in Networks with Global 196 Enterprise Recursion (RANGER) [RFC5720] [I-D.russert-rangers]. Many 197 of the VET principles can be traced to the deliberations of the ROAD 198 group in January 1992, and also to still earlier initiatives 199 including NIMROD [RFC1753] and the Catenet model for internetworking 200 [CATENET] [IEN48] [RFC2775]. [RFC1955] captures the high-level 201 architectural aspects of the ROAD group deliberations in a "New 202 Scheme for Internet Routing and Addressing (ENCAPS) for IPNG". 204 VET is related to the present-day activities of the IETF INTAREA, 205 AUTOCONF, DHC, IPv6, MANET, and V6OPS working groups, as well as the 206 IRTF RRG working group. 208 2. Terminology 210 The mechanisms within this document build upon the fundamental 211 principles of IP encapsulation. The term "inner" refers to the 212 innermost {address, protocol, header, packet, etc.} *before* 213 encapsulation, and the term "outer" refers to the outermost {address, 214 protocol, header, packet, etc.} *after* encapsulation. VET also 215 accommodates "mid-layer" encapsulations including the Subnetwork 216 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal], 217 IPsec [RFC4301], etc. 219 The terminology in the normative references apply; the following 220 terms are defined within the scope of this document: 222 Virtual Enterprise Traversal (VET) 223 an abstraction that uses IP encapsulation to create overlays for 224 traversing IPv4 and IPv6 enterprise networks. 226 enterprise network 227 the same as defined in [RFC4852]. An enterprise network is 228 further understood to refer to a cooperative networked collective 229 of devices within a structured IP routing and addressing plan and 230 with a commonality of business, social, political, etc., 231 interests. Minimally, the only commonality of interest in some 232 enterprise network scenarios may be the cooperative provisioning 233 of connectivity itself. 235 subnetwork 236 the same as defined in [RFC3819]. 238 site 239 a logical and/or physical grouping of interfaces that connect a 240 topological area less than or equal to an enterprise network in 241 scope. From a network organizational standpoint, a site within an 242 enterprise network can be considered as an enterprise unto itself. 244 Mobile Ad hoc Network (MANET) 245 a connected topology of mobile or fixed routers that maintain a 246 routing structure among themselves over dynamic links. The 247 characteristics of MANETs are defined in [RFC2501], Section 3, and 248 a wide variety of MANETs share common properties with enterprise 249 networks. 251 enterprise/site/MANET 252 throughout the remainder of this document, the term "enterprise 253 network" is used to collectively refer to any of {enterprise, 254 site, MANET}, i.e., the VET mechanisms and operational principles 255 can be applied to enterprises, sites, and MANETs of any size or 256 shape. 258 Enterprise Router (ER) 259 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 260 mobile router that comprises a router function, a host function, 261 one or more enterprise-interior interfaces, and zero or more 262 internal virtual, enterprise-edge, provider-edge, and VET 263 interfaces. At a minimum, an ER forwards outer IP packets over 264 one or more sets of enterprise-interior interfaces, where each set 265 connects to a distinct enterprise network. 267 Enterprise Border Router (EBR) 268 an ER that connects edge networks to the enterprise network and/or 269 connects multiple enterprise networks together. An EBR is a 270 tunnel endpoint router, and it configures a separate VET interface 271 over each set of enterprise-interior interfaces that connect the 272 EBR to each distinct enterprise network. In particular, an EBR 273 may configure multiple VET interfaces - one for each distinct 274 enterprise network. All EBRs are also ERs. 276 Enterprise Border Gateway (EBG) 277 an EBR that connects child enterprise networks to provider 278 networks - either directly via a provider-edge interface or 279 indirectly via another VET interface configured over a parent 280 enterprise network. EBRs may act as EBGs on some VET interfaces 281 and as ordinary EBRs on other VET interfaces. All EBGs are also 282 EBRs. 284 VET host 285 any node (host or router) that configures a VET interface for 286 host-operation only. Note that a node may configure some of its 287 VET interfaces as host interfaces and others as router interfaces. 289 VET node 290 any node (host or router) that configures and uses a VET 291 interface. 293 enterprise-interior interface 294 an ER's attachment to a link within an enterprise network. 295 Packets sent over enterprise-interior interfaces may be forwarded 296 over multiple additional enterprise-interior interfaces within the 297 enterprise network before they are forwarded via an enterprise- 298 edge interface, provider-edge interface, or a VET interface 299 configured over a different enterprise network. Enterprise- 300 interior interfaces connect laterally within the IP network 301 hierarchy. 303 enterprise-edge interface 304 an EBR's attachment to a link (e.g., an Ethernet, a wireless 305 personal area network, etc.) on an arbitrarily complex edge 306 network that the EBR connects to an enterprise network and/or 307 provider network. Enterprise-edge interfaces connect to lower 308 levels within the IP network hierarchy. 310 provider-edge interface 311 an EBR's attachment to the Internet or to a provider network via 312 which the Internet can be reached. Provider-edge interfaces 313 connect to higher levels within the IP network hierarchy. 315 internal-virtual interface 316 an interface that is internal to an EBR and does not in itself 317 directly attach to a tangible physical link (e.g., an Ethernet 318 cable, a WiFi radio, etc.). Examples include a loopback 319 interface, a virtual private network interface, or some form of 320 tunnel interface. 322 VET link 323 a virtual link that uses automatic tunneling to create an overlay 324 network that spans an enterprise-interior routing region. VET 325 links can be segmented (e.g., by filtering gateways) into multiple 326 distinct segments that can be joined together by bridges or IP 327 routers the same as for any link. Bridging would view the 328 multiple (bridged) segments as a single VET link, whereas IP 329 routing would view the multiple segments as multiple distinct VET 330 links. VET link segments can further be partitioned into multiple 331 logical areas, where each area is identified by a distinct set of 332 EBGs. 334 VET links in non-multicast enterprise networks are Non-Broadcast, 335 Multiple Access (NBMA); VET links in enterprise networks that 336 support multicast are multicast capable. 338 VET interface 339 a VET node's attachment to a VET link. VET nodes configure each 340 VET interface over a set of underlying enterprise-interior 341 interfaces that connect to a routing region spanned by a single 342 VET link. When there are multiple distinct VET links (each with 343 their own distinct set of underlying interfaces), the VET node 344 configures separate VET interfaces for each link. 346 The VET interface encapsulates each inner packet in any mid-layer 347 headers followed by an outer IP header, then forwards the packet 348 on an underlying interface such that the Time to Live (TTL) - Hop 349 Limit in the inner header is not decremented as the packet 350 traverses the link. The VET interface therefore presents an 351 automatic tunneling abstraction that represents the link as a 352 single IP hop. 354 Provider Aggregated (PA) prefix 355 a network layer protocol prefix that is delegated to an EBR by a 356 provider network. 358 Provider-Independent (PI) address/prefix 359 a network layer protocol prefix that is delegated to an EBR by an 360 independent prefix registration authority. 362 Routing Locator (RLOC) 363 a public-scope or enterprise-local-scope IP address that can 364 appear in enterprise-interior and/or interdomain routing tables. 365 Public-scope RLOCs are delegated to specific enterprise networks 366 and routable within both the enterprise-interior and interdomain 367 routing regions. Enterprise-local-scope RLOCs (e.g., IPv6 Unique 368 Local Addresses [RFC4193], IPv4 privacy addresses [RFC1918], etc.) 369 are self-generated by individual enterprise networks and routable 370 only within the enterprise-interior routing region. 372 ERs use RLOCs for operating the enterprise-interior routing 373 protocol and for next-hop determination in forwarding packets 374 addressed to other RLOCs. End systems can use RLOCs as addresses 375 for end-to-end communications between peers within the same 376 enterprise network. VET interfaces treat RLOCs as *outer* IP 377 addresses during encapsulation. 379 Endpoint Interface iDentifier (EID) 380 a public-scope network layer address that is routable within an 381 enterprise-edge or VET overlay network. EID prefixes are separate 382 and distinct from any RLOC prefix space, but are mapped to RLOC 383 addresses to support routing over VET interfaces. 385 EBRs use EIDs for operating the enterprise-edge or VET overlay 386 network routing protocol and for next-hop determination in 387 forwarding packets addressed to other EIDs. End systems can use 388 EIDs as addresses for end-to-end communications between peers 389 either within the same enterprise network or within different 390 enterprise networks. VET interfaces treat EIDs as *inner* network 391 layer addresses during encapsulation. 393 Note that an EID can also be used as an *outer* network layer 394 address if there are nested encapsulations. In that case, the EID 395 would appear as an RLOC to the innermost encapsulation. 397 The following additional acronyms are used throughout the document: 399 CGA - Cryptographically Generated Address 400 DHCP(v4, v6) - Dynamic Host Configuration Protocol 401 ECMP - Equal Cost Multi Path 402 FIB - Forwarding Information Base 403 ICMP - either ICMPv4 or ICMPv6 404 IP - either IPv4 or IPv6 405 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 406 NBMA - Non-Broadcast, Multiple Access 407 ND - Neighbor Discovery 408 NS/NA - Neighbor Solicitation/Advertisement 409 PIO - Prefix Information Option 410 PRL - Potential Router List 411 PRLNAME - Identifying name for the PRL 412 RIB - Routing Information Base 413 RIO - Route Information Option 414 RPF - Reverse Path Forwarding 415 RS/RA - Router Solicitation/Advertisement 416 SCMP - SEAL Control Message Protocol 417 SEAL - Subnetwork Encapsulation and Adaptation Layer 418 SLAAC - IPv6 StateLess Address AutoConfiguration 420 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 421 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 422 document are to be interpreted as described in [RFC2119]. When used 423 in lower case (e.g., must, must not, etc.), these words MUST NOT be 424 interpreted as described in [RFC2119], but are rather interpreted as 425 they would be in common English. 427 3. Enterprise Network Characteristics 429 Enterprise networks consist of links that are connected by Enterprise 430 Routers (ERs) as depicted in Figure 1. ERs typically participate in 431 a routing protocol over enterprise-interior interfaces to discover 432 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 433 Enterprise Border Routers (EBRs) are ERs that connect edge networks 434 to the enterprise network and/or join multiple enterprise networks 435 together. Enterprise Border Gateways (EBGs) are EBRs that connect 436 enterprise networks to provider networks. 438 Conceptually, an ER embodies both a host function and router 439 function, and supports communications according to the weak end- 440 system model [RFC1122]. The router function engages in the 441 enterprise-interior routing protocol, connects any of the ER's edge 442 networks to the enterprise networks, and may also connect the 443 enterprise network to provider networks (see Figure 1). The host 444 function typically supports network management applications, but may 445 also support diverse applications typically associated with general- 446 purpose computing platforms. 448 An enterprise network may be as simple as a small collection of ERs 449 and their attached edge networks; an enterprise network may also 450 contain other enterprise networks and/or be a subnetwork of a larger 451 enterprise network. An enterprise network may further encompass a 452 set of branch offices and/or nomadic hosts connected to a home office 453 over one or several service providers, e.g., through Virtual Private 454 Network (VPN) tunnels. Finally, an enterprise network may contain 455 many internal partitions that are logical or physical groupings of 456 nodes for the purpose of load balancing, organizational separation, 457 etc. In that case, each internal partition resembles an individual 458 segment of a bridged LAN. 460 Enterprise networks that comprise link types with sufficiently 461 similar properties (e.g., Layer 2 (L2) address formats, maximum 462 transmission units (MTUs), etc.) can configure a sub-IP layer routing 463 service such that IP sees the network as an ordinary shared link the 464 same as for a (bridged) campus LAN. In that case, a single IP hop is 465 sufficient to traverse the network without need for encapsulation. 466 Enterprise networks that comprise link types with diverse properties 467 and/or configure multiple IP subnets must also provide an enterprise- 468 interior routing service that operates as an IP layer mechanism. In 469 that case, multiple IP hops may be necessary to traverse the network 470 such that care must be taken to avoid multi-link subnet issues 471 [RFC4903]. 473 In addition to other interface types, VET nodes configure VET 474 interfaces that view all other nodes on the VET link as neighbors on 475 a virtual NBMA link. VET nodes configure a separate VET interface 476 for each distinct VET link to which they connect, and discover other 477 EBRs on the link that can be used for forwarding packets to off-link 478 destinations. 480 For each distinct enterprise network, a trust basis must be 481 established and consistently applied. For example, in enterprise 482 networks in which EBRs establish symmetric security associations, 483 mechanisms such as IPsec [RFC4301] can be used to assure 484 authentication and confidentiality. In other enterprise network 485 scenarios, asymmetric securing mechanisms such as SEcure Neighbor 486 Discovery (SEND) [RFC3971] may be necessary. Still other enterprise 487 networks may find it sufficient to employ additional encapsulations 488 (e.g., SEAL [I-D.templin-intarea-seal]) that include a nonce to 489 detect off-path attacks. 491 Finally, in enterprise networks with a centralized management 492 structure (e.g., a corporate campus network), an overlay routing/ 493 mapping service and a synchronized set of EBGs can provide sufficient 494 infrastructure support for virtual enterprise traversal. In that 495 case, the EBGs can provide a "default mapper" [I-D.jen-apt] service 496 used for short-term packet forwarding until route-optimized paths 497 between neighboring EBRs can be established. In enterprise networks 498 with a distributed management structure (e.g., disconnected MANETs), 499 peer-to-peer coordination between the EBRs themselves may be 500 required. Recognizing that various use cases will entail a continuum 501 between a fully distributed and fully centralized approach, the 502 following sections present the mechanisms of Virtual Enterprise 503 Traversal as they apply to a wide variety of scenarios. 505 4. Autoconfiguration 507 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 508 specified in the following subsections. 510 4.1. Enterprise Router (ER) Autoconfiguration 512 ERs configure enterprise-interior interfaces and engage in any 513 routing protocols over those interfaces. 515 When an ER joins an enterprise network, it first configures an IPv6 516 link-local address on each enterprise-interior interface and 517 configures an IPv4 link-local address on each enterprise-interior 518 interface that requires an IPv4 link-local capability. IPv6 link- 519 local address generation mechanisms include Cryptographically 520 Generated Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses 521 [RFC4941], StateLess Address AutoConfiguration (SLAAC) using EUI-64 522 interface identifiers [RFC4291] [RFC4862], etc. The mechanisms 523 specified in [RFC3927] provide an IPv4 link-local address generation 524 capability. 526 Next, the ER configures one or more RLOCs and engages in any routing 527 protocols on its enterprise-interior interfaces. The ER can 528 configure RLOCs via explicit management, DHCP autoconfiguration, 529 pseudo-random self-generation from a suitably large address pool, or 530 through an alternate autoconfiguration mechanism. The ER may 531 optionally configure and assign a separate RLOC for each underlying 532 interface, or it may configure only a single RLOC and assign it to a 533 VET interface configured over the underlying interfaces (see Section 534 4.2.1). In the latter case, the ER can use the VET interface for 535 link layer multiplexing and traffic engineering purposes as specified 536 in Appendix B. 538 Alternatively (or in addition), the ER can request RLOC prefix 539 delegations via an automated prefix delegation exchange over an 540 enterprise-interior interface and can assign the prefix(es) on 541 enterprise-edge interfaces. Note that in some cases, the same 542 enterprise-edge interfaces may assign both RLOC and EID addresses if 543 there is a means for source address selection. In other cases (e.g., 544 for separation of security domains), RLOCs and EIDs are assigned on 545 separate sets of enterprise-edge interfaces. 547 Pseudo-random self-generation of IPv6 RLOCs can be from a large 548 public or local-use IPv6 address range (e.g., IPv6 Unique Local 549 Addresses [RFC4193]). Pseudo-random self-generation of IPv4 RLOCs 550 can be from a large public or local-use IPv4 address range (e.g., 551 [RFC1918]). When self-generation is used alone, the ER continuously 552 monitors the RLOCs for uniqueness, e.g., by monitoring the 553 enterprise-interior routing protocol. (Note however that anycast 554 RLOCs MAY be assigned to multiple enterprise interior interfaces; 555 hence, monitoring for uniqueness applies only to RLOCs that are 556 intended as unicast.) 557 DHCP generation of RLOCs uses standard DHCP procedures but may 558 require support from relays within the enterprise network. For 559 DHCPv6, relays that do not already know the RLOC of a server within 560 the enterprise network forward requests to the 'All_DHCP_Servers' 561 site-scoped IPv6 multicast group [RFC3315]. For DHCPv4, relays that 562 do not already know the RLOC of a server within the enterprise 563 network forward requests to the site-scoped IPv4 multicast group 564 address 'All_DHCPv4_Servers', which SHOULD be set to 239.255.2.1 565 unless an alternate multicast group for the site is known. DHCPv4 566 servers that delegate RLOCs SHOULD therefore join the 567 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 568 received for that group. 570 A combined approach using both DHCP and self-generation is also 571 possible when the ER configures both a DHCP client and relay that are 572 connected, e.g., via a pair of back-to-back connected Ethernet 573 interfaces, a tun/tap interface, a loopback interface, inter-process 574 communication, etc. The ER first self-generates an RLOC from a 575 temporary addressing range used only for the bootstrapping purpose of 576 procuring an actual RLOC taken from a preferred addressing range. 577 The ER then engages in the enterprise-interior routing protocol and 578 performs a DHCP client/relay exchange using the temporary RLOC as the 579 address of the relay. When the DHCP server delegates an actual RLOC 580 address/prefix, the ER abandons the temporary RLOC and re-engages in 581 the enterprise-interior routing protocol using an RLOC taken from the 582 delegation. 584 In some enterprise network use cases (e.g., MANETs), assignment of 585 RLOCs on enterprise-interior interfaces as singleton addresses (i.e., 586 as addresses with /32 prefix lengths for IPv4, or as addresses with 587 /128 prefix lengths for IPv6) MAY be necessary to avoid multi-link 588 subnet issues. In other use cases, assignment of an RLOC on a VET 589 interface as specified in Appendix B can provide link layer 590 multiplexing and traffic engineering over multiple underlying 591 interfaces using only a single IP address. 593 4.2. Enterprise Border Router (EBR) Autoconfiguration 595 EBRs are ERs that configure VET interfaces over distinct sets of 596 underlying interfaces belonging to the same enterprise network; an 597 EBR can connect to multiple enterprise networks, in which case it 598 would configure multiple VET interfaces. In addition to the ER 599 autoconfiguration procedures specified in Section 4.1, EBRs perform 600 the following autoconfiguration operations. 602 4.2.1. VET Interface Initialization 604 EBRs configure a VET interface over a set of underlying interfaces 605 belonging to the same enterprise network such that all other nodes on 606 the VET link appear as single-hop neighbors from the standpoint of 607 the inner network layer protocol through the use of encapsulation. 608 If there are multiple inner network layer protocols (e.g., IPv4, 609 IPv6, OSI, etc.) the EBR configures a separate VET interface for each 610 protocol. 612 After the EBR configures a VET interface, it associates one or more 613 RLOCs with the interface to serve as the source addresses for outer 614 IP packets to be sent over underlying interfaces. The EBR then 615 assigns link-local addresses to the interface if necessary. When 616 IPv6 and IPv4 are used as the inner/outer protocols (respectively), 617 the EBR autoconfigures an IPv6 link-local address on the VET 618 interface using a modified EUI-64 interface identifier based on an 619 IPv4 address (see Section 2.2.1 of [RFC5342]). Link-local address 620 configuration for other inner/outer protocol combinations is through 621 administrative configuration, random self-generation (e.g., 622 [RFC4941], etc.) or through an unspecified alternate method. 624 The EBR next discovers a Potential Router List (PRL) that includes 625 the RLOC addresses of EBGs. The PRL names the VET interface, and is 626 specific to the address family of the inner network layer protocol 627 (e.g., IPv4, IPv6, OSI, etc.). If there are multiple address 628 families, then there will be multiple VET interfaces; each with its 629 own PRL. 631 The PRL can be discovered through information conveyed in the 632 enterprise-interior routing protocol, through a DHCP option 633 [I-D.templin-isatap-dhcp], an anycast EBG discovery message exchange, 634 etc. In multicast-capable enterprise networks, EBRs can also listen 635 for advertisements on the 'rasadv' [RASADV] multicast group address. 637 Whether or not other information is available, the EBR can resolve an 638 identifying name for the PRL ('PRLNAME') formed as 639 'hostname.domainname', where 'hostname' is an enterprise-specific 640 name string and 'domainname' is an enterprise-specific Domain Name 641 System (DNS) suffix [RFC1035]. The EBR discovers 'PRLNAME' through 642 manual configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 643 protocol advertisements, link-layer information (e.g., an IEEE 802.11 644 Service Set Identifier (SSID)), or through some other means specific 645 to the enterprise network. The EBR can also obtain 'PRLNAME' as part 646 of an arrangement with a private-sector PI prefix vendor (see: 647 Section 4.2.3). 649 In the absence of other information, the EBR sets the 'hostname' 650 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 651 component to an enterprise-specific DNS suffix (e.g., "example.com"). 652 Isolated enterprise networks that do not connect to the outside world 653 may have no enterprise-specific DNS suffix, in which case the 654 'PRLNAME' consists only of the 'hostname' component. (Note that the 655 default hostname "isatapv2" is intentionally distinct from the 656 convention specified in [RFC5214].) 658 After discovering 'PRLNAME', the EBR resolves the name into a list of 659 RLOC addresses through a name service lookup. For centrally managed 660 enterprise networks, the EBR resolves 'PRLNAME' using an enterprise- 661 local name service (e.g., the DNS). For enterprises with no 662 centralized management structure, the EBR resolves 'PRLNAME' using 663 Link-Local Multicast Name Resolution (LLMNR) [RFC4795] over the VET 664 interface. In that case, all EBGs in the PRL respond to the LLMNR 665 query, and the EBR accepts the union of all responses. 667 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 669 EBRs that connect their enterprise networks to a provider network 670 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 671 stateless autoconfiguration mechanisms. The stateful and stateless 672 approaches are discussed in the following subsections. 674 4.2.2.1. Stateful Prefix Delegation 676 For IPv4, EBRs acquire IPv4 PA EID prefixes via an automated IPv4 677 prefix delegation exchange, explicit management, etc. 679 For IPv6, EBRs acquire IPv6 PA EID prefixes via DHCPv6 Prefix 680 Delegation exchanges with an EBG acting as a DHCP relay/server. In 681 particular, the EBR (acting as a requesting router) can use DHCPv6 682 prefix delegation [RFC3633] over the VET interface to obtain prefixes 683 from the server (acting as a delegating router). The EBR obtains 684 prefixes using either a 2-message or 4-message DHCPv6 exchange 685 [RFC3315]. For example, to perform the 2-message exchange, the EBR's 686 DHCPv6 client forwards a Solicit message with an IA_PD option to its 687 DHCPv6 relay, i.e., the EBR acts as a combined client/relay (see 688 Section 4.1). The relay then forwards the message over the VET 689 interface using VET encapsulation (see: Section 5.4) to an EBG which 690 either services the request or relays it further. The forwarded 691 Solicit message will elicit a reply from the server containing prefix 692 delegations. The EBR can also propose a specific prefix to the 693 DHCPv6 server per Section 7 of [RFC3633]. The server will check the 694 proposed prefix for consistency and uniqueness, then return it in the 695 reply to the EBR if it was able to perform the delegation. 697 After the EBR receives IPv4 and/or IPv6 prefix delegations, it can 698 provision the prefixes on enterprise-edge interfaces as well as on 699 other VET interfaces configured over child enterprise networks for 700 which it acts as an EBG. The EBR can also provision the prefixes on 701 enterprise-interior interfaces to service any hosts attached to the 702 link. 704 The prefix delegations remain active as long as the EBR continues to 705 renew them via the delegating EBG before lease lifetimes expire. The 706 lease lifetime also keeps the delegation state active even if 707 communications between the EBR and delegating EBG are disrupted for a 708 period of time (e.g., due to an enterprise network partition, power 709 failure, etc.). Note however that if the EBR abandons or otherwise 710 loses continuity with the prefixes, it may be obliged to perform 711 network-wide renumbering if it subsequently receives a new and 712 different set of prefixes. 714 Stateful prefix delegation for non-IP protocols is out of scope. 716 4.2.2.2. Stateless Prefix Delegation 718 When IPv6 and IPv4 are used as the inner and outer protocols, 719 respectively, a stateless IPv6 PA prefix delegation capability is 720 available using the mechanisms specified in [RFC5569][RFC5969]. EBRs 721 can use these mechanisms to statelessly configure IPv6 PA prefixes 722 that embed one of the EBR's IPv4 RLOCs. 724 Using this stateless prefix delegation, if the IPv4 RLOC changes the 725 IPv6 prefix also changes and the EBR is obliged to renumber any 726 interfaces on which sub-prefixes from the delegated prefix are 727 assigned. This method may therefore be most suitable for enterprise 728 networks in which IPv4 RLOC assignments rarely change, or in 729 enterprise networks in which only services that do not depend on a 730 long-term stable IPv6 prefix (e.g., client-side web browsing) are 731 used. 733 Stateless prefix delegation for other protocol combinations is out of 734 scope. 736 4.2.3. Provider-(In)dependent (PI) EID Prefix Autoconfiguration 738 EBRs can acquire Provider (In)dependent (PI) prefixes to facilitate 739 multihoming, mobility and traffic engineering without requiring site- 740 wide renumbering events. These PI prefixes are made available to 741 EBRs through a prefix registration authority that may or may not be 742 associated with a specific ISP. 744 EBRs that connect major enterprise networks (e.g., large 745 corporations, academic campuses, ISP networks, etc.) to a parent 746 enterprise network and/or the global Internet can acquire short PI 747 prefixes (e.g., an IPv6 ::/20, an IPv4 /16, etc.) through a 748 registration authority such as the Internet Assigned Numbers 749 Authority (IANA) or a major regional Internet registry. EBRs that 750 connect small enterprise networks (e.g., SOHO networks, MANETs, etc.) 751 to a parent enterprise network can acquire longer PI prefixes through 752 arrangements with a PI prefix commercial vendor organization. 754 After an EBR receives PI prefixes, it can sub-delegate portions of 755 the prefixes on enterprise-edge interfaces, on other VET interfaces 756 for which it is configured as an EBG and on enterprise-interior 757 interfaces to service any hosts attached to the link. The EBR can 758 also sub-delegate portions of its PI prefixes to requesting routers 759 within child enterprise networks. These requesting routers consider 760 their sub-delegated portions of the PI prefix as PA, and consider the 761 delegating routers as their points of connection to a provider 762 network. 764 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 766 EBGs are EBRs that connect child enterprise networks to provider 767 networks via provider-edge interfaces and/or via VET interfaces 768 configured over parent enterprise networks. EBGs autoconfigure their 769 provider-edge interfaces in a manner that is specific to the provider 770 connections, and they autoconfigure their VET interfaces that were 771 configured over parent enterprise networks using the EBR 772 autoconfiguration procedures specified in Section 4.2. 774 For each of its VET interfaces configured over a child enterprise 775 network, the EBG initializes the interface the same as for an 776 ordinary EBR (see Section 4.2.1). It then arranges to add one or 777 more of its RLOCs associated with the child enterprise network to the 778 PRL. In particular, for each VET interface configured over a child 779 enterprise network the EBG adds the RLOCs to name service resource 780 records for 'PRLNAME'. 782 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 783 configured over child enterprise networks with a distributed 784 management structure. EBGs may also engage in an unspecified anycast 785 EBG discovery message exchange if they are configured to do so. 787 EBGs configure a DHCP relay/server on VET interfaces configured over 788 child enterprise networks that require DHCP services. 790 To avoid looping, EBGs MUST NOT configure a default route on a VET 791 interface configured over a child enterprise network interface. 793 4.4. VET Host Autoconfiguration 795 Nodes that cannot be attached via an EBR's enterprise-edge interface 796 (e.g., nomadic laptops that connect to a home office via a Virtual 797 Private Network (VPN)) can instead be configured for operation as a 798 simple host with a VET interface. Such VET hosts perform the same 799 VET interface initialization and EBG discovery procedures as 800 specified for EBRs in Section 4.2.1, but they configure their VET 801 interfaces as host interfaces (and not router interfaces). Note also 802 that a node may be configured as a host on some VET interfaces and as 803 an EBR/EBG on other VET interfaces. 805 A VET host may receive non-link-local addresses and/or prefixes to 806 assign to the VET interface via DHCP exchanges and/or through 807 information conveyed in Router Advertisements (RAs). If prefixes are 808 provided, however, there must be assurance that either 1) the VET 809 link will not partition, or 2) that each VET host interface connected 810 to the VET link will configure a unique set of prefixes. VET hosts 811 therefore depend on DHCP and/or RA exchanges to provide only 812 addresses/prefixes that are appropriate according to these specific 813 cases (i.e., shared prefixes vs. individual prefixes), and depend on 814 the EBGs within the enterprise keeping track of which addresses/ 815 prefixes were assigned to which hosts. 817 When the VET host solicits a DHCPv6-assigned address over an IPv6- 818 within-IPv4 NBMA VET interface, it maps the 819 'All_DHCP_Relay_Agents_and_Servers' IPv6 multicast destination 820 address to the IPv4 address of an EBG that it has selected as a 821 default router. The VET host then assigns any resulting DHCPv6- 822 delegated addresses to the VET interface for use as the source 823 address of inner packets. The host will subsqeuently send all 824 packets destined to IPv6 correspondents via its VET interface default 825 router, and will discover more-specific routes based on any redirect 826 messages it receives. 828 5. Internetworking Operation 830 Following the autoconfiguration procedures specified in Section 4, 831 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 832 operations as discussed in the following sections. 834 5.1. Routing Protocol Participation 836 ERs engage in any intra-enterprise routing protocols over enterprise- 837 interior interfaces to exchange routing information for forwarding IP 838 packets with RLOC addresses. EBRs and EBGs can additionally engage 839 in any inter-enterprise routing protocols over VET, enterprise-edge 840 and provider-edge interfaces to exchange routing information for 841 forwarding IP packets with EID addresses. Note that the EID-based 842 inter-enterprise IP routing domains are separate and distinct from 843 any RLOC-based enterprise interior IP routing domains. 845 Routing protocol participation on non-multicast VET interfaces uses 846 the NBMA interface model, e.g., in the same manner as for OSPF over 847 NBMA interfaces [RFC5340], while routing protocol participation on 848 multicast-capable VET interfaces uses the standard multicast 849 interface model. EBRs use the list of EBGs in the PRL (see: 850 Section 4.2.1) as an initial list of neighbors for inter-enterprise 851 routing protocol participation. 853 5.1.1. PI Prefix Routing Considerations 855 EBRs that connect large enterprise networks to the global Internet 856 advertise their EID PI prefixes directly into the Internet default- 857 free RIB via the Border Gateway Protocol (BGP) [RFC4271] the same as 858 for a major service provider network. EBRs that connect large 859 enterprise networks to provider networks can instead advertise their 860 EID PI prefixes into the providers' routing system(s) if the provider 861 networks are configured to accept them. 863 EBRs that connect small enterprise networks to provider networks 864 obtain one or more public IP address(es) (i.e., either EID or RLOC IP 865 address) then dynamically register the mapping of their PI prefixes 866 to the public IP address. The registrations are through secured end- 867 to-end exchanges between the EBR and a serving EBG in the PI prefix 868 vendor's network (e.g., through a vendor-specific short http(s) 869 transaction). The PI prefix vendor network then acts as a virtual 870 "home" enterprise network that connects its customer small enterprise 871 networks to the Internet routing system. The customer small 872 enterprise networks in turn appear as mobile components of the PI 873 prefix vendor's network, i.e., the customer networks are always "away 874 from home". 876 Further details on routing for PI prefixes is discussed in "The 877 Internet Routing Overlay Network (IRON)" [I-D.templin-iron] and "Fib 878 Suppression with Virtual Aggregation" [I-D.ietf-grow-va]. 880 5.2. Default Route Configuration and Selection 882 Configuration of default routes in the presence of VET interfaces 883 must be carefully coordinated according to the inner and outer 884 network protocols. If the inner and outer protocols are different 885 (e.g., IPv6 within IPv4) then default routes of the inner protocol 886 version can be configured with next-hops corresponding to default 887 routers on a VET interface while default routes of the outer protocol 888 version can be configured with next-hops corresponding to default 889 routers on an underlying interface. 891 If the inner and outer protocols are the same (e.g., IPv4 within 892 IPv4), care must be taken in setting the default route to avoid 893 ambiguity. For example, if default routes are configured on the VET 894 interface then more-specific routes could be configured on underlying 895 interfaces to avoid looping. In a preferred method, however, 896 multiple default routes can be configured with some having next-hops 897 corresponding to (EID-based) default routers on VET interfaces and 898 others having next-hops corresponding to (RLOC-based) default routers 899 on underlying interfaces. In that case, special next-hop 900 determination rules must be used (see: Section 5.4). 902 5.3. Address Selection 904 When permitted by policy and supported by enterprise interior 905 routing, VET nodes can avoid encapsulation through communications 906 that directly invoke the outer IP protocol using RLOC addresses 907 instead of EID addresses for end-to-end communications. For example, 908 an enterprise network that provides native IPv4 intra-enterprise 909 services can provide continued support for native IPv4 communications 910 even when encapsulated IPv6 services are available for inter- 911 enterprise communications. In other enterprise network scenarios, 912 the use of EID-based communications (i.e., instead of RLOC-based 913 communications) may be necessary and/or beneficial to support address 914 scaling, NAT traversal avoidance, security domain separation, site 915 multihoming, traffic engineering, etc. . 917 VET nodes can use source address selection rules (e.g., based on name 918 service information) to determine whether to use EID-based or RLOC- 919 based addressing. The remainder of this section discusses 920 internetworking operation for EID-based communications using the VET 921 interface abstraction. 923 5.4. Next Hop Determination 925 VET nodes perform normal next-hop determination via longest prefix 926 match, and send packets according to the most-specific matching entry 927 in the FIB. If the FIB entry has multiple next-hop addresses, the 928 EBR selects the next-hop with the best metric value. If multiple 929 next hops have the same metric value, the VET node can use Equal Cost 930 Multi Path (ECMP) to forward different flows via different next-hop 931 addresses, where flows are determined, e.g., by computing a hash of 932 the inner packet's source address, destination address and flow label 933 fields. 935 If the VET node has multiple default routes of the same inner and 936 outer protocol versions, with some corresponding to EID-based default 937 routers and others corresponding to RLOC-based default routers, it 938 must perform source address based selection of a default route. In 939 particular, if the packet's source address is taken from an EID 940 prefix the VET node selects a default route configured over the VET 941 interface; otherwise, it selects a default route configured over an 942 underlying interface. 944 As a last resort when there is no matching entry in the FIB (i.e., 945 not even default), VET nodes can discover next-hop addresses within 946 the enterprise network through on-demand name service queries for the 947 EID prefix taken from a packet's destination address (or, by some 948 other inner address to outer address mapping mechanism). For 949 example, for the IPv6 destination address '2001:DB8:1:2::1' and 950 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 951 service lookup for the domain name: 952 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 954 Name-service lookups in enterprise networks with a centralized 955 management structure use an infrastructure-based service, e.g., an 956 enterprise-local DNS. Name-service lookups in enterprise networks 957 with a distributed management structure and/or that lack an 958 infrastructure-based name service instead use LLMNR over the VET 959 interface. When LLMNR is used, the EBR that performs the lookup 960 sends an LLMNR query (with the prefix taken from the IP destination 961 address encoded in dotted-nibble format as shown above) and accepts 962 the union of all replies it receives from other EBRs on the VET 963 interface. When an EBR receives an LLMNR query, it responds to the 964 query IFF it aggregates an IP prefix that covers the prefix in the 965 query. If the name-service lookup succeeds, it will return RLOC 966 addresses (e.g., in DNS A records) that correspond to next-hop EBRs 967 to which the VET node can forward packets. 969 5.5. VET Interface Encapsulation/Decapsulation 971 VET interfaces encapsulate inner network layer packets in any 972 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 973 etc.) followed by a SEAL header (if necessary) followed by an outer 974 UDP header (if necessary) followed by an outer IP header. Following 975 all encapsulations, the VET interface submits the encapsulated packet 976 to the outer IP forwarding engine for transmission on an underlying 977 interface. The following sections provide further details on 978 encapsulation: 980 5.5.1. Inner Network Layer Protocol 982 The inner network layer protocol sees the VET interface as an 983 ordinary network interface, and views the outer network layer 984 protocol as an L2 transport. The inner- and outer network layer 985 protocol types are mutually independent and can be used in any 986 combination. Inner network layer protocol types include IPv6 987 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 988 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 990 5.5.2. Mid-Layer Encapsulation 992 VET interfaces that use mid-layer encapsulations encapsulate each 993 inner network layer packet in any mid-layer headers and trailers as 994 the first step in a potentially multi-layer encapsulation. 996 5.5.3. SEAL Encapsulation 998 Following any mid-layer encapsulations, VET interfaces that use SEAL 999 add a SEAL header as specified in [I-D.templin-intarea-seal]. 1000 Inclusion of a SEAL header MUST be applied uniformly between all 1001 nodes on the VET link. Note that when a VET interface sends a SEAL- 1002 encapsulated packet to a VET node that does not use SEAL 1003 encapsulation, it may receive an ICMP "port unreachable" or "protocol 1004 unreachable" depending on whether/not an outer UDP header is 1005 included. 1007 SEAL encapsulation is used on VET links that require path MTU 1008 mitigations due to encapsulation overhead and/or mechanisms for VET 1009 interface neighbor coordination. When SEAL encapsulation is used, 1010 the VET interface sets the 'Next Header' value in the SEAL header to 1011 the IP protocol number associated with either the mid-layer 1012 encapsulation or the IP protocol number of the inner network layer 1013 (if no mid-layer encapsulation is used). The VET interface sets the 1014 other fields in the SEAL header as specified in 1015 [I-D.templin-intarea-seal]. 1017 5.5.4. Outer UDP Header Encapsulation 1019 Following any mid-layer and/or SEAL encapsulations, VET interfaces 1020 that use UDP encapsulation add an outer UDP header. Inclusion of an 1021 outer UDP header must be applied uniformly between all nodes on the 1022 VET link. Note that when a VET interface sends a UDP-encapsulated 1023 packet to a node that does not recognize the UDP port number, it may 1024 receive an ICMP "port unreachable" message. 1026 VET interfaces use UDP encapsulation on VET links that may traverse 1027 Network Address Translators (NATs) and/or legacy networking gear that 1028 only recognizes certain network layer protocols, e.g., Equal Cost 1029 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc. 1030 When UDP encapsulation is used, the VET interface encapsulates the 1031 mid-layer packet in an outer UDP header then sets the UDP port 1032 numbers as specified for the outermost mid-layer protocol (e.g., 1033 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 1034 is used as the outermost mid-layer protocol, the VET interface sets 1035 the UDP source port number to a hash calculated over the inner 1036 network layer {destination, source} values or (optionally) over the 1037 inner network layer {dest addr, source addr, protocol, dest port, 1038 source port} values. The VET interface uses a hash function of its 1039 own choosing, but it MUST be consistent in the manner in which the 1040 hash is applied.. 1042 For VET links configured over IPv4 enterprise networks, the VET 1043 interface sets the UDP checksum field to zero. For VET links 1044 configured over IPv6 enterprise networks, considerations for setting 1045 the UDP checksum are discussed in [I-D.ietf-6man-udpzero]. 1047 5.5.5. Outer IP Header Encapsulation 1049 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1050 interface adds an outer IP header. Outer IP header construction is 1051 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1052 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1053 Service/Traffic Class" and "Congestion Experienced" values in the 1054 inner network layer header are copied into the corresponding fields 1055 in the outer IP header. The VET interface also sets the IP protocol 1056 number to the appropriate value for the first protocol layer within 1057 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1058 as the outer IP protocol, the VET interface sets the flow label value 1059 in the outer IPv6 header the same as described in 1060 [I-D.carpenter-flow-ecmp]. 1062 5.5.6. Decapsulation 1064 When a VET interface receives an encapsulated packet, it retains the 1065 outer headers and processes the SEAL header as specified in 1066 [I-D.templin-intarea-seal]. 1068 Next, if the packet will be forwarded from the receiving VET 1069 interface into a forwarding VET interface, the VET node copies the 1070 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1071 Experienced" values in the outer IP header received on the receiving 1072 VET interface into the corresponding fields in the outer IP header to 1073 be sent over the forwarding VET interface (i.e., the values are 1074 transferred between outer headers and *not* copied from the inner 1075 network layer header). This is true even if the packet is forwarded 1076 out the same VET interface that it arrived on, and necessary to 1077 support diagnostic functions (e.g., traceroute) and avoid looping. 1079 During decapsulation, when the next-hop is via a non-VET interface, 1080 the "Congestion Experienced" value in the outer IP header is copied 1081 into the corresponding field in the inner network layer header. 1083 5.6. Mobility and Multihoming Considerations 1085 EBRs that travel between distinct enterprise networks must either 1086 abandon their PA prefixes that are relative to the "old" enterprise 1087 and obtain PA prefixes relative to the "new" enterprise, or somehow 1088 coordinate with a "home" enterprise to retain ownership of the 1089 prefixes. In the first instance, the EBR would be required to 1090 coordinate a network renumbering event using the new PA prefixes 1091 [RFC4192][RFC5887]. In the second instance, an ancillary mobility 1092 management mechanism is required. 1094 EBRs can retain their PI prefixes as they travel between distinct 1095 enterprise networks as long as they update their PI prefix to public 1096 IP address mappings with their PI prefix vendors. This is 1097 accomplished by performing short transactions with EBGs in the PI 1098 prefix vendor network the same as specified in Section 5.1.1. In 1099 this way, EBRs can update their PI prefix to RLOC mappings in real 1100 time as their RLOCs change. 1102 The EBGs of a multihomed enterprise network participate in a private 1103 inner network layer routing protocol instance (possibly over an 1104 alternate topology) to accommodate network partitions/merges as well 1105 as intra-enterprise mobility events. 1107 5.7. Neighbor Coordination on VET Interfaces using SEAL 1109 VET interfaces that use SEAL use the SEAL Control Message Protocol 1110 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1111 coordinate reachability, routing information, and mappings between 1112 the inner and outer network layer protocols. SCMP directly parallels 1113 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1114 [RFC4443] protocols, but operates from within the tunnel and supports 1115 operation for any combinations of inner and outer network layer 1116 protocols. 1118 VET and SEAL are specifically designed for encapsulation of inner 1119 protocol payloads over IPv4 and IPv6 networks as a link layer. VET 1120 interfaces that use SCMP therefore require a new Source/Target Link- 1121 Layer Address Option (S/TLLAO) format that encapsulates IPv4 1122 addresses as shown in Figure 2 and IPv6 addresses as shown in 1123 Figure 3: 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Type = 2 | Length = 1 | Reserved | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | IPv4 address (bytes 0 thru 3) | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Figure 2: SCMP S/TLLAO Option for IPv4 RLOCs 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Type = 2 | Length = 3 | Reserved | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Reserved | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | IPv6 address (bytes 0 thru 3) | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | IPv6 address (bytes 4 thru 7) | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | IPv6 address (bytes 8 thru 11) | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | IPv6 address (bytes 12 thru 15) | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 Figure 3: SCMP S/TLLAO Option for IPv6 RLOCs 1153 In addition, VET interfaces that use SCMP use a modified version of 1154 the Route Information Option (RIO) (see: [RFC4191]) formatted as 1155 shown in Figure 4: 1157 0 1 2 3 1158 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Type = 24 | Length | Prefix Length | AF |Prf|Resvd| 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Route Lifetime | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Prefix (Variable Length) | 1165 . . 1166 . . 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Figure 4: SCMP Route Information Option Format 1171 In this modified format, the VET interface sets the Route Lifetime 1172 and Prefix fields in the RIO option the same as specified in 1174 [RFC4191]. It then sets the fields in the header as follows: 1176 o the 'Type', 'Length' and 'Prf' fields are set the same as 1177 specified in [RFC4191]. 1179 o the 'Resvd' field is set to 0. 1181 o the 'Length' field is set to 1, 2, or 3 as specified in [RFC4191]. 1182 It is instead set to 4 if the 'Prefix Length' is greater than 128 1183 and set to 5 if the 'Prefix Length' is greater than 192 in order 1184 to accommodate longer prefixes of non-IP protocols. 1186 o the 'Prefix Length' field ranges from 0 to 255. The 'Prefix' 1187 field is 0, 8, 16, 24 or 32 octets depending on the Length, and 1188 the embedded prefix MAY be up to 256 bits in length. (If the 1189 length is 256 bits, however the Prefix Length field encodes the 1190 value 0.) 1192 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1193 that indicates the embedded prefix protocol type. This document 1194 defines the following values for AF: 1196 * 000 - IPv4 1198 * 001 - IPv6 1200 * 010 - OSI/CLNP NSAP 1202 The following subsections discuss VET interface neighbor coordination 1203 using SCMP: 1205 5.7.1. Router Discovery 1207 VET hosts and EBRs can send SCMP Router Solicitation (SRS) messages 1208 to one or more EBGs in the PRL to receive solicited SCMP Router 1209 Advertisements (SRAs). 1211 When an EBG receives an SRS message on a VET interface, it prepares a 1212 solicited SRA message. The SRA includes Router Lifetimes, Default 1213 Router Preferences, PIOs and any other options/parameters that the 1214 EBG is configured to include. If necessary, the EBG also includes 1215 Route Information Options (RIOs) formatted as specified above. 1217 The EBG finally includes one or more SLLAOs formatted as specified 1218 above that encode the IPv6 and/or IPv4 RLOC unicast addresses of its 1219 own enterprise interior interfaces or the enterprise interior 1220 interfaces of other nearby EBGs. 1222 5.7.2. Neighbor Unreachability Detection 1224 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1225 interface neighbors by monitoring hints of forward progress as 1226 evidence that a neighbor is reachable. SEAL enables an explicit 1227 acknowledgement mechanism that can provide hints of forward progress. 1228 When data packets are flowing, the VET node can periodically set the 1229 A bit in the SEAL header of data packets to elicit SCMP responses 1230 from the neighbor. When no data packets are flowing, the VET node 1231 can send periodic probes such as SCMP Neighbor Solicitation (SNS) 1232 messages for the same purpose. 1234 Responsiveness to routing changes is directly related to the delay in 1235 detecting that a neighbor has gone unreachable. In order to provide 1236 responsiveness comparable to dynamic routing protocols, a reasonably 1237 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1239 Additionally, a VET node may receive outer IP ICMP "Destination 1240 Unreachable; net / host unreachable" messages from an ER on the path 1241 indicating that the path to a VET neighbor may be failing. The node 1242 SHOULD first check the packet-in-error to obtain reasonable assurance 1243 that the ICMP message is authentic. If the node receives excessive 1244 ICMP unreachable errors through multiple RLOCs associated with the 1245 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1246 packets to flow through a different route. 1248 5.7.3. Redirect Function 1250 A VET node (i.e., the redirectee) may receive a redirect message when 1251 it forwards packets over a VET interface to a neighboring VET node 1252 (i.e., the redirector). The redirector will forward the packet and 1253 return an SCMP Redirect message if necessary to inform the redirectee 1254 of a better next hop. 1256 The SCMP Redirect message is formatted the same as for ordinary 1257 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1258 the Destination and Target Address fields are unnecessary and 1259 therefore omitted. The format of the SCMP Redirect message is shown 1260 in Figure 5 1261 0 1 2 3 1262 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 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Type = 137 | Code = 0 | Checksum | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Reserved | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Options ... 1269 +-+-+-+-+-+-+-+-+-+-+-+- 1271 Figure 5: SCMP Redirect Message Format 1273 The redirector then adds any necessary Options to the Redirect 1274 message. It first includes one or more TLLAOs (see above) that 1275 include RLOCs corresponding to better next hops. The redirector next 1276 includes an RIO that contains a prefix from its FIB that covers the 1277 destination address of the original packet. 1279 Following the RIO option, the redirector includes any other necessary 1280 options (e.g., SEND options) followed by a Redirected Header option 1281 containing the leading portion of the packet that triggered the 1282 redirect as the final option in the message. The redirector then 1283 encapsulates the Redirect message the same as for any other SCMP 1284 message and sends it to the redirectee. 1286 When the redirectee receives the Redirect, it first authenticates the 1287 message (e.g.., by checking the SEAL_ID in the Redirected Header, 1288 etc.) then uses the EID prefix in the RIO with its respective 1289 lifetime to update its FIB. The redirectee also caches the IPv4 or 1290 IPv6 addresses in TLLAOs as the layer 2 addresses of potential next- 1291 hops for the prefix. 1293 The redirectee retains the FIB entry created as a result of receipt 1294 of an SCMP Redirect until the route lifetime expires, or until the 1295 redirected target neighbor becomes unreachable. In this way, RLOC 1296 liveness detection parallels IPv6 Neighbor Unreachability Detection. 1298 5.7.3.1. Correspondent Node Redirection 1300 When a mobile VET node moves to a new network point of attachment, it 1301 leaves short-term forwarding information with its former network 1302 point of attachment. Thereafter, any existing correspondents that 1303 attempt to contact the mobile node via the former network point of 1304 attachment will be redirected to the new network point of attachment. 1306 In this way, mobile VET nodes need not inform correspondents of a 1307 mobility event, since the correspondents will soon receive redirects 1308 from the network. 1310 5.8. Neighbor Coordination on VET Interfaces using IPsec 1312 VET interfaces that use IPsec encapsulation use the Internet Key 1313 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1314 association setup and maintenance. The IKEv2 can be seen as a 1315 logical equivalent of the SEAL SCMP in terms of VET interface 1316 neighbor coordinations. In particular, IKEv2 also provides 1317 mechanisms for redirection [RFC5685] and mobility [RFC4555]. 1319 IPsec additionally provides an extended Identification field and 1320 integrity check vector; these features allow IPsec to utilize outer 1321 IP fragmentation and reassembly with less risk of exposure to data 1322 corruption due to reassembly misassociations. On the other hand, 1323 IPsec entails the use of symmetric security associations and hence 1324 may not be appropriate to all enterprise network use cases. 1326 5.9. Multicast 1328 In multicast-capable deployments, ERs provide an enterprise-wide 1329 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1330 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1331 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1332 over their enterprise-interior interfaces such that outer IP 1333 multicast messages of site-scope or greater scope will be propagated 1334 across the enterprise network. For such deployments, VET nodes can 1335 also provide an inner multicast/broadcast capability over their VET 1336 interfaces through mapping of the inner multicast address space to 1337 the outer multicast address space. In that case, operation of link- 1338 scoped (or greater scoped) inner multicasting services (e.g., a link- 1339 scoped neighbor discovery protocol) over the VET interface is 1340 available, but should be used sparingly to minimize enterprise-wide 1341 flooding. 1343 VET nodes encapsulate inner multicast messages sent over the VET 1344 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1345 followed by an outer IP header with a site-scoped outer IP multicast 1346 address as the destination. For the case of IPv6 and IPv4 as the 1347 inner/outer protocols (respectively), [RFC2529] provides mappings 1348 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1349 address space (for other encapsulations, mappings are established 1350 through administrative configuration or through an unspecified 1351 alternate static mapping). 1353 Multicast mapping for inner multicast groups over outer IP multicast 1354 groups can be accommodated, e.g., through VET interface snooping of 1355 inner multicast group membership and routing protocol control 1356 messages. To support inner-to-outer multicast address mapping, the 1357 VET interface acts as a virtual outer IP multicast host connected to 1358 its underlying interfaces. When the VET interface detects that an 1359 inner multicast group joins or leaves, it forwards corresponding 1360 outer IP multicast group membership reports on an underlying 1361 interface over which the VET interface is configured. If the VET 1362 node is configured as an outer IP multicast router on the underlying 1363 interfaces, the VET interface forwards locally looped-back group 1364 membership reports to the outer IP multicast routing process. If the 1365 VET node is configured as a simple outer IP multicast host, the VET 1366 interface instead forwards actual group membership reports (e.g., 1367 IGMP messages) directly over an underlying interface. 1369 Since inner multicast groups are mapped to site-scoped outer IP 1370 multicast groups, the VET node MUST ensure that the site-scope outer 1371 IP multicast messages received on the underlying interfaces for one 1372 VET interface do not "leak out" to the underlying interfaces of 1373 another VET interface. This is accommodated through normal site- 1374 scoped outer IP multicast group filtering at enterprise network 1375 boundaries. 1377 5.10. Service Discovery 1379 VET nodes can perform enterprise-wide service discovery using a 1380 suitable name-to-address resolution service. Examples of flooding- 1381 based services include the use of LLMNR [RFC4795] over the VET 1382 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1383 over an underlying interface. More scalable and efficient service 1384 discovery mechanisms (e.g., anycast) are for further study. 1386 5.11. Enterprise Network Partitioning 1388 An enterprise network can be partitioned into multiple distinct 1389 logical groupings. In that case, each partition configures its own 1390 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1391 'isatapv2.zone2.example.com', etc.). 1393 EBGs can further create multiple IP subnets within a partition, e.g., 1394 by sending RAs with PIOs containing different IP prefixes to 1395 different groups of VET hosts. EBGs can identify subnets, e.g., by 1396 examining RLOC prefixes, observing the enterprise interior interfaces 1397 over which RSs are received, etc. 1399 In the limiting case, EBGs can advertise a unique set of IP prefixes 1400 to each VET host such that each host belongs to a different subnet 1401 (or set of subnets) on the VET interface. 1403 5.12. EBG Prefix State Recovery 1405 EBGs retain explicit state that tracks the inner PA prefixes 1406 delegated to EBRs within the enterprise network, e.g., so that 1407 packets are delivered to the correct EBRs. When an EBG loses some or 1408 all of its state (e.g., due to a power failure), it must recover the 1409 state so that packets can be forwarded over correct routes. 1411 5.13. Support for Legacy ISATAP Services 1413 EBGs support legacy ISATAP services according to the specifications 1414 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1415 interfaces and VET interfaces over the same sets of underlying 1416 interfaces as long as the PRLs and IPv6 prefixes associated with the 1417 ISATAP/VET interfaces are distinct. 1419 Legacy ISATAP hosts aquire addresses and/or prefixes in the same 1420 manner and using the same mechanisms as described for VET hosts in 1421 Section 4.4 above. 1423 6. IANA Considerations 1425 There are no IANA considerations for this document. 1427 7. Security Considerations 1429 Security considerations for MANETs are found in [RFC2501]. 1431 The security considerations found in 1432 [RFC2529][RFC5214][I-D.nakibly-v6ops-tunnel-loops] also apply to VET. 1434 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1435 where attacks on the neighbor coordination protocol are possible. 1436 SEAL [I-D.templin-intarea-seal] provides a per-packet identification 1437 that can be used to detect source address spoofing. 1439 Rogue neighbor coordination messages with spoofed RLOC source 1440 addresses can consume network resources and cause VET nodes to 1441 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1442 such RLOCs, as that may result in a denial of service to the RLOCs' 1443 legitimate owners. 1445 VET EBRs and EBGs observe the recommendations for network ingress 1446 filtering [RFC2827]. 1448 8. Related Work 1450 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1451 automatic tunneling in [RFC2529]; this concept was later called: 1452 "Virtual Ethernet" and investigated by Quang Nguyen under the 1453 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1454 their colleagues have motivated a number of foundational concepts on 1455 which this work is based. 1457 Telcordia has proposed DHCP-related solutions for MANETs through the 1458 CECOM MOSAIC program. 1460 The Naval Research Lab (NRL) Information Technology Division uses 1461 DHCP in their MANET research testbeds. 1463 Security concerns pertaining to tunneling mechanisms are discussed in 1464 [I-D.ietf-v6ops-tunnel-security-concerns]. 1466 Default router and prefix information options for DHCPv6 are 1467 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1469 An automated IPv4 prefix delegation mechanism is proposed in 1470 [I-D.ietf-dhc-subnet-alloc]. 1472 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1473 [I-D.clausen-manet-autoconf-recommendations]. 1475 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1477 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1478 decapsulation issues and other aspects of tunneling. 1480 Various proposals within the IETF have suggested similar mechanisms. 1482 9. Acknowledgements 1484 The following individuals gave direct and/or indirect input that was 1485 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1486 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1487 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1488 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1489 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1490 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1491 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1492 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1493 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1494 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1495 working groups. Many others have provided guidance over the course 1496 of many years. 1498 10. Contributors 1500 The following individuals have contributed to this document: 1502 Eric Fleischman (eric.fleischman@boeing.com) 1503 Thomas Henderson (thomas.r.henderson@boeing.com) 1504 Steven Russert (steven.w.russert@boeing.com) 1505 Seung Yi (seung.yi@boeing.com) 1507 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1508 of the document. 1510 Jim Bound's foundational work on enterprise networks provided 1511 significant guidance for this effort. We mourn his loss and honor 1512 his contributions. 1514 11. References 1516 11.1. Normative References 1518 [I-D.templin-intarea-seal] 1519 Templin, F., "The Subnetwork Encapsulation and Adaptation 1520 Layer (SEAL)", draft-templin-intarea-seal-24 (work in 1521 progress), November 2010. 1523 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1524 September 1981. 1526 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1527 RFC 792, September 1981. 1529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1530 Requirement Levels", BCP 14, RFC 2119, March 1997. 1532 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1533 RFC 2131, March 1997. 1535 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1536 (IPv6) Specification", RFC 2460, December 1998. 1538 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1539 Defeating Denial of Service Attacks which employ IP Source 1540 Address Spoofing", BCP 38, RFC 2827, May 2000. 1542 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1543 and M. Carney, "Dynamic Host Configuration Protocol for 1544 IPv6 (DHCPv6)", RFC 3315, July 2003. 1546 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1547 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1548 December 2003. 1550 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1551 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1553 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1554 RFC 3972, March 2005. 1556 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1557 More-Specific Routes", RFC 4191, November 2005. 1559 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1560 Architecture", RFC 4291, February 2006. 1562 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1563 Message Protocol (ICMPv6) for the Internet Protocol 1564 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1566 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1567 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1568 September 2007. 1570 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1571 Address Autoconfiguration", RFC 4862, September 2007. 1573 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1574 for IEEE 802 Parameters", BCP 141, RFC 5342, 1575 September 2008. 1577 11.2. Informative References 1579 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1580 Switching Networks", May 1974. 1582 [I-D.carpenter-flow-ecmp] 1583 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1584 for equal cost multipath routing and link aggregation in 1585 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 1586 October 2010. 1588 [I-D.cheshire-dnsext-multicastdns] 1589 Cheshire, S. and M. Krochmal, "Multicast DNS", 1590 draft-cheshire-dnsext-multicastdns-12 (work in progress), 1591 October 2010. 1593 [I-D.clausen-manet-autoconf-recommendations] 1594 Clausen, T. and U. Herberg, "MANET Router Configuration 1595 Recommendations", 1596 draft-clausen-manet-autoconf-recommendations-00 (work in 1597 progress), February 2009. 1599 [I-D.clausen-manet-linktype] 1600 Clausen, T., "The MANET Link Type", 1601 draft-clausen-manet-linktype-00 (work in progress), 1602 October 2008. 1604 [I-D.droms-dhc-dhcpv6-default-router] 1605 Droms, R. and T. Narten, "Default Router and Prefix 1606 Advertisement Options for DHCPv6", 1607 draft-droms-dhc-dhcpv6-default-router-00 (work in 1608 progress), March 2009. 1610 [I-D.ietf-6man-udpzero] 1611 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 1612 Considerations", draft-ietf-6man-udpzero-02 (work in 1613 progress), October 2010. 1615 [I-D.ietf-dhc-subnet-alloc] 1616 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1617 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1618 (work in progress), May 2010. 1620 [I-D.ietf-grow-va] 1621 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1622 L. Zhang, "FIB Suppression with Virtual Aggregation", 1623 draft-ietf-grow-va-03 (work in progress), August 2010. 1625 [I-D.ietf-lisp] 1626 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1627 "Locator/ID Separation Protocol (LISP)", 1628 draft-ietf-lisp-09 (work in progress), October 2010. 1630 [I-D.ietf-manet-smf] 1631 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1632 draft-ietf-manet-smf-10 (work in progress), March 2010. 1634 [I-D.ietf-v6ops-tunnel-security-concerns] 1635 Krishnan, S., Thaler, D., and J. Hoagland, "Security 1636 Concerns With IP Tunneling", 1637 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 1638 progress), October 2010. 1640 [I-D.jen-apt] 1641 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1642 L. Zhang, "APT: A Practical Transit Mapping Service", 1643 draft-jen-apt-01 (work in progress), November 2007. 1645 [I-D.nakibly-v6ops-tunnel-loops] 1646 Nakibly, G. and F. Templin, "Routing Loop Attack using 1647 IPv6 Automatic Tunnels: Problem Statement and Proposed 1648 Mitigations", draft-nakibly-v6ops-tunnel-loops-03 (work in 1649 progress), August 2010. 1651 [I-D.russert-rangers] 1652 Russert, S., Fleischman, E., and F. Templin, "RANGER 1653 Scenarios", draft-russert-rangers-05 (work in progress), 1654 July 2010. 1656 [I-D.templin-iron] 1657 Templin, F., "The Internet Routing Overlay Network 1658 (IRON)", draft-templin-iron-13 (work in progress), 1659 October 2010. 1661 [I-D.templin-isatap-dhcp] 1662 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1663 Option for the Intra-Site Automatic Tunnel Addressing 1664 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1665 progress), December 2009. 1667 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1668 July 1978. 1670 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1671 Protocol Specification", October 2008. 1673 [RFC0994] International Organization for Standardization (ISO) and 1674 American National Standards Institute (ANSI), "Final text 1675 of DIS 8473, Protocol for Providing the Connectionless- 1676 mode Network Service", RFC 994, March 1986. 1678 [RFC1035] Mockapetris, P., "Domain names - implementation and 1679 specification", STD 13, RFC 1035, November 1987. 1681 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1682 a subnetwork for experimentation with the OSI network 1683 layer", RFC 1070, February 1989. 1685 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1686 Communication Layers", STD 3, RFC 1122, October 1989. 1688 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1689 Routing and Addressing Architecture", RFC 1753, 1690 December 1994. 1692 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1693 E. Lear, "Address Allocation for Private Internets", 1694 BCP 5, RFC 1918, February 1996. 1696 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1697 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1699 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1700 October 1996. 1702 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1703 Extensions", RFC 2132, March 1997. 1705 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1706 IPv6 Specification", RFC 2473, December 1998. 1708 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1709 over Non-Broadcast Multiple Access (NBMA) networks", 1710 RFC 2491, January 1999. 1712 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1713 (MANET): Routing Protocol Performance Issues and 1714 Evaluation Considerations", RFC 2501, January 1999. 1716 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1717 Domains without Explicit Tunnels", RFC 2529, March 1999. 1719 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1720 February 2000. 1722 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1723 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1724 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1725 RFC 3819, July 2004. 1727 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1728 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1729 May 2005. 1731 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1732 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1733 January 2005. 1735 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1736 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1737 RFC 3948, January 2005. 1739 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1740 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1741 September 2005. 1743 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1744 Addresses", RFC 4193, October 2005. 1746 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1747 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1749 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1750 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1752 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1753 Internet Protocol", RFC 4301, December 2005. 1755 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1756 RFC 4306, December 2005. 1758 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1759 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1760 May 2006. 1762 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1763 (MOBIKE)", RFC 4555, June 2006. 1765 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1766 Multicast Name Resolution (LLMNR)", RFC 4795, 1767 January 2007. 1769 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1770 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1771 Focus", RFC 4852, April 2007. 1773 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1774 June 2007. 1776 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1777 Extensions for Stateless Address Autoconfiguration in 1778 IPv6", RFC 4941, September 2007. 1780 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1781 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1782 March 2008. 1784 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1785 for IPv6", RFC 5340, July 2008. 1787 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1788 Infrastructures (6rd)", RFC 5569, January 2010. 1790 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1791 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1792 RFC 5685, November 2009. 1794 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1795 Global Enterprise Recursion (RANGER)", RFC 5720, 1796 February 2010. 1798 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1799 Still Needs Work", RFC 5887, May 2010. 1801 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1802 Infrastructures (6rd) -- Protocol Specification", 1803 RFC 5969, August 2010. 1805 Appendix A. Duplicate Address Detection (DAD) Considerations 1807 A priori uniqueness determination (also known as "pre-service DAD") 1808 for an RLOC assigned on an enterprise-interior interface would 1809 require either flooding the entire enterprise network or somehow 1810 discovering a link in the network on which a node that configures a 1811 duplicate address is attached and performing a localized DAD exchange 1812 on that link. But, the control message overhead for such an 1813 enterprise-wide DAD would be substantial and prone to false-negatives 1814 due to packet loss and intermittent connectivity. An alternative to 1815 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1816 enterprise-interior interfaces and employ a passive in-service DAD 1817 (e.g., one that monitors routing protocol messages for duplicate 1818 assignments). 1820 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1821 CGAs, IPv6 privacy addresses, etc. with very small probability of 1822 collision. Pseudo-random IPv4 RLOCs can be generated through random 1823 assignment from a suitably large IPv4 prefix space. 1825 Consistent operational practices can assure uniqueness for EBG- 1826 aggregated addresses/prefixes, while statistical properties for 1827 pseudo-random address self-generation can assure uniqueness for the 1828 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1829 RLOC delegation authority should be used when available, while a 1830 passive in-service DAD mechanism should be used to detect RLOC 1831 duplications when there is no RLOC delegation authority. 1833 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1835 For each distinct enterprise network that it connects to, an EBR 1836 configures a VET interface over possibly multiple underlying 1837 interfaces that all connect to the same network. The VET interface 1838 therefore represents the EBR's logical point of attachment to the 1839 enterprise network, and provides a logical interface for link-layer 1840 multiplexing over its underlying interfaces as described in Section 1841 3.3.4 of [RFC1122]: 1843 "Finally, we note another possibility that is NOT multihoming: one 1844 logical interface may be bound to multiple physical interfaces, in 1845 order to increase the reliability or throughput between directly 1846 connected machines by providing alternative physical paths between 1847 them. For instance, two systems might be connected by multiple 1848 point-to-point links. We call this "link-layer multiplexing". 1849 With link-layer multiplexing, the protocols above the link layer 1850 are unaware that multiple physical interfaces are present; the 1851 link-layer device driver is responsible for multiplexing and 1852 routing packets across the physical interfaces." 1854 EBRs can support such a link-layer multiplexing capability across the 1855 enterprise network in accordance with the Weak End System Model (see 1856 Section 3.3.4 of [RFC1122]). In particular, when an EBR 1857 autoconfigures an RLOC address, it can associate it with the VET 1858 interface only instead of assigning it to an underlying interface. 1859 The EBR therefore only needs to obtain a single RLOC address even if 1860 there are multiple underlying interfaces, i.e., it does not need to 1861 obtain one for each underlying interface. The EBR can then leave the 1862 underlying interfaces unnumbered, or it can configure a randomly 1863 chosen IP link-local address (e.g., from the prefix 169.254/16 1864 [RFC3927] for IPv4) on underlying interfaces that require a 1865 configuration. The EBR need not check these link-local addresses for 1866 uniqueness within the enterprise network, as they will not normally 1867 be used as the source address for packets. 1869 When the EBR engages in the enterprise-interior routing protocol, it 1870 uses the RLOC address assigned to the VET interface as the source 1871 address for all routing protocol control messages, however it must 1872 also supply an interface identifier (e.g., a small integer) that 1873 uniquely identifies the underlying interface that the control message 1874 is sent over. For example, if the underlying interfaces are known as 1875 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1876 sends a routing protocol control message over the "eth7" interface. 1877 This is necessary to ensure that other routers can determine the 1878 specific interface over which the EBR's routing protocol control 1879 message was sent, but the token need only be unique within the EBR 1880 itself and need not be unique throughout the enterprise network. 1882 When the EBR discovers an RLOC route via the enterprise interior 1883 routing protocol, it configures a preferred route in the IP FIB that 1884 points to the VET interface instead of the underlying interface. At 1885 the same time, the EBR also configures an ancillary route that points 1886 to the underlying interface. If the EBR discovers that the same RLOC 1887 route is reachable via multiple underlying interfaces, it configures 1888 multiple ancillary routes (i.e., one for each interface). If the EBR 1889 discovers that the RLOC route is no longer reachable via any 1890 underlying interface, it removes the route in the IP FIB that points 1891 to the VET interface. 1893 With these arrangements, all locally-generated packets with RLOC 1894 destinations will flow through the VET interface (and thereby use the 1895 VET interface's RLOC address as the source address) instead of 1896 through the underlying interfaces. In the same fashion, all 1897 forwarded packets with RLOC destinations will flow through the VET 1898 interface instead of through the underlying interfaces. 1900 This arrangement has several operational advantages that enable a 1901 number of traffic engineering capabilities when SEAL encapsulation is 1902 also used. First, the VET interface can insert the SEAL header so 1903 that ID-based duplicate packet detection is enabled within the 1904 enterprise network. Secondly, SEAL can dynamically adjust its packet 1905 sizing parameters so that an optimum Maximum Transmission Unit (MTU) 1906 can be determined. This is true even if the VET interface reroutes 1907 traffic between underlying interfaces with different MTUs. 1909 Most importantly, the EBR can configure default and more-specific 1910 routes on the VET interface to direct traffic through a specific 1911 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1912 will ensure that a specific eEBR is chosen, and the best eEBR can be 1913 chosen when multiple are available. Also, local applications see a 1914 stable IP source address even if there are multiple underlying 1915 interfaces. This link-layer multiplexing can therefore provide 1916 continuous operation across failovers between multiple links attached 1917 to the same enterprise network without any need for readdressing. 1918 Finally, the VET interface can forward packets with RLOC-based 1919 destinations over an underlying interface without any encapsulation 1920 if encapsulation avoidance is desired. 1922 It must be specifically noted that the above arrangement constitutes 1923 a case in which the same RLOC may be used as both the inner and outer 1924 IP source address. This will not present a problem as long as both 1925 ends configure a VET interface in the same fashion. 1927 It must also be noted that EID-based communications can use the same 1928 VET interface arrangement, except that the EID-based next hop must be 1929 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1930 within IPvX encapsulation, as well as for IPv4 within IPv6 1931 encapsulation, this requires a VET interface specific address mapping 1932 database. For IPv6 within IPv4 encapsulation, the mapping is 1933 accomplished through simple static extraction of an IPv4 address 1934 embedded within the IPv6 address. 1936 Appendix C. Anycast Services 1938 Some of the IPv4 addresses that appear in the Potential Router List 1939 may be anycast addresses, i.e., they may be configured on the VET 1940 interfaces of multiple EBRs/EBGs. In that case, each VET router 1941 interface that configures the same anycast address must provide 1942 equivalent packet forwarding and neighbor discovery services. 1944 Use of an anycast address as the IP destination address of tunneled 1945 packets can have subtle interactions with tunnel path MTU and 1946 neighbor discovery. For example, if the initial fragments of a 1947 fragmented tunneled packet with an anycast IP destination address are 1948 routed to different egress tunnel endpoints than the remaining 1949 fragments, the multiple endpoints will be left with incomplete 1950 reassembly buffers. This issue can be mitigated by ensuring that 1951 each egress tunnel endpoint implements a proactive reassembly buffer 1952 garbage collection strategy. Additionally, ingress tunnel endpoints 1953 that send packets with an anycast IP destination address must use the 1954 minimum path MTU for all egress tunnel endpoints that configure the 1955 same anycast address as the tunnel MTU. Finally, ingress tunnel 1956 endpoints should treat ICMP unreachable messages from a router within 1957 the tunnel as at most a weak indication of neighbor unreachability, 1958 since the failures may only be transient and a different path to an 1959 alternate anycast router quickly selected through reconvergence of 1960 the underlying routing protocol. 1962 Use of an anycast address as the IP source address of tunneled 1963 packets can lead to more serious issues. For example, when the IP 1964 source address of a tunneled packet is anycast, ICMP messages 1965 produced by routers within the tunnel might be delivered to different 1966 ingress tunnel endpoints than the ones that produced the packets. In 1967 that case, functions such as path MTU discovery and neighbor 1968 unreachability detection may experience non-deterministic behavior 1969 that can lead to communications failures. Additionally, the 1970 fragments of multiple tunneled packets produced by multiple ingress 1971 tunnel endpoints may be delivered to the same reassembly buffer at a 1972 single egress tunnel endpoint. In that case, data corruption may 1973 result due to fragment misassociation during reassembly. 1975 In view of these considerations, EBRs/EBGs that configure an anycast 1976 address should also configure one or more unicast addresses from the 1977 Potential Router List; they should further accept tunneled packets 1978 destined to any of their anycast or unicast addresses, but should 1979 send tunneled packets using a unicast address as the source address. 1980 In order to influence traffic to use an anycast route (and thereby 1981 leverage the natural fault tolerance afforded by anycast), ISATAP 1982 routers should set higher preferences on the default routes they 1983 advertise using an anycast address as the source and set lower 1984 preferences on the default routes they advertise using a unicast 1985 address as the source (see: [RFC4191]). 1987 Appendix D. Change Log 1989 (Note to RFC editor - this section to be removed before publication 1990 as an RFC.) 1992 Changes from -14 to -15: 1994 o new insights into default route configuration and next-hop 1995 determination 1997 Changes from -13 to -14: 1999 o fixed Idnits 2001 Changes from -12 to -13: 2003 o Changed "VGL" *back* to "PRL" 2005 o More changes for multi-protocol support 2007 o Changes to Redirect function 2009 Changes from -11 to -12: 2011 o Major section rearrangement 2013 o Changed "PRL" to "VGL" 2015 o Brought back text that was lost in the -10 to -11 transition 2017 Changes from -10 to -11: 2019 o Major changes with significant simplifications 2020 o Now support stateless PD using 6rd mechanisms 2022 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2024 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2026 Changes from -09 to -10: 2028 o Changed "enterprise" to "enterprise network" throughout 2030 o dropped "inner IP", since inner layer may be non-IP 2032 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2033 messages remain *within* the tunnel interface instead of being 2034 exposed to the inner network layer protocol engine. 2036 Changes from -08 to -09: 2038 o Expanded discussion of encapsulation/decapsulation procedures 2040 o cited IRON 2042 Changes from -07 to -08: 2044 o Specified the approach to global mapping using virtual aggregation 2045 and BGP 2047 Changes from -06 to -07: 2049 o reworked redirect function 2051 o created new section on VET interface encapsulation 2053 o clarifications on nexthop selection 2055 o fixed several bugs 2057 Changed from -05 to -06: 2059 o reworked VET interface ND 2061 o anycast clarifications 2063 Changes from -03 to -04: 2065 o security consideration clarifications 2067 Changes from -02 to -03: 2069 o security consideration clarifications 2071 o new PRLNAME for VET is "isatav2.example.com" 2073 o VET now uses SEAL natively 2075 o EBGs can support both legacy ISATAP and VET over the same 2076 underlying interfaces. 2078 Changes from -01 to -02: 2080 o Defined CGA and privacy address configuration on VET interfaces 2082 o Interface identifiers added to routing protocol control messages 2083 for link-layer multiplexing 2085 Changes from -00 to -01: 2087 o Section 4.1 clarifications on link-local assignment and RLOC 2088 autoconfiguration. 2090 o Appendix B clarifications on Weak End System Model 2092 Changes from RFC5558 to -00: 2094 o New appendix on RLOC configuration on VET interfaces. 2096 Author's Address 2098 Fred L. Templin (editor) 2099 Boeing Research & Technology 2100 P.O. Box 3707 MC 7L-49 2101 Seattle, WA 98124 2102 USA 2104 Email: fltemplin@acm.org