idnits 2.17.1 draft-templin-intarea-vet-18.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 3, 2010) is 4894 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 3, 2010 5 Expires: June 6, 2011 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-18.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 6, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 32 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. 623 However, link-local address configuration for other inner/outer 624 protocol combinations may not be necessary if a non-link-local 625 address can be configured through other means (e.g., administrative 626 configuration, DHCP, etc.). 628 The EBR next discovers a Potential Router List (PRL) that includes 629 the RLOC addresses of EBGs. The PRL names the VET interface, and is 630 specific to the address family of the inner network layer protocol 631 (e.g., IPv4, IPv6, OSI, etc.). If there are multiple address 632 families, then there will be multiple VET interfaces; each with its 633 own PRL. 635 The PRL can be discovered through information conveyed in the 636 enterprise-interior routing protocol, through a DHCP option 637 [I-D.templin-isatap-dhcp], an unspecified anycast EBG discovery 638 message exchange, etc. In multicast-capable enterprise networks, 639 EBRs can also listen for advertisements on the 'rasadv' [RASADV] 640 multicast group address. 642 Whether or not other information is available, the EBR can resolve an 643 identifying name for the PRL ('PRLNAME') formed as 644 'hostname.domainname', where 'hostname' is an enterprise-specific 645 name string and 'domainname' is an enterprise-specific Domain Name 646 System (DNS) suffix [RFC1035]. The EBR discovers 'PRLNAME' through 647 manual configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 648 protocol advertisements, link-layer information (e.g., an IEEE 802.11 649 Service Set Identifier (SSID)), or through some other means specific 650 to the enterprise network. The EBR can also obtain 'PRLNAME' as part 651 of an arrangement with a private-sector PI prefix vendor (see: 652 Section 4.2.3). 654 In the absence of other information, the EBR sets the 'hostname' 655 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 656 component to an enterprise-specific DNS suffix (e.g., "example.com"). 657 Isolated enterprise networks that do not connect to the outside world 658 may have no enterprise-specific DNS suffix, in which case the 659 'PRLNAME' consists only of the 'hostname' component. (Note that the 660 default hostname "isatapv2" is intentionally distinct from the 661 convention specified in [RFC5214].) 663 After discovering 'PRLNAME', the EBR resolves the name into a list of 664 RLOC addresses through a name service lookup. For centrally managed 665 enterprise networks, the EBR resolves 'PRLNAME' using an enterprise- 666 local name service (e.g., the DNS). For enterprises with no 667 centralized management structure, the EBR resolves 'PRLNAME' using 668 Link-Local Multicast Name Resolution (LLMNR) [RFC4795] over the VET 669 interface. In that case, all EBGs in the PRL respond to the LLMNR 670 query, and the EBR accepts the union of all responses. 672 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 674 EBRs that connect their enterprise networks to a provider network 675 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 676 stateless autoconfiguration mechanisms. The stateful and stateless 677 approaches are discussed in the following subsections. 679 4.2.2.1. Stateful Prefix Delegation 681 For IPv4, EBRs acquire IPv4 PA EID prefixes via an automated IPv4 682 prefix delegation exchange, explicit management, etc. 684 For IPv6, EBRs acquire IPv6 PA EID prefixes via DHCPv6 Prefix 685 Delegation exchanges with an EBG acting as a DHCP relay/server. In 686 particular, the EBR (acting as a requesting router) can use DHCPv6 687 prefix delegation [RFC3633] over the VET interface to obtain prefixes 688 from the server (acting as a delegating router). The EBR obtains 689 prefixes using either a 2-message or 4-message DHCPv6 exchange 690 [RFC3315]. For example, to perform the 2-message exchange, the EBR's 691 DHCPv6 client forwards a Solicit message with an IA_PD option to its 692 DHCPv6 relay, i.e., the EBR acts as a combined client/relay (see 693 Section 4.1). The relay then forwards the message over the VET 694 interface using VET encapsulation (see: Section 5.4) to an EBG which 695 either services the request or relays it further. The forwarded 696 Solicit message will elicit a reply from the server containing prefix 697 delegations. The EBR can also propose a specific prefix to the 698 DHCPv6 server per Section 7 of [RFC3633]. The server will check the 699 proposed prefix for consistency and uniqueness, then return it in the 700 reply to the EBR if it was able to perform the delegation. 702 After the EBR receives IPv4 and/or IPv6 prefix delegations, it can 703 provision the prefixes on enterprise-edge interfaces as well as on 704 other VET interfaces configured over child enterprise networks for 705 which it acts as an EBG. The EBR can also provision the prefixes on 706 enterprise-interior interfaces to service any hosts attached to the 707 link. 709 The prefix delegations remain active as long as the EBR continues to 710 renew them via the delegating EBG before lease lifetimes expire. The 711 lease lifetime also keeps the delegation state active even if 712 communications between the EBR and delegating EBG are disrupted for a 713 period of time (e.g., due to an enterprise network partition, power 714 failure, etc.). Note however that if the EBR abandons or otherwise 715 loses continuity with the prefixes, it may be obliged to perform 716 network-wide renumbering if it subsequently receives a new and 717 different set of prefixes. 719 Stateful prefix delegation for non-IP protocols is out of scope. 721 4.2.2.2. Stateless Prefix Delegation 723 When IPv6 and IPv4 are used as the inner and outer protocols, 724 respectively, a stateless IPv6 PA prefix delegation capability is 725 available using the mechanisms specified in [RFC5569][RFC5969]. EBRs 726 can use these mechanisms to statelessly configure IPv6 PA prefixes 727 that embed one of the EBR's IPv4 RLOCs. 729 Using this stateless prefix delegation, if the IPv4 RLOC changes the 730 IPv6 prefix also changes and the EBR is obliged to renumber any 731 interfaces on which sub-prefixes from the delegated prefix are 732 assigned. This method may therefore be most suitable for enterprise 733 networks in which IPv4 RLOC assignments rarely change, or in 734 enterprise networks in which only services that do not depend on a 735 long-term stable IPv6 prefix (e.g., client-side web browsing) are 736 used. 738 Stateless prefix delegation for other protocol combinations is out of 739 scope. 741 4.2.3. Provider-(In)dependent (PI) EID Prefix Autoconfiguration 743 EBRs can acquire Provider (In)dependent (PI) prefixes to facilitate 744 multihoming, mobility and traffic engineering without requiring site- 745 wide renumbering events. These PI prefixes are made available to 746 EBRs through a prefix registration authority that may or may not be 747 associated with a specific ISP. 749 EBRs that connect major enterprise networks (e.g., large 750 corporations, academic campuses, ISP networks, etc.) to a parent 751 enterprise network and/or the global Internet can acquire short PI 752 prefixes (e.g., an IPv6 ::/20, an IPv4 /16, etc.) through a 753 registration authority such as the Internet Assigned Numbers 754 Authority (IANA) or a major regional Internet registry. EBRs that 755 connect small enterprise networks (e.g., SOHO networks, MANETs, etc.) 756 to a parent enterprise network can acquire longer PI prefixes through 757 arrangements with a PI prefix commercial vendor organization. 759 After an EBR receives PI prefixes, it can sub-delegate portions of 760 the prefixes on enterprise-edge interfaces, on other VET interfaces 761 for which it is configured as an EBG and on enterprise-interior 762 interfaces to service any hosts attached to the link. The EBR can 763 also sub-delegate portions of its PI prefixes to requesting routers 764 within child enterprise networks. These requesting routers consider 765 their sub-delegated portions of the PI prefix as PA, and consider the 766 delegating routers as their points of connection to a provider 767 network. 769 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 771 EBGs are EBRs that connect child enterprise networks to provider 772 networks via provider-edge interfaces and/or via VET interfaces 773 configured over parent enterprise networks. EBGs autoconfigure their 774 provider-edge interfaces in a manner that is specific to the provider 775 connections, and they autoconfigure their VET interfaces that were 776 configured over parent enterprise networks using the EBR 777 autoconfiguration procedures specified in Section 4.2. 779 For each of its VET interfaces configured over a child enterprise 780 network, the EBG initializes the interface the same as for an 781 ordinary EBR (see Section 4.2.1). It then arranges to add one or 782 more of its RLOCs associated with the child enterprise network to the 783 PRL. In particular, for each VET interface configured over a child 784 enterprise network the EBG adds the RLOCs to name service resource 785 records for 'PRLNAME'. 787 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 788 configured over child enterprise networks with a distributed 789 management structure. EBGs may also engage in an unspecified anycast 790 EBG discovery message exchange if they are configured to do so. 792 EBGs configure a DHCP relay/server on VET interfaces configured over 793 child enterprise networks that require DHCP services. 795 To avoid looping, EBGs MUST NOT configure a default route on a VET 796 interface configured over a child enterprise network interface. 798 4.4. VET Host Autoconfiguration 800 Nodes that cannot be attached via an EBR's enterprise-edge interface 801 (e.g., nomadic laptops that connect to a home office via a Virtual 802 Private Network (VPN)) can instead be configured for operation as a 803 simple host with a VET interface. Such VET hosts perform the same 804 VET interface initialization and EBG discovery procedures as 805 specified for EBRs in Section 4.2.1, but they configure their VET 806 interfaces as host interfaces (and not router interfaces). Note also 807 that a node may be configured as a host on some VET interfaces and as 808 an EBR/EBG on other VET interfaces. 810 A VET host may receive non-link-local addresses and/or prefixes to 811 assign to the VET interface via DHCP exchanges and/or through 812 information conveyed in Router Advertisements (RAs). If prefixes are 813 provided, however, there must be assurance that either 1) the VET 814 link will not partition, or 2) that each VET host interface connected 815 to the VET link will configure a unique set of prefixes. VET hosts 816 therefore depend on DHCP and/or RA exchanges to provide only prefixes 817 that are appropriate according to these specific cases (i.e., shared 818 prefixes vs. individual prefixes), and depend on the EBGs within the 819 enterprise keeping track of which prefixes were assigned to which 820 hosts. 822 5. Internetworking Operation 824 Following the autoconfiguration procedures specified in Section 4, 825 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 826 operations as discussed in the following sections. 828 5.1. Routing Protocol Participation 830 ERs engage in any intra-enterprise routing protocols over enterprise- 831 interior interfaces to exchange routing information for forwarding IP 832 packets with RLOC addresses. EBRs and EBGs can additionally engage 833 in any inter-enterprise routing protocols over VET, enterprise-edge 834 and provider-edge interfaces to exchange routing information for 835 forwarding IP packets with EID addresses. Note that the EID-based 836 inter-enterprise IP routing domains are separate and distinct from 837 any RLOC-based enterprise interior IP routing domains. 839 Routing protocol participation on non-multicast VET interfaces uses 840 the NBMA interface model, e.g., in the same manner as for OSPF over 841 NBMA interfaces [RFC5340], while routing protocol participation on 842 multicast-capable VET interfaces uses the standard multicast 843 interface model. EBRs use the list of EBGs in the PRL (see: 844 Section 4.2.1) as an initial list of neighbors for inter-enterprise 845 routing protocol participation. 847 5.1.1. PI Prefix Routing Considerations 849 EBRs that connect large enterprise networks to the global Internet 850 advertise their EID PI prefixes directly into the Internet default- 851 free RIB via the Border Gateway Protocol (BGP) [RFC4271] the same as 852 for a major service provider network. EBRs that connect large 853 enterprise networks to provider networks can instead advertise their 854 EID PI prefixes into the providers' routing system(s) if the provider 855 networks are configured to accept them. 857 EBRs that connect small enterprise networks to provider networks 858 obtain one or more public IP address(es) (i.e., either EID or RLOC IP 859 address) then dynamically register the mapping of their PI prefixes 860 to the public IP address. The registrations are through secured end- 861 to-end exchanges between the EBR and a serving EBG in the PI prefix 862 vendor's network (e.g., through a vendor-specific short http(s) 863 transaction). The PI prefix vendor network then acts as a virtual 864 "home" enterprise network that connects its customer small enterprise 865 networks to the Internet routing system. The customer small 866 enterprise networks in turn appear as mobile components of the PI 867 prefix vendor's network, i.e., the customer networks are always "away 868 from home". 870 Further details on routing for PI prefixes is discussed in "The 871 Internet Routing Overlay Network (IRON)" [I-D.templin-iron] and "Fib 872 Suppression with Virtual Aggregation" [I-D.ietf-grow-va]. 874 5.2. Default Route Configuration and Selection 876 Configuration of default routes in the presence of VET interfaces 877 must be carefully coordinated according to the inner and outer 878 network protocols. If the inner and outer protocols are different 879 (e.g., IPv6 within IPv4) then default routes of the inner protocol 880 version can be configured with next-hops corresponding to default 881 routers on a VET interface while default routes of the outer protocol 882 version can be configured with next-hops corresponding to default 883 routers on an underlying interface. 885 If the inner and outer protocols are the same (e.g., IPv4 within 886 IPv4), care must be taken in setting the default route to avoid 887 ambiguity. For example, if default routes are configured on the VET 888 interface then more-specific routes could be configured on underlying 889 interfaces to avoid looping. In a preferred method, however, 890 multiple default routes can be configured with some having next-hops 891 corresponding to (EID-based) default routers on VET interfaces and 892 others having next-hops corresponding to (RLOC-based) default routers 893 on underlying interfaces. In that case, special next-hop 894 determination rules must be used (see: Section 5.4). 896 5.3. Address Selection 898 When permitted by policy and supported by enterprise interior 899 routing, VET nodes can avoid encapsulation through communications 900 that directly invoke the outer IP protocol using RLOC addresses 901 instead of EID addresses for end-to-end communications. For example, 902 an enterprise network that provides native IPv4 intra-enterprise 903 services can provide continued support for native IPv4 communications 904 even when encapsulated IPv6 services are available for inter- 905 enterprise communications. In other enterprise network scenarios, 906 the use of EID-based communications (i.e., instead of RLOC-based 907 communications) may be necessary and/or beneficial to support address 908 scaling, NAT traversal avoidance, security domain separation, site 909 multihoming, traffic engineering, etc. . 911 VET nodes can use source address selection rules (e.g., based on name 912 service information) to determine whether to use EID-based or RLOC- 913 based addressing. The remainder of this section discusses 914 internetworking operation for EID-based communications using the VET 915 interface abstraction. 917 5.4. Next Hop Determination 919 VET nodes perform normal next-hop determination via longest prefix 920 match, and send packets according to the most-specific matching entry 921 in the FIB. If the FIB entry has multiple next-hop addresses, the 922 EBR selects the next-hop with the best metric value. If multiple 923 next hops have the same metric value, the VET node can use Equal Cost 924 Multi Path (ECMP) to forward different flows via different next-hop 925 addresses, where flows are determined, e.g., by computing a hash of 926 the inner packet's source address, destination address and flow label 927 fields. 929 If the VET node has multiple default routes of the same inner and 930 outer protocol versions, with some corresponding to EID-based default 931 routers and others corresponding to RLOC-based default routers, it 932 must perform source address based selection of a default route. In 933 particular, if the packet's source address is taken from an EID 934 prefix the VET node selects a default route configured over the VET 935 interface; otherwise, it selects a default route configured over an 936 underlying interface. 938 As a last resort when there is no matching entry in the FIB (i.e., 939 not even default), VET nodes can discover next-hop addresses within 940 the enterprise network through on-demand name service queries for the 941 EID prefix taken from a packet's destination address (or, by some 942 other inner address to outer address mapping mechanism). For 943 example, for the IPv6 destination address '2001:DB8:1:2::1' and 944 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 945 service lookup for the domain name: 946 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 948 Name-service lookups in enterprise networks with a centralized 949 management structure use an infrastructure-based service, e.g., an 950 enterprise-local DNS. Name-service lookups in enterprise networks 951 with a distributed management structure and/or that lack an 952 infrastructure-based name service instead use LLMNR over the VET 953 interface. When LLMNR is used, the EBR that performs the lookup 954 sends an LLMNR query (with the prefix taken from the IP destination 955 address encoded in dotted-nibble format as shown above) and accepts 956 the union of all replies it receives from other EBRs on the VET 957 interface. When an EBR receives an LLMNR query, it responds to the 958 query IFF it aggregates an IP prefix that covers the prefix in the 959 query. If the name-service lookup succeeds, it will return RLOC 960 addresses (e.g., in DNS A records) that correspond to next-hop EBRs 961 to which the VET node can forward packets. 963 5.5. VET Interface Encapsulation/Decapsulation 965 VET interfaces encapsulate inner network layer packets in any 966 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 967 etc.) followed by a SEAL header (if necessary) followed by an outer 968 UDP header (if necessary) followed by an outer IP header. Following 969 all encapsulations, the VET interface submits the encapsulated packet 970 to the outer IP forwarding engine for transmission on an underlying 971 interface. The following sections provide further details on 972 encapsulation: 974 5.5.1. Inner Network Layer Protocol 976 The inner network layer protocol sees the VET interface as an 977 ordinary network interface, and views the outer network layer 978 protocol as an L2 transport. The inner- and outer network layer 979 protocol types are mutually independent and can be used in any 980 combination. Inner network layer protocol types include IPv6 981 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 982 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 984 5.5.2. Mid-Layer Encapsulation 986 VET interfaces that use mid-layer encapsulations encapsulate each 987 inner network layer packet in any mid-layer headers and trailers as 988 the first step in a potentially multi-layer encapsulation. 990 5.5.3. SEAL Encapsulation 992 Following any mid-layer encapsulations, VET interfaces that use SEAL 993 add a SEAL header as specified in [I-D.templin-intarea-seal]. 994 Inclusion of a SEAL header MUST be applied uniformly between all 995 nodes on the VET link. Note that when a VET interface sends a SEAL- 996 encapsulated packet to a VET node that does not use SEAL 997 encapsulation, it may receive an ICMP "port unreachable" or "protocol 998 unreachable" depending on whether/not an outer UDP header is 999 included. 1001 SEAL encapsulation is used on VET links that require path MTU 1002 mitigations due to encapsulation overhead and/or mechanisms for VET 1003 interface neighbor coordination. When SEAL encapsulation is used, 1004 the VET interface sets the 'Next Header' value in the SEAL header to 1005 the IP protocol number associated with either the mid-layer 1006 encapsulation or the IP protocol number of the inner network layer 1007 (if no mid-layer encapsulation is used). The VET interface sets the 1008 other fields in the SEAL header as specified in 1009 [I-D.templin-intarea-seal]. 1011 5.5.4. Outer UDP Header Encapsulation 1013 Following any mid-layer and/or SEAL encapsulations, VET interfaces 1014 that use UDP encapsulation add an outer UDP header. Inclusion of an 1015 outer UDP header must be applied uniformly between all nodes on the 1016 VET link. Note that when a VET interface sends a UDP-encapsulated 1017 packet to a node that does not recognize the UDP port number, it may 1018 receive an ICMP "port unreachable" message. 1020 VET interfaces use UDP encapsulation on VET links that may traverse 1021 Network Address Translators (NATs) and/or legacy networking gear that 1022 only recognizes certain network layer protocols, e.g., Equal Cost 1023 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc. 1024 When UDP encapsulation is used, the VET interface encapsulates the 1025 mid-layer packet in an outer UDP header then sets the UDP port 1026 numbers as specified for the outermost mid-layer protocol (e.g., 1027 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 1028 is used as the outermost mid-layer protocol, the VET interface sets 1029 the UDP source port number to a hash calculated over the inner 1030 network layer {destination, source} values or (optionally) over the 1031 inner network layer {dest addr, source addr, protocol, dest port, 1032 source port} values. The VET interface uses a hash function of its 1033 own choosing, but it MUST be consistent in the manner in which the 1034 hash is applied.. 1036 For VET links configured over IPv4 enterprise networks, the VET 1037 interface sets the UDP checksum field to zero. For VET links 1038 configured over IPv6 enterprise networks, considerations for setting 1039 the UDP checksum are discussed in [I-D.ietf-6man-udpzero]. 1041 5.5.5. Outer IP Header Encapsulation 1043 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1044 interface adds an outer IP header. Outer IP header construction is 1045 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1046 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1047 Service/Traffic Class" and "Congestion Experienced" values in the 1048 inner network layer header are copied into the corresponding fields 1049 in the outer IP header. The VET interface also sets the IP protocol 1050 number to the appropriate value for the first protocol layer within 1051 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1052 as the outer IP protocol, the VET interface sets the flow label value 1053 in the outer IPv6 header the same as described in 1054 [I-D.carpenter-flow-ecmp]. 1056 5.5.6. Decapsulation 1058 When a VET interface receives an encapsulated packet, it retains the 1059 outer headers and processes the SEAL header as specified in 1060 [I-D.templin-intarea-seal]. 1062 Next, if the packet will be forwarded from the receiving VET 1063 interface into a forwarding VET interface, the VET node copies the 1064 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1065 Experienced" values in the outer IP header received on the receiving 1066 VET interface into the corresponding fields in the outer IP header to 1067 be sent over the forwarding VET interface (i.e., the values are 1068 transferred between outer headers and *not* copied from the inner 1069 network layer header). This is true even if the packet is forwarded 1070 out the same VET interface that it arrived on, and necessary to 1071 support diagnostic functions (e.g., traceroute) and avoid looping. 1073 During decapsulation, when the next-hop is via a non-VET interface, 1074 the "Congestion Experienced" value in the outer IP header is copied 1075 into the corresponding field in the inner network layer header. 1077 5.6. Mobility and Multihoming Considerations 1079 EBRs that travel between distinct enterprise networks must either 1080 abandon their PA prefixes that are relative to the "old" enterprise 1081 and obtain PA prefixes relative to the "new" enterprise, or somehow 1082 coordinate with a "home" enterprise to retain ownership of the 1083 prefixes. In the first instance, the EBR would be required to 1084 coordinate a network renumbering event using the new PA prefixes 1085 [RFC4192][RFC5887]. In the second instance, an ancillary mobility 1086 management mechanism is required. 1088 EBRs can retain their PI prefixes as they travel between distinct 1089 enterprise networks as long as they update their PI prefix to public 1090 IP address mappings with their PI prefix vendors. This is 1091 accomplished by performing short transactions with EBGs in the PI 1092 prefix vendor network the same as specified in Section 5.1.1. In 1093 this way, EBRs can update their PI prefix to RLOC mappings in real 1094 time as their RLOCs change. 1096 The EBGs of a multihomed enterprise network participate in a private 1097 inner network layer routing protocol instance (possibly over an 1098 alternate topology) to accommodate network partitions/merges as well 1099 as intra-enterprise mobility events. 1101 5.7. Neighbor Coordination on VET Interfaces using SEAL 1103 VET interfaces that use SEAL use the SEAL Control Message Protocol 1104 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1105 coordinate reachability, routing information, and mappings between 1106 the inner and outer network layer protocols. SCMP directly parallels 1107 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1108 [RFC4443] protocols, but operates from within the tunnel and supports 1109 operation for any combinations of inner and outer network layer 1110 protocols. 1112 VET and SEAL are specifically designed for encapsulation of inner 1113 protocol payloads over IPv4 and IPv6 networks as a link layer. VET 1114 interfaces that use SCMP therefore require a new Source/Target Link- 1115 Layer Address Option (S/TLLAO) format that encapsulates IPv4 1116 addresses as shown in Figure 2 and IPv6 addresses as shown in 1117 Figure 3: 1119 0 1 2 3 1120 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 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Type = 2 | Length = 1 | Reserved | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | IPv4 address (bytes 0 thru 3) | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 2: SCMP S/TLLAO Option for IPv4 RLOCs 1129 0 1 2 3 1130 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 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Type = 2 | Length = 3 | Reserved | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Reserved | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | IPv6 address (bytes 0 thru 3) | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | IPv6 address (bytes 4 thru 7) | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | IPv6 address (bytes 8 thru 11) | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | IPv6 address (bytes 12 thru 15) | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 Figure 3: SCMP S/TLLAO Option for IPv6 RLOCs 1147 In addition, VET interfaces that use SCMP use a modified version of 1148 the Route Information Option (RIO) (see: [RFC4191]) formatted as 1149 shown in Figure 4: 1151 0 1 2 3 1152 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 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Type = 24 | Length | Prefix Length | AF |Prf|Resvd| 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Route Lifetime | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Prefix (Variable Length) | 1159 . . 1160 . . 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 Figure 4: SCMP Route Information Option Format 1165 In this modified format, the VET interface sets the Route Lifetime 1166 and Prefix fields in the RIO option the same as specified in 1168 [RFC4191]. It then sets the fields in the header as follows: 1170 o the 'Type', 'Length' and 'Prf' fields are set the same as 1171 specified in [RFC4191]. 1173 o the 'Resvd' field is set to 0. 1175 o the 'Length' field is set to 1, 2, or 3 as specified in [RFC4191]. 1176 It is instead set to 4 if the 'Prefix Length' is greater than 128 1177 and set to 5 if the 'Prefix Length' is greater than 192 in order 1178 to accommodate longer prefixes of non-IP protocols. 1180 o the 'Prefix Length' field ranges from 0 to 255. The 'Prefix' 1181 field is 0, 8, 16, 24 or 32 octets depending on the Length, and 1182 the embedded prefix MAY be up to 256 bits in length. (If the 1183 length is 256 bits, however the Prefix Length field encodes the 1184 value 0.) 1186 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1187 that indicates the embedded prefix protocol type. This document 1188 defines the following values for AF: 1190 * 000 - IPv4 1192 * 001 - IPv6 1194 * 010 - OSI/CLNP NSAP 1196 The following subsections discuss VET interface neighbor coordination 1197 using SCMP: 1199 5.7.1. Router Discovery 1201 VET hosts and EBRs can send SCMP Router Solicitation (SRS) messages 1202 to one or more EBGs in the PRL to receive solicited SCMP Router 1203 Advertisements (SRAs). 1205 When an EBG receives an SRS message on a VET interface, it prepares a 1206 solicited SRA message. The SRA includes Router Lifetimes, Default 1207 Router Preferences, PIOs and any other options/parameters that the 1208 EBG is configured to include. If necessary, the EBG also includes 1209 Route Information Options (RIOs) formatted as specified above. 1211 The EBG finally includes one or more SLLAOs formatted as specified 1212 above that encode the IPv6 and/or IPv4 RLOC unicast addresses of its 1213 own enterprise interior interfaces or the enterprise interior 1214 interfaces of other nearby EBGs. 1216 5.7.2. Neighbor Unreachability Detection 1218 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1219 interface neighbors by monitoring hints of forward progress as 1220 evidence that a neighbor is reachable. SEAL enables an explicit 1221 acknowledgement mechanism that can provide hints of forward progress. 1222 When data packets are flowing, the VET node can periodically set the 1223 A bit in the SEAL header of data packets to elicit SCMP responses 1224 from the neighbor. When no data packets are flowing, the VET node 1225 can send periodic probes such as SCMP Neighbor Solicitation (SNS) 1226 messages for the same purpose. 1228 Responsiveness to routing changes is directly related to the delay in 1229 detecting that a neighbor has gone unreachable. In order to provide 1230 responsiveness comparable to dynamic routing protocols, a reasonably 1231 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1233 Additionally, a VET node may receive outer IP ICMP "Destination 1234 Unreachable; net / host unreachable" messages from an ER on the path 1235 indicating that the path to a VET neighbor may be failing. The node 1236 SHOULD first check the packet-in-error to obtain reasonable assurance 1237 that the ICMP message is authentic. If the node receives excessive 1238 ICMP unreachable errors through multiple RLOCs associated with the 1239 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1240 packets to flow through a different route. 1242 5.7.3. Redirect Function 1244 A VET node (i.e., the redirectee) may receive a redirect message when 1245 it forwards packets over a VET interface to a neighboring VET node 1246 (i.e., the redirector). The redirector will forward the packet and 1247 return an SCMP Redirect message if necessary to inform the redirectee 1248 of a better next hop. 1250 The SCMP Redirect message is formatted the same as for ordinary 1251 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1252 the Destination and Target Address fields are unnecessary and 1253 therefore omitted. The format of the SCMP Redirect message is shown 1254 in Figure 5 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Type = 137 | Code = 0 | Checksum | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Reserved | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Options ... 1263 +-+-+-+-+-+-+-+-+-+-+-+- 1265 Figure 5: SCMP Redirect Message Format 1267 The redirector then adds any necessary Options to the Redirect 1268 message. It first includes one or more TLLAOs (see above) that 1269 include RLOCs corresponding to better next hops. The redirector next 1270 includes an RIO that contains a prefix from its FIB that covers the 1271 destination address of the original packet. 1273 Following the RIO option, the redirector includes any other necessary 1274 options (e.g., SEND options) followed by a Redirected Header option 1275 containing the leading portion of the packet that triggered the 1276 redirect as the final option in the message. The redirector then 1277 encapsulates the Redirect message the same as for any other SCMP 1278 message and sends it to the redirectee. 1280 When the redirectee receives the Redirect, it first authenticates the 1281 message (e.g.., by checking the SEAL_ID in the Redirected Header, 1282 etc.) then uses the EID prefix in the RIO with its respective 1283 lifetime to update its FIB. The redirectee also caches the IPv4 or 1284 IPv6 addresses in TLLAOs as the layer 2 addresses of potential next- 1285 hops for the prefix. 1287 The redirectee retains the FIB entry created as a result of receipt 1288 of an SCMP Redirect until the route lifetime expires, or until the 1289 redirected target neighbor becomes unreachable. In this way, RLOC 1290 liveness detection parallels IPv6 Neighbor Unreachability Detection. 1292 5.7.3.1. Correspondent Node Redirection 1294 When a mobile VET node moves to a new network point of attachment, it 1295 leaves short-term forwarding information with its former network 1296 point of attachment. Thereafter, any existing correspondents that 1297 attempt to contact the mobile node via the former network point of 1298 attachment will be redirected to the new network point of attachment. 1300 In this way, mobile VET nodes need not inform correspondents of a 1301 mobility event, since the correspondents will soon receive redirects 1302 from the network. 1304 5.8. Neighbor Coordination on VET Interfaces using IPsec 1306 VET interfaces that use IPsec encapsulation use the Internet Key 1307 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1308 association setup and maintenance. The IKEv2 can be seen as a 1309 logical equivalent of the SEAL SCMP in terms of VET interface 1310 neighbor coordinations. In particular, IKEv2 also provides 1311 mechanisms for redirection [RFC5685] and mobility [RFC4555]. 1313 IPsec additionally provides an extended Identification field and 1314 integrity check vector; these features allow IPsec to utilize outer 1315 IP fragmentation and reassembly with less risk of exposure to data 1316 corruption due to reassembly misassociations. On the other hand, 1317 IPsec entails the use of symmetric security associations and hence 1318 may not be appropriate to all enterprise network use cases. 1320 5.9. Multicast 1322 In multicast-capable deployments, ERs provide an enterprise-wide 1323 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1324 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1325 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1326 over their enterprise-interior interfaces such that outer IP 1327 multicast messages of site-scope or greater scope will be propagated 1328 across the enterprise network. For such deployments, VET nodes can 1329 also provide an inner multicast/broadcast capability over their VET 1330 interfaces through mapping of the inner multicast address space to 1331 the outer multicast address space. In that case, operation of link- 1332 scoped (or greater scoped) inner multicasting services (e.g., a link- 1333 scoped neighbor discovery protocol) over the VET interface is 1334 available, but should be used sparingly to minimize enterprise-wide 1335 flooding. 1337 VET nodes encapsulate inner multicast messages sent over the VET 1338 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1339 followed by an outer IP header with a site-scoped outer IP multicast 1340 address as the destination. For the case of IPv6 and IPv4 as the 1341 inner/outer protocols (respectively), [RFC2529] provides mappings 1342 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1343 address space (for other encapsulations, mappings are established 1344 through administrative configuration or through an unspecified 1345 alternate static mapping). 1347 Multicast mapping for inner multicast groups over outer IP multicast 1348 groups can be accommodated, e.g., through VET interface snooping of 1349 inner multicast group membership and routing protocol control 1350 messages. To support inner-to-outer multicast address mapping, the 1351 VET interface acts as a virtual outer IP multicast host connected to 1352 its underlying interfaces. When the VET interface detects that an 1353 inner multicast group joins or leaves, it forwards corresponding 1354 outer IP multicast group membership reports on an underlying 1355 interface over which the VET interface is configured. If the VET 1356 node is configured as an outer IP multicast router on the underlying 1357 interfaces, the VET interface forwards locally looped-back group 1358 membership reports to the outer IP multicast routing process. If the 1359 VET node is configured as a simple outer IP multicast host, the VET 1360 interface instead forwards actual group membership reports (e.g., 1361 IGMP messages) directly over an underlying interface. 1363 Since inner multicast groups are mapped to site-scoped outer IP 1364 multicast groups, the VET node MUST ensure that the site-scope outer 1365 IP multicast messages received on the underlying interfaces for one 1366 VET interface do not "leak out" to the underlying interfaces of 1367 another VET interface. This is accommodated through normal site- 1368 scoped outer IP multicast group filtering at enterprise network 1369 boundaries. 1371 5.10. Service Discovery 1373 VET nodes can perform enterprise-wide service discovery using a 1374 suitable name-to-address resolution service. Examples of flooding- 1375 based services include the use of LLMNR [RFC4795] over the VET 1376 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1377 over an underlying interface. More scalable and efficient service 1378 discovery mechanisms (e.g., anycast) are for further study. 1380 5.11. Enterprise Network Partitioning 1382 An enterprise network can be partitioned into multiple distinct 1383 logical groupings. In that case, each partition configures its own 1384 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1385 'isatapv2.zone2.example.com', etc.). 1387 EBGs can further create multiple IP subnets within a partition, e.g., 1388 by sending RAs with PIOs containing different IP prefixes to 1389 different groups of VET hosts. EBGs can identify subnets, e.g., by 1390 examining RLOC prefixes, observing the enterprise interior interfaces 1391 over which RSs are received, etc. 1393 In the limiting case, EBGs can advertise a unique set of IP prefixes 1394 to each VET host such that each host belongs to a different subnet 1395 (or set of subnets) on the VET interface. 1397 5.12. EBG Prefix State Recovery 1399 EBGs retain explicit state that tracks the inner PA prefixes 1400 delegated to EBRs within the enterprise network, e.g., so that 1401 packets are delivered to the correct EBRs. When an EBG loses some or 1402 all of its state (e.g., due to a power failure), it must recover the 1403 state so that packets can be forwarded over correct routes. 1405 5.13. Support for Legacy ISATAP Services 1407 EBGs support legacy ISATAP services according to the specifications 1408 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1409 interfaces and VET interfaces over the same sets of underlying 1410 interfaces as long as the PRLs and IPv6 prefixes associated with the 1411 ISATAP/VET interfaces are distinct. 1413 6. IANA Considerations 1415 There are no IANA considerations for this document. 1417 7. Security Considerations 1419 Security considerations for MANETs are found in [RFC2501]. 1421 The security considerations found in 1422 [RFC2529][RFC5214][I-D.nakibly-v6ops-tunnel-loops] also apply to VET. 1424 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1425 where attacks on the neighbor coordination protocol are possible. 1426 SEAL [I-D.templin-intarea-seal] provides a per-packet identification 1427 that can be used to detect source address spoofing. 1429 Rogue neighbor coordination messages with spoofed RLOC source 1430 addresses can consume network resources and cause VET nodes to 1431 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1432 such RLOCs, as that may result in a denial of service to the RLOCs' 1433 legitimate owners. 1435 VET EBRs and EBGs observe the recommendations for network ingress 1436 filtering [RFC2827]. 1438 8. Related Work 1440 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1441 automatic tunneling in [RFC2529]; this concept was later called: 1443 "Virtual Ethernet" and investigated by Quang Nguyen under the 1444 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1445 their colleagues have motivated a number of foundational concepts on 1446 which this work is based. 1448 Telcordia has proposed DHCP-related solutions for MANETs through the 1449 CECOM MOSAIC program. 1451 The Naval Research Lab (NRL) Information Technology Division uses 1452 DHCP in their MANET research testbeds. 1454 Security concerns pertaining to tunneling mechanisms are discussed in 1455 [I-D.ietf-v6ops-tunnel-security-concerns]. 1457 Default router and prefix information options for DHCPv6 are 1458 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1460 An automated IPv4 prefix delegation mechanism is proposed in 1461 [I-D.ietf-dhc-subnet-alloc]. 1463 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1464 [I-D.clausen-manet-autoconf-recommendations]. 1466 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1468 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1469 decapsulation issues and other aspects of tunneling. 1471 Various proposals within the IETF have suggested similar mechanisms. 1473 9. Acknowledgements 1475 The following individuals gave direct and/or indirect input that was 1476 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1477 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1478 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1479 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1480 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1481 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1482 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1483 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1484 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1485 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1486 working groups. Many others have provided guidance over the course 1487 of many years. 1489 10. Contributors 1491 The following individuals have contributed to this document: 1493 Eric Fleischman (eric.fleischman@boeing.com) 1494 Thomas Henderson (thomas.r.henderson@boeing.com) 1495 Steven Russert (steven.w.russert@boeing.com) 1496 Seung Yi (seung.yi@boeing.com) 1498 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1499 of the document. 1501 Jim Bound's foundational work on enterprise networks provided 1502 significant guidance for this effort. We mourn his loss and honor 1503 his contributions. 1505 11. References 1507 11.1. Normative References 1509 [I-D.templin-intarea-seal] 1510 Templin, F., "The Subnetwork Encapsulation and Adaptation 1511 Layer (SEAL)", draft-templin-intarea-seal-24 (work in 1512 progress), November 2010. 1514 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1515 September 1981. 1517 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1518 RFC 792, September 1981. 1520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1521 Requirement Levels", BCP 14, RFC 2119, March 1997. 1523 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1524 RFC 2131, March 1997. 1526 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1527 (IPv6) Specification", RFC 2460, December 1998. 1529 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1530 Defeating Denial of Service Attacks which employ IP Source 1531 Address Spoofing", BCP 38, RFC 2827, May 2000. 1533 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1534 and M. Carney, "Dynamic Host Configuration Protocol for 1535 IPv6 (DHCPv6)", RFC 3315, July 2003. 1537 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1538 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1539 December 2003. 1541 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1542 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1544 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1545 RFC 3972, March 2005. 1547 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1548 More-Specific Routes", RFC 4191, November 2005. 1550 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1551 Architecture", RFC 4291, February 2006. 1553 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1554 Message Protocol (ICMPv6) for the Internet Protocol 1555 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1557 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1558 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1559 September 2007. 1561 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1562 Address Autoconfiguration", RFC 4862, September 2007. 1564 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1565 for IEEE 802 Parameters", BCP 141, RFC 5342, 1566 September 2008. 1568 11.2. Informative References 1570 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1571 Switching Networks", May 1974. 1573 [I-D.carpenter-flow-ecmp] 1574 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1575 for equal cost multipath routing and link aggregation in 1576 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 1577 October 2010. 1579 [I-D.cheshire-dnsext-multicastdns] 1580 Cheshire, S. and M. Krochmal, "Multicast DNS", 1581 draft-cheshire-dnsext-multicastdns-12 (work in progress), 1582 October 2010. 1584 [I-D.clausen-manet-autoconf-recommendations] 1585 Clausen, T. and U. Herberg, "MANET Router Configuration 1586 Recommendations", 1587 draft-clausen-manet-autoconf-recommendations-00 (work in 1588 progress), February 2009. 1590 [I-D.clausen-manet-linktype] 1591 Clausen, T., "The MANET Link Type", 1592 draft-clausen-manet-linktype-00 (work in progress), 1593 October 2008. 1595 [I-D.droms-dhc-dhcpv6-default-router] 1596 Droms, R. and T. Narten, "Default Router and Prefix 1597 Advertisement Options for DHCPv6", 1598 draft-droms-dhc-dhcpv6-default-router-00 (work in 1599 progress), March 2009. 1601 [I-D.ietf-6man-udpzero] 1602 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 1603 Considerations", draft-ietf-6man-udpzero-02 (work in 1604 progress), October 2010. 1606 [I-D.ietf-dhc-subnet-alloc] 1607 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1608 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1609 (work in progress), May 2010. 1611 [I-D.ietf-grow-va] 1612 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1613 L. Zhang, "FIB Suppression with Virtual Aggregation", 1614 draft-ietf-grow-va-03 (work in progress), August 2010. 1616 [I-D.ietf-lisp] 1617 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1618 "Locator/ID Separation Protocol (LISP)", 1619 draft-ietf-lisp-09 (work in progress), October 2010. 1621 [I-D.ietf-manet-smf] 1622 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1623 draft-ietf-manet-smf-10 (work in progress), March 2010. 1625 [I-D.ietf-v6ops-tunnel-security-concerns] 1626 Krishnan, S., Thaler, D., and J. Hoagland, "Security 1627 Concerns With IP Tunneling", 1628 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 1629 progress), October 2010. 1631 [I-D.jen-apt] 1632 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1633 L. Zhang, "APT: A Practical Transit Mapping Service", 1634 draft-jen-apt-01 (work in progress), November 2007. 1636 [I-D.nakibly-v6ops-tunnel-loops] 1637 Nakibly, G. and F. Templin, "Routing Loop Attack using 1638 IPv6 Automatic Tunnels: Problem Statement and Proposed 1639 Mitigations", draft-nakibly-v6ops-tunnel-loops-03 (work in 1640 progress), August 2010. 1642 [I-D.russert-rangers] 1643 Russert, S., Fleischman, E., and F. Templin, "RANGER 1644 Scenarios", draft-russert-rangers-05 (work in progress), 1645 July 2010. 1647 [I-D.templin-iron] 1648 Templin, F., "The Internet Routing Overlay Network 1649 (IRON)", draft-templin-iron-13 (work in progress), 1650 October 2010. 1652 [I-D.templin-isatap-dhcp] 1653 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1654 Option for the Intra-Site Automatic Tunnel Addressing 1655 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1656 progress), December 2009. 1658 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1659 July 1978. 1661 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1662 Protocol Specification", October 2008. 1664 [RFC0994] International Organization for Standardization (ISO) and 1665 American National Standards Institute (ANSI), "Final text 1666 of DIS 8473, Protocol for Providing the Connectionless- 1667 mode Network Service", RFC 994, March 1986. 1669 [RFC1035] Mockapetris, P., "Domain names - implementation and 1670 specification", STD 13, RFC 1035, November 1987. 1672 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1673 a subnetwork for experimentation with the OSI network 1674 layer", RFC 1070, February 1989. 1676 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1677 Communication Layers", STD 3, RFC 1122, October 1989. 1679 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1680 Routing and Addressing Architecture", RFC 1753, 1681 December 1994. 1683 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1684 E. Lear, "Address Allocation for Private Internets", 1685 BCP 5, RFC 1918, February 1996. 1687 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1688 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1690 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1691 October 1996. 1693 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1694 Extensions", RFC 2132, March 1997. 1696 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1697 IPv6 Specification", RFC 2473, December 1998. 1699 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1700 over Non-Broadcast Multiple Access (NBMA) networks", 1701 RFC 2491, January 1999. 1703 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1704 (MANET): Routing Protocol Performance Issues and 1705 Evaluation Considerations", RFC 2501, January 1999. 1707 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1708 Domains without Explicit Tunnels", RFC 2529, March 1999. 1710 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1711 February 2000. 1713 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1714 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1715 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1716 RFC 3819, July 2004. 1718 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1719 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1720 May 2005. 1722 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1723 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1724 January 2005. 1726 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1727 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1728 RFC 3948, January 2005. 1730 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1731 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1732 September 2005. 1734 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1735 Addresses", RFC 4193, October 2005. 1737 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1738 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1740 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1741 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1743 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1744 Internet Protocol", RFC 4301, December 2005. 1746 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1747 RFC 4306, December 2005. 1749 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1750 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1751 May 2006. 1753 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1754 (MOBIKE)", RFC 4555, June 2006. 1756 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1757 Multicast Name Resolution (LLMNR)", RFC 4795, 1758 January 2007. 1760 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1761 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1762 Focus", RFC 4852, April 2007. 1764 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1765 June 2007. 1767 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1768 Extensions for Stateless Address Autoconfiguration in 1769 IPv6", RFC 4941, September 2007. 1771 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1772 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1773 March 2008. 1775 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1776 for IPv6", RFC 5340, July 2008. 1778 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1779 Infrastructures (6rd)", RFC 5569, January 2010. 1781 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1782 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1783 RFC 5685, November 2009. 1785 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1786 Global Enterprise Recursion (RANGER)", RFC 5720, 1787 February 2010. 1789 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1790 Still Needs Work", RFC 5887, May 2010. 1792 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1793 Infrastructures (6rd) -- Protocol Specification", 1794 RFC 5969, August 2010. 1796 Appendix A. Duplicate Address Detection (DAD) Considerations 1798 A priori uniqueness determination (also known as "pre-service DAD") 1799 for an RLOC assigned on an enterprise-interior interface would 1800 require either flooding the entire enterprise network or somehow 1801 discovering a link in the network on which a node that configures a 1802 duplicate address is attached and performing a localized DAD exchange 1803 on that link. But, the control message overhead for such an 1804 enterprise-wide DAD would be substantial and prone to false-negatives 1805 due to packet loss and intermittent connectivity. An alternative to 1806 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1807 enterprise-interior interfaces and employ a passive in-service DAD 1808 (e.g., one that monitors routing protocol messages for duplicate 1809 assignments). 1811 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1812 CGAs, IPv6 privacy addresses, etc. with very small probability of 1813 collision. Pseudo-random IPv4 RLOCs can be generated through random 1814 assignment from a suitably large IPv4 prefix space. 1816 Consistent operational practices can assure uniqueness for EBG- 1817 aggregated addresses/prefixes, while statistical properties for 1818 pseudo-random address self-generation can assure uniqueness for the 1819 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1820 RLOC delegation authority should be used when available, while a 1821 passive in-service DAD mechanism should be used to detect RLOC 1822 duplications when there is no RLOC delegation authority. 1824 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1826 For each distinct enterprise network that it connects to, an EBR 1827 configures a VET interface over possibly multiple underlying 1828 interfaces that all connect to the same network. The VET interface 1829 therefore represents the EBR's logical point of attachment to the 1830 enterprise network, and provides a logical interface for link-layer 1831 multiplexing over its underlying interfaces as described in Section 1832 3.3.4 of [RFC1122]: 1834 "Finally, we note another possibility that is NOT multihoming: one 1835 logical interface may be bound to multiple physical interfaces, in 1836 order to increase the reliability or throughput between directly 1837 connected machines by providing alternative physical paths between 1838 them. For instance, two systems might be connected by multiple 1839 point-to-point links. We call this "link-layer multiplexing". 1840 With link-layer multiplexing, the protocols above the link layer 1841 are unaware that multiple physical interfaces are present; the 1842 link-layer device driver is responsible for multiplexing and 1843 routing packets across the physical interfaces." 1845 EBRs can support such a link-layer multiplexing capability across the 1846 enterprise network in accordance with the Weak End System Model (see 1847 Section 3.3.4 of [RFC1122]). In particular, when an EBR 1848 autoconfigures an RLOC address, it can associate it with the VET 1849 interface only instead of assigning it to an underlying interface. 1850 The EBR therefore only needs to obtain a single RLOC address even if 1851 there are multiple underlying interfaces, i.e., it does not need to 1852 obtain one for each underlying interface. The EBR can then leave the 1853 underlying interfaces unnumbered, or it can configure a randomly 1854 chosen IP link-local address (e.g., from the prefix 169.254/16 1855 [RFC3927] for IPv4) on underlying interfaces that require a 1856 configuration. The EBR need not check these link-local addresses for 1857 uniqueness within the enterprise network, as they will not normally 1858 be used as the source address for packets. 1860 When the EBR engages in the enterprise-interior routing protocol, it 1861 uses the RLOC address assigned to the VET interface as the source 1862 address for all routing protocol control messages, however it must 1863 also supply an interface identifier (e.g., a small integer) that 1864 uniquely identifies the underlying interface that the control message 1865 is sent over. For example, if the underlying interfaces are known as 1866 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1867 sends a routing protocol control message over the "eth7" interface. 1868 This is necessary to ensure that other routers can determine the 1869 specific interface over which the EBR's routing protocol control 1870 message was sent, but the token need only be unique within the EBR 1871 itself and need not be unique throughout the enterprise network. 1873 When the EBR discovers an RLOC route via the enterprise interior 1874 routing protocol, it configures a preferred route in the IP FIB that 1875 points to the VET interface instead of the underlying interface. At 1876 the same time, the EBR also configures an ancillary route that points 1877 to the underlying interface. If the EBR discovers that the same RLOC 1878 route is reachable via multiple underlying interfaces, it configures 1879 multiple ancillary routes (i.e., one for each interface). If the EBR 1880 discovers that the RLOC route is no longer reachable via any 1881 underlying interface, it removes the route in the IP FIB that points 1882 to the VET interface. 1884 With these arrangements, all locally-generated packets with RLOC 1885 destinations will flow through the VET interface (and thereby use the 1886 VET interface's RLOC address as the source address) instead of 1887 through the underlying interfaces. In the same fashion, all 1888 forwarded packets with RLOC destinations will flow through the VET 1889 interface instead of through the underlying interfaces. 1891 This arrangement has several operational advantages that enable a 1892 number of traffic engineering capabilities when SEAL encapsulation is 1893 also used. First, the VET interface can insert the SEAL header so 1894 that ID-based duplicate packet detection is enabled within the 1895 enterprise network. Secondly, SEAL can dynamically adjust its packet 1896 sizing parameters so that an optimum Maximum Transmission Unit (MTU) 1897 can be determined. This is true even if the VET interface reroutes 1898 traffic between underlying interfaces with different MTUs. 1900 Most importantly, the EBR can configure default and more-specific 1901 routes on the VET interface to direct traffic through a specific 1902 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1903 will ensure that a specific eEBR is chosen, and the best eEBR can be 1904 chosen when multiple are available. Also, local applications see a 1905 stable IP source address even if there are multiple underlying 1906 interfaces. This link-layer multiplexing can therefore provide 1907 continuous operation across failovers between multiple links attached 1908 to the same enterprise network without any need for readdressing. 1909 Finally, the VET interface can forward packets with RLOC-based 1910 destinations over an underlying interface without any encapsulation 1911 if encapsulation avoidance is desired. 1913 It must be specifically noted that the above arrangement constitutes 1914 a case in which the same RLOC may be used as both the inner and outer 1915 IP source address. This will not present a problem as long as both 1916 ends configure a VET interface in the same fashion. 1918 It must also be noted that EID-based communications can use the same 1919 VET interface arrangement, except that the EID-based next hop must be 1920 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1921 within IPvX encapsulation, as well as for IPv4 within IPv6 1922 encapsulation, this requires a VET interface specific address mapping 1923 database. For IPv6 within IPv4 encapsulation, the mapping is 1924 accomplished through simple static extraction of an IPv4 address 1925 embedded within the IPv6 address. 1927 Appendix C. Anycast Services 1929 Some of the IPv4 addresses that appear in the Potential Router List 1930 may be anycast addresses, i.e., they may be configured on the VET 1931 interfaces of multiple EBRs/EBGs. In that case, each VET router 1932 interface that configures the same anycast address must provide 1933 equivalent packet forwarding and neighbor discovery services. 1935 Use of an anycast address as the IP destination address of tunneled 1936 packets can have subtle interactions with tunnel path MTU and 1937 neighbor discovery. For example, if the initial fragments of a 1938 fragmented tunneled packet with an anycast IP destination address are 1939 routed to different egress tunnel endpoints than the remaining 1940 fragments, the multiple endpoints will be left with incomplete 1941 reassembly buffers. This issue can be mitigated by ensuring that 1942 each egress tunnel endpoint implements a proactive reassembly buffer 1943 garbage collection strategy. Additionally, ingress tunnel endpoints 1944 that send packets with an anycast IP destination address must use the 1945 minimum path MTU for all egress tunnel endpoints that configure the 1946 same anycast address as the tunnel MTU. Finally, ingress tunnel 1947 endpoints should treat ICMP unreachable messages from a router within 1948 the tunnel as at most a weak indication of neighbor unreachability, 1949 since the failures may only be transient and a different path to an 1950 alternate anycast router quickly selected through reconvergence of 1951 the underlying routing protocol. 1953 Use of an anycast address as the IP source address of tunneled 1954 packets can lead to more serious issues. For example, when the IP 1955 source address of a tunneled packet is anycast, ICMP messages 1956 produced by routers within the tunnel might be delivered to different 1957 ingress tunnel endpoints than the ones that produced the packets. In 1958 that case, functions such as path MTU discovery and neighbor 1959 unreachability detection may experience non-deterministic behavior 1960 that can lead to communications failures. Additionally, the 1961 fragments of multiple tunneled packets produced by multiple ingress 1962 tunnel endpoints may be delivered to the same reassembly buffer at a 1963 single egress tunnel endpoint. In that case, data corruption may 1964 result due to fragment misassociation during reassembly. 1966 In view of these considerations, EBRs/EBGs that configure an anycast 1967 address should also configure one or more unicast addresses from the 1968 Potential Router List; they should further accept tunneled packets 1969 destined to any of their anycast or unicast addresses, but should 1970 send tunneled packets using a unicast address as the source address. 1971 In order to influence traffic to use an anycast route (and thereby 1972 leverage the natural fault tolerance afforded by anycast), ISATAP 1973 routers should set higher preferences on the default routes they 1974 advertise using an anycast address as the source and set lower 1975 preferences on the default routes they advertise using a unicast 1976 address as the source (see: [RFC4191]). 1978 Appendix D. Change Log 1980 (Note to RFC editor - this section to be removed before publication 1981 as an RFC.) 1983 Changes from -14 to -15: 1985 o new insights into default route configuration and next-hop 1986 determination 1988 Changes from -13 to -14: 1990 o fixed Idnits 1992 Changes from -12 to -13: 1994 o Changed "VGL" *back* to "PRL" 1996 o More changes for multi-protocol support 1998 o Changes to Redirect function 2000 Changes from -11 to -12: 2002 o Major section rearrangement 2004 o Changed "PRL" to "VGL" 2006 o Brought back text that was lost in the -10 to -11 transition 2008 Changes from -10 to -11: 2010 o Major changes with significant simplifications 2012 o Now support stateless PD using 6rd mechanisms 2013 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2015 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2017 Changes from -09 to -10: 2019 o Changed "enterprise" to "enterprise network" throughout 2021 o dropped "inner IP", since inner layer may be non-IP 2023 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2024 messages remain *within* the tunnel interface instead of being 2025 exposed to the inner network layer protocol engine. 2027 Changes from -08 to -09: 2029 o Expanded discussion of encapsulation/decapsulation procedures 2031 o cited IRON 2033 Changes from -07 to -08: 2035 o Specified the approach to global mapping using virtual aggregation 2036 and BGP 2038 Changes from -06 to -07: 2040 o reworked redirect function 2042 o created new section on VET interface encapsulation 2044 o clarifications on nexthop selection 2046 o fixed several bugs 2048 Changed from -05 to -06: 2050 o reworked VET interface ND 2052 o anycast clarifications 2054 Changes from -03 to -04: 2056 o security consideration clarifications 2058 Changes from -02 to -03: 2060 o security consideration clarifications 2062 o new PRLNAME for VET is "isatav2.example.com" 2064 o VET now uses SEAL natively 2066 o EBGs can support both legacy ISATAP and VET over the same 2067 underlying interfaces. 2069 Changes from -01 to -02: 2071 o Defined CGA and privacy address configuration on VET interfaces 2073 o Interface identifiers added to routing protocol control messages 2074 for link-layer multiplexing 2076 Changes from -00 to -01: 2078 o Section 4.1 clarifications on link-local assignment and RLOC 2079 autoconfiguration. 2081 o Appendix B clarifications on Weak End System Model 2083 Changes from RFC5558 to -00: 2085 o New appendix on RLOC configuration on VET interfaces. 2087 Author's Address 2089 Fred L. Templin (editor) 2090 Boeing Research & Technology 2091 P.O. Box 3707 MC 7L-49 2092 Seattle, WA 98124 2093 USA 2095 Email: fltemplin@acm.org