idnits 2.17.1 draft-templin-intarea-vet-13.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 non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 (June 2, 2010) is 5039 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) == Unused Reference: 'RFC0792' is defined on line 1519, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1600, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-13 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-03) exists of draft-carpenter-flow-ecmp-02 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-11 == 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-02 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-07 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-10 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-02 == Outdated reference: A later version (-03) exists of draft-nakibly-v6ops-tunnel-loops-02 == Outdated reference: A later version (-05) exists of draft-russert-rangers-02 == Outdated reference: A later version (-17) exists of draft-templin-iron-01 -- 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 (~~), 16 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 June 2, 2010 5 Expires: December 4, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-13.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 December 4, 2010. 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 . . . . . . . . . 12 62 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 14 63 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 14 64 4.2.2. Provider-Aggregated (PA) EID Prefix 65 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 66 4.2.3. Provider-Independent (PI) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 68 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 18 69 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 18 70 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 18 71 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 19 72 5.1.1. PI Prefix Routing Considerations . . . . . . . . . . . 19 73 5.2. Default Route Configuration . . . . . . . . . . . . . . . 20 74 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 20 75 5.4. Next Hop Determination . . . . . . . . . . . . . . . . . . 20 76 5.5. VET Interface Encapsulation/Decapsulation . . . . . . . . 21 77 5.5.1. Inner Network Layer Protocol . . . . . . . . . . . . . 21 78 5.5.2. Mid-Layer Encapsulation . . . . . . . . . . . . . . . 22 79 5.5.3. SEAL Encapsulation . . . . . . . . . . . . . . . . . . 22 80 5.5.4. Outer UDP Header Encapsulation . . . . . . . . . . . . 22 81 5.5.5. Outer IP Header Encapsulation . . . . . . . . . . . . 23 82 5.5.6. Decapsulation . . . . . . . . . . . . . . . . . . . . 23 83 5.6. Mobility and Multihoming Considerations . . . . . . . . . 24 84 5.7. Neighbor Coordination on VET Interfaces using SEAL . . . . 24 85 5.7.1. Router Discovery . . . . . . . . . . . . . . . . . . . 25 86 5.7.2. Neighbor Unreachability Detection . . . . . . . . . . 25 87 5.7.3. Redirect Function . . . . . . . . . . . . . . . . . . 25 88 5.7.4. Mobility . . . . . . . . . . . . . . . . . . . . . . . 28 89 5.8. Neighbor Coordination on VET Interfaces using IPsec . . . 29 90 5.9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29 91 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 30 92 5.11. Enterprise Network Partitioning . . . . . . . . . . . . . 30 93 5.12. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 31 94 5.13. Support for Legacy ISATAP Services . . . . . . . . . . . . 31 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 97 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 32 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 103 Appendix A. Duplicate Address Detection (DAD) Considerations . . 39 104 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 40 105 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 42 106 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 43 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 109 1. Introduction 111 Enterprise networks [RFC4852] connect hosts and routers over various 112 link types (see [RFC4861], Section 2.2). The term "enterprise 113 network" in this context extends to a wide variety of use cases and 114 deployment scenarios. For example, an "enterprise" can be as small 115 as a SOHO network, as complex as a multi-organizational corporation, 116 or as large as the global Internet itself. ISP networks are another 117 example use case that fits well with the VET enterprise network 118 model. Mobile Ad hoc Networks (MANETs) [RFC2501] can also be 119 considered as a challenging example of an enterprise network, in that 120 their topologies may change dynamically over time and that they may 121 employ little/no active management by a centralized network 122 administrative authority. These specialized characteristics for 123 MANETs require careful consideration, but the same principles apply 124 equally to other enterprise network scenarios. 126 This document specifies a Virtual Enterprise Traversal (VET) 127 abstraction for autoconfiguration and internetworking operation, 128 where addresses of different scopes may be assigned on various types 129 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 130 [RFC2460] are discussed within this context (other network layer 131 protocols are also considered). The use of standard DHCP [RFC2131] 132 [RFC3315] is assumed 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 must have a means for supporting both Provider- 177 Independent (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 must be mapped to 383 RLOC 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 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 404 NBMA - Non-Broadcast, Multiple Access 405 ND - Neighbor Discovery 406 NS/NA - Neighbor Solicitation/Advertisement 407 PIO - Prefix Information Option 408 PRL - Potential Router List 409 PRLNAME - Identifying name for the PRL 410 RIB - Routing Information Base 411 RIO - Route Information Option 412 RPF - Reverse Path Forwarding 413 RS/RA - Router Solicitation/Advertisement 414 SCMP - SEAL Control Message Protocol 415 SEAL - Subnetwork Encapsulation and Adaptation Layer 416 SLAAC - IPv6 StateLess Address AutoConfiguration 418 3. Enterprise Network Characteristics 420 Enterprise networks consist of links that are connected by Enterprise 421 Routers (ERs) as depicted in Figure 1. ERs typically participate in 422 a routing protocol over enterprise-interior interfaces to discover 423 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 424 Enterprise Border Routers (EBRs) are ERs that connect edge networks 425 to the enterprise network and/or join multiple enterprise networks 426 together. Enterprise Border Gateways (EBGs) are EBRs that connect 427 enterprise networks to provider networks. 429 Conceptually, an ER embodies both a host function and router 430 function, and supports communications according to the weak end- 431 system model [RFC1122]. The router function engages in the 432 enterprise-interior routing protocol, connects any of the ER's edge 433 networks to the enterprise networks, and may also connect the 434 enterprise network to provider networks (see Figure 1). The host 435 function typically supports network management applications, but may 436 also support diverse applications typically associated with general- 437 purpose computing platforms. 439 An enterprise network may be as simple as a small collection of ERs 440 and their attached edge networks; an enterprise network may also 441 contain other enterprise networks and/or be a subnetwork of a larger 442 enterprise network. An enterprise network may further encompass a 443 set of branch offices and/or nomadic hosts connected to a home office 444 over one or several service providers, e.g., through Virtual Private 445 Network (VPN) tunnels. Finally, an enterprise network may contain 446 many internal partitions that are logical or physical groupings of 447 nodes for the purpose of load balancing, organizational separation, 448 etc. In that case, each internal partition resembles an individual 449 segment of a bridged LAN. 451 Enterprise networks that comprise link types with sufficiently 452 similar properties (e.g., Layer 2 (L2) address formats, maximum 453 transmission units (MTUs), etc.) can configure a sub-IP layer routing 454 service such that IP sees the network as an ordinary shared link the 455 same as for a (bridged) campus LAN. In that case, a single IP hop is 456 sufficient to traverse the network without need for encapsulation. 457 Enterprise networks that comprise link types with diverse properties 458 and/or configure multiple IP subnets must also provide an enterprise- 459 interior routing service that operates as an IP layer mechanism. In 460 that case, multiple IP hops may be necessary to traverse the network 461 such that care must be taken to avoid multi-link subnet issues 462 [RFC4903]. 464 In addition to other interface types, VET nodes configure VET 465 interfaces that view all other nodes on the VET link as neighbors on 466 a virtual NBMA link. VET nodes configure a separate VET interface 467 for each distinct VET link to which they connect, and discover other 468 EBRs on the link that can be used for forwarding packets to off-link 469 destinations. 471 For each distinct enterprise network, a trust basis must be 472 established and consistently applied. For example, in enterprise 473 networks in which EBRs establish symmetric security associations, 474 mechanisms such as IPsec [RFC4301] can be used to assure 475 authentication and confidentiality. In other enterprise network 476 scenarios, asymmetric securing mechanisms such as SEcure Neighbor 477 Discovery (SEND) [RFC3971] may be necessary. Still other enterprise 478 networks may find it sufficient to employ mechanisms (e.g., SEAL 479 [I-D.templin-intarea-seal]) that can defeat off-path attacks. 481 Finally, in enterprise networks with a centralized management 482 structure (e.g., a corporate campus network), an overlay routing/ 483 mapping service and a synchronized set of EBGs can provide sufficient 484 infrastructure support for virtual enterprise traversal. In that 485 case, the EBGs can provide a "default mapper" [I-D.jen-apt] service 486 used for short-term packet forwarding until route-optimized paths 487 between neighboring EBRs can be established. In enterprise networks 488 with a distributed management structure (e.g., disconnected MANETs), 489 peer-to-peer coordination between the EBRs themselves may be 490 required. Recognizing that various use cases will entail a continuum 491 between a fully distributed and fully centralized approach, the 492 following sections present the mechanisms of Virtual Enterprise 493 Traversal as they apply to a wide variety of scenarios. 495 4. Autoconfiguration 497 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 498 specified in the following subsections. 500 4.1. Enterprise Router (ER) Autoconfiguration 502 ERs configure enterprise-interior interfaces and engage in any 503 routing protocols over those interfaces. 505 When an ER joins an enterprise network, it first configures an IPv6 506 link-local address on each enterprise-interior interface and 507 configures an IPv4 link-local address on each enterprise-interior 508 interface that requires an IPv4 link-local capability. IPv6 link- 509 local address generation mechanisms include Cryptographically 510 Generated Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses 511 [RFC4941], StateLess Address AutoConfiguration (SLAAC) using EUI-64 512 interface identifiers [RFC4291] [RFC4862], etc. The mechanisms 513 specified in [RFC3927] provide an IPv4 link-local address generation 514 capability. 516 Next, the ER configures one or more RLOCs and engages in any routing 517 protocols on its enterprise-interior interfaces. The ER can 518 configure RLOCs via explicit management, DHCP autoconfiguration, 519 pseudo-random self-generation from a suitably large address pool, or 520 through an alternate autoconfiguration mechanism. The ER may 521 optionally configure and assign a separate RLOC for each underlying 522 interface, or it may configure only a single RLOC and assign it to a 523 VET interface configured over the underlying interfaces (see Section 524 4.2.1). In the latter case, the ER can use the VET interface for 525 link layer multiplexing and traffic engineering purposes as specified 526 in Appendix B. 528 Alternatively (or in addition), the ER can request RLOC prefix 529 delegations via an automated prefix delegation exchange over an 530 enterprise-interior interface and can assign the prefix(es) on 531 enterprise-edge interfaces. Note that in some cases, the same 532 enterprise-edge interfaces may assign both RLOC and EID addresses if 533 there is a means for source address selection. In other cases (e.g., 534 for separation of security domains), RLOCs and EIDs must be assigned 535 on separate sets of enterprise-edge interfaces. 537 Pseudo-random self-generation of IPv6 RLOCs can be from a large 538 public or local-use IPv6 address range (e.g., IPv6 Unique Local 539 Addresses [RFC4193]). Pseudo-random self-generation of IPv4 RLOCs 540 can be from a large public or local-use IPv4 address range (e.g., 541 [RFC1918]). When self-generation is used alone, the ER must 542 continuously monitor the RLOCs for uniqueness, e.g., by monitoring 543 the enterprise-interior routing protocol. (Note however that anycast 544 RLOCs may be assigned to multiple enterprise interior interfaces; 545 hence, monitoring for uniqueness applies only to RLOCs that are 546 intended as unicast.) 548 DHCP generation of RLOCs uses standard DHCP procedures but may 549 require support from relays within the enterprise network. For 550 DHCPv6, relays that do not already know the RLOC of a server within 551 the enterprise network forward requests to the 'All_DHCP_Servers' 552 site-scoped IPv6 multicast group [RFC3315]. For DHCPv4, relays that 553 do not already know the RLOC of a server within the enterprise 554 network forward requests to the site-scoped IPv4 multicast group 555 address 'All_DHCPv4_Servers', which should be set to 239.255.2.1 556 unless an alternate multicast group for the site is known. DHCPv4 557 servers that delegate RLOCs should therefore join the 558 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 559 received for that group. 561 A combined approach using both DHCP and self-generation is also 562 possible when the ER configures both a DHCP client and relay that are 563 connected, e.g., via a pair of back-to-back connected Ethernet 564 interfaces, a tun/tap interface, a loopback interface, inter-process 565 communication, etc. The ER first self-generates an RLOC from a 566 temporary addressing range used only for the bootstrapping purpose of 567 procuring an actual RLOC taken from a preferred addressing range. 568 The ER then engages in the enterprise-interior routing protocol and 569 performs a DHCP client/relay exchange using the temporary RLOC as the 570 address of the relay. When the DHCP server delegates an actual RLOC 571 address/prefix, the ER abandons the temporary RLOC and re-engages in 572 the enterprise-interior routing protocol using an RLOC taken from the 573 delegation. 575 In some enterprise network use cases (e.g., MANETs), assignment of 576 RLOCs on enterprise-interior interfaces as singleton addresses (i.e., 577 as addresses with /32 prefix lengths for IPv4, or as addresses with 578 /128 prefix lengths for IPv6) may be necessary to avoid multi-link 579 subnet issues. In other use cases, assignment of an RLOC on a VET 580 interface as specified in Appendix B can provide link layer 581 multiplexing and traffic engineering over multiple underlying 582 interfaces using only a single IP address. 584 4.2. Enterprise Border Router (EBR) Autoconfiguration 586 EBRs are ERs that configure VET interfaces over distinct sets of 587 underlying interfaces belonging to the same enterprise network; an 588 EBR can connect to multiple enterprise networks, in which case it 589 would configure multiple VET interfaces. In addition to the ER 590 autoconfiguration procedures specified in Section 4.1, EBRs perform 591 the following autoconfiguration operations. 593 4.2.1. VET Interface Initialization 595 EBRs configure a VET interface over a set of underlying interfaces 596 belonging to the same enterprise network such that all other nodes on 597 the VET link appear as single-hop neighbors from the standpoint of 598 the inner network layer protocol through the use of encapsulation. 599 If there are multiple inner network layer protocols (e.g., IPv4, 600 IPv6, OSI, etc.) the EBR configures a separate VET interface for each 601 protocol. 603 After the EBR configures a VET interface, it binds an RLOC to the 604 interface to serve as the source address for outer IP packets then 605 assigns link-local addresses to the interface if necessary. When 606 IPv6 and IPv4 are used as the inner/outer protocols (respectively), 607 the EBR autoconfigures an IPv6 link-local address on the VET 608 interface formed as specified in Sections 6.1 and 6.2 of [RFC5214]. 610 Link-local address configuration for other inner/outer protocol 611 combinations is through administrative configuration, random self- 612 generation (e.g., [RFC4941], etc.) or through an unspecified 613 alternate method. However, link-local address configuration for 614 other inner/outer protocol combinations may not be necessary if a 615 non-link-local address can be configured through other means (e.g., 616 administrative configuration, DHCP, etc.). 618 The EBR next discovers a Potential Router List (PRL) that includes 619 the RLOC addresses of EBGs. The PRL names the VET interface, and is 620 specific to the address family of the inner network layer protocol 621 (e.g., IPv4, IPv6, OSI, etc.). If there are multiple address 622 families, then there will be multiple VET interfaces; each with its 623 own PRL. 625 The PRL can be discovered through information conveyed in the 626 enterprise-interior routing protocol, through the mechanisms outlined 627 in Section 8.3.2 of [RFC5214], through a DHCP option 628 [I-D.templin-isatap-dhcp], etc. In multicast-capable enterprise 629 networks, EBRs can also listen for advertisements on the 'rasadv' 630 [RASADV] multicast group address. 632 Whether or not routing information is available, the EBR can resolve 633 an identifying name for the PRL ('PRLNAME') formed as 634 'hostname.domainname', where 'hostname' is an enterprise-specific 635 name string and 'domainname' is an enterprise-specific Domain Name 636 System (DNS) suffix [RFC1035]. The EBR discovers 'PRLNAME' through 637 manual configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 638 protocol advertisements, link-layer information (e.g., an IEEE 802.11 639 Service Set Identifier (SSID)), or through some other means specific 640 to the enterprise network. The EBR can also obtain 'PRLNAME' as part 641 of an arrangement with a private-sector PI prefix vendor (see: 642 Section 4.2.3). 644 In the absence of other information, the EBR sets the 'hostname' 645 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 646 component to an enterprise-specific DNS suffix (e.g., "example.com"). 647 Isolated enterprise networks that do not connect to the outside world 648 may have no enterprise-specific DNS suffix, in which case the 649 'PRLNAME' consists only of the 'hostname' component. (Note that the 650 default hostname "isatapv2" is intentionally distinct from the 651 convention specified in [RFC5214].) 653 After discovering 'PRLNAME', the EBR resolves the name into a list of 654 RLOC addresses through a name service lookup. For centrally managed 655 enterprise networks, the EBR resolves 'PRLNAME' using an enterprise- 656 local name service (e.g., the DNS). For enterprises with no 657 centralized management structure, the EBR resolves 'PRLNAME' using 658 Link-Local Multicast Name Resolution (LLMNR) [RFC4795] over the VET 659 interface. In that case, all EBGs in the PRL respond to the LLMNR 660 query, and the EBR accepts the union of all responses. 662 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 664 EBRs that connect their enterprise networks to a provider network 665 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 666 stateless autoconfiguration mechanisms. The stateful and stateless 667 approaches are discussed in the following subsections. 669 4.2.2.1. Stateful Prefix Delegation 671 For IPv4, EBRs acquire IPv4 PA EID prefixes via an automated IPv4 672 prefix delegation exchange, explicit management, etc. 674 For IPv6, EBRs acquire IPv6 PA EID prefixes via DHCPv6 Prefix 675 Delegation exchanges with an EBG acting as a DHCP relay/server. In 676 particular, the EBR (acting as a requesting router) can use DHCPv6 677 prefix delegation [RFC3633] over the VET interface to obtain prefixes 678 from the server (acting as a delegating router). The EBR obtains 679 prefixes using either a 2-message or 4-message DHCPv6 exchange 680 [RFC3315]. For example, to perform the 2-message exchange, the EBR's 681 DHCPv6 client forwards a Solicit message with an IA_PD option to its 682 DHCPv6 relay, i.e., the EBR acts as a combined client/relay (see 683 Section 4.1). The relay then forwards the message over the VET 684 interface using VET encapsulation (see: Section 5.4) to an EBG which 685 either services the request or relays it further. The forwarded 686 Solicit message will elicit a reply from the server containing prefix 687 delegations. The EBR can also propose a specific prefix to the 688 DHCPv6 server per Section 7 of [RFC3633]. The server will check the 689 proposed prefix for consistency and uniqueness, then return it in the 690 reply to the EBR if it was able to perform the delegation. 692 After the EBR receives IPv4 and/or IPv6 prefix delegations, it can 693 provision the prefixes on enterprise-edge interfaces as well as on 694 other VET interfaces configured over child enterprise networks for 695 which it acts as an EBG. The EBR can also provision the prefixes on 696 enterprise-interior interfaces to service any hosts attached to the 697 link. 699 The prefix delegations remain active as long as the EBR continues to 700 renew them before lease lifetimes expire. The lease lifetime also 701 keeps the delegation state active even if communications between the 702 EBR and delegation server are disrupted for a period of time (e.g., 703 due to an enterprise network partition, power failure, etc.). 705 Stateful prefix delegation for non-IP protocols is out of scope. 707 4.2.2.2. Stateless Prefix Delegation 709 When IPv6 and IPv4 are used as the inner and outer protocols, 710 respectively, a stateless IPv6 PA prefix delegation capability is 711 available using the mechanisms specified in 712 [RFC5569][I-D.ietf-softwire-ipv6-6rd]. EBRs can use these mechanisms 713 to statelessly configure IPv6 PA prefixes that embed one of the EBR's 714 IPv4 RLOCs. 716 Using this stateless prefix delegation, if the IPv4 RLOC changes the 717 IPv6 prefix also changes and the EBR must renumber any interfaces on 718 which sub-prefixes from the prefix are assigned. This method may 719 therefore be most suitable for enterprise networks in which IPv4 RLOC 720 assignments rarely change, or in enterprise networks in which only 721 services that do not depend on a long-term stable IPv6 prefix (e.g., 722 client-side web browsing) are used. 724 Stateless prefix delegation for other protocol combinations is out of 725 scope. 727 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 729 EBRs can acquire Provider Independent (PI) prefixes to facilitate 730 multihoming, mobility and traffic engineering without requiring site- 731 wide renumbering events. These PI prefixes are made available to 732 EBRs through provider-independent registries and without need to 733 coordinate with Internet Service Provider networks. 735 EBRs that connect major enterprise networks (e.g., large 736 corporations, academic campuses, ISP networks, etc.) to a parent 737 enterprise network and/or the global Internet can acquire highly- 738 aggregated PI prefixes (e.g., an IPv6 ::/20, an IPv4 /16, etc.) 739 through a registration authority such as the Internet Assigned 740 Numbers Authority (IANA) or a major regional Internet registry. EBRs 741 that connect small enterprise networks (e.g., SOHO networks, MANETs, 742 etc.) to a parent enterprise network can acquire de-aggregated PI 743 prefixes through arrangements with a PI prefix commercial vendor 744 organization. 746 After an EBR receives PI prefixes, it can sub-delegate portions of 747 the prefixes on enterprise-edge interfaces, on other VET interfaces 748 for which it is configured as an EBG and on enterprise-interior 749 interfaces to service any hosts attached to the link. The EBR can 750 also sub-delegate portions of its PI prefixes to requesting routers 751 within child enterprise networks. These requesting routers consider 752 their sub-delegated portions of the PI prefix as PA, and consider the 753 delegating routers as their points of connection to a provider 754 network. 756 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 758 EBGs are EBRs that connect child enterprise networks to provider 759 networks via provider-edge interfaces and/or via VET interfaces 760 configured over parent enterprise networks. EBGs autoconfigure their 761 provider-edge interfaces in a manner that is specific to the provider 762 connections, and they autoconfigure their VET interfaces that were 763 configured over parent enterprise networks using the EBR 764 autoconfiguration procedures specified in Section 4.2. 766 For each of its VET interfaces configured over a child enterprise 767 network, the EBG initializes the interface the same as for an 768 ordinary EBR (see Section 4.2.1). It must then arrange to add one or 769 more of its RLOCs associated with the child enterprise network to the 770 PRL as specified in [RFC5214], Section 9. In particular, for each 771 VET interface configured over a child enterprise network the EBG adds 772 the RLOCs to name service resource records for 'PRLNAME'. 774 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 775 configured over child enterprise networks with a distributed 776 management structure. 778 EBGs configure a DHCP relay/server on VET interfaces configured over 779 child enterprise networks that require DHCP services. 781 To avoid looping, EBGs must not configure a default route on a VET 782 interface configured over a child enterprise network interface. 784 4.4. VET Host Autoconfiguration 786 Nodes that cannot be attached via an EBR's enterprise-edge interface 787 (e.g., nomadic laptops that connect to a home office via a Virtual 788 Private Network (VPN)) can instead be configured for operation as a 789 simple host connected to the VET interface. Such VET hosts perform 790 the same VET interface initialization and border gateway discovery 791 procedures as specified for EBRs in Section 4.2.1, but they configure 792 their VET interfaces as host interfaces (and not router interfaces). 793 Note also that a node may be configured as a host on some VET 794 interfaces and as an EBR/EBG on other VET interfaces. 796 5. Internetworking Operation 798 Following the autoconfiguration procedures specified in Section 4, 799 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 800 operations as discussed in the following sections. 802 5.1. Routing Protocol Participation 804 ERs engage in any intra-enterprise routing protocols over enterprise- 805 interior interfaces to exchange routing information for forwarding IP 806 packets with RLOC addresses. EBRs and EBGs can additionally engage 807 in any inter-enterprise routing protocols over VET, enterprise-edge 808 and provider-edge interfaces to exchange routing information for 809 forwarding IP packets with EID addresses. Note that the EID-based 810 inter-enterprise IP routing domains are separate and distinct from 811 any RLOC-based enterprise interior IP routing domains. 813 Routing protocol participation on non-multicast VET interfaces uses 814 the NBMA interface model, e.g., in the same manner as for OSPF over 815 NBMA interfaces [RFC5340], while routing protocol participation on 816 multicast-capable VET interfaces uses the standard multicast 817 interface model. EBRs use the list of EBGs in the PRL (see: 818 Section 4.2.1) as an initial list of neighbors for inter-enterprise 819 routing protocol participation. 821 5.1.1. PI Prefix Routing Considerations 823 EBRs that connect large enterprise networks to the global Internet 824 advertise their EID PI prefixes directly into the Internet default- 825 free RIB via the Border Gateway Protocol (BGP) [RFC4271] the same as 826 for a major service provider network. EBRs that connect large 827 enterprise networks to provider networks can instead advertise their 828 EID PI prefixes into the providers' routing system(s) if the provider 829 networks are configured to accept them. 831 EBRs that connect small enterprise networks to provider networks must 832 obtain one or more public IP address(es) (i.e., either EID or RLOC IP 833 address) then dynamically register the mapping of their PI prefixes 834 to the public IP address. The registrations are through secured end- 835 to-end exchanges between the EBR and a server in the PI prefix 836 vendor's network (e.g., through a vendor-specific short http(s) 837 transaction). The PI prefix vendor network then acts as a virtual 838 "home" enterprise network that connects its customer small enterprise 839 networks to the Internet routing system with no arrangements needed 840 with the customers' Internet Service Providers. The customer small 841 enterprise networks in turn appear as mobile components of the PI 842 prefix vendor's network, i.e., the customer networks are always "away 843 from home". 845 Further details on routing for PI prefixes is discussed in "The 846 Internet Routing Overlay Network (IRON)" [I-D.templin-iron] and "Fib 847 Suppression with Virtual Aggregation" [I-D.ietf-grow-va]. 849 5.2. Default Route Configuration 851 Configuration of default routes in the presence of VET interfaces 852 must be carefully coordinated according to the inner and outer 853 network protocols. If the inner and outer protocols are different 854 (e.g., IPv6 within IPv4) then a default route of the inner protocol 855 version can be configured on a VET interface while a default route of 856 the outer protocol version can be configured on an underlying 857 interface. If the inner and outer protocols are the same however 858 (e.g., IPv4 within IPv4), care must be taken in setting the default 859 route to avoid ambiguity. For example, if the default route were 860 configured on the VET interface great care must be taken by 861 configuring more-specific routes on underlying interfaces to avoid 862 looping. 864 5.3. Address Selection 866 When permitted by policy and supported by enterprise interior 867 routing, VET nodes can avoid encapsulation through communications 868 that directly invoke the outer IP protocol using RLOC addresses 869 instead of EID addresses for end-to-end communications. For example, 870 an enterprise network that provides native IPv4 intra-enterprise 871 services can provide continued support for native IPv4 communications 872 even when encapsulated IPv6 services are available for inter- 873 enterprise communications. In other enterprise network scenarios, 874 the use of EID-based communications (i.e., instead of RLOC-based 875 communications) may be necessary and/or beneficial to support address 876 scaling, NAT traversal avoidance, security domain separation, site 877 multihoming, traffic engineering, etc. . 879 VET nodes can use source address selection rules (e.g., based on name 880 service information) to determine whether to use EID-based or RLOC- 881 based addressing. The remainder of this section discusses 882 internetworking operation for EID-based communications using the VET 883 interface abstraction. 885 5.4. Next Hop Determination 887 VET nodes perform normal next-hop determination via longest prefix 888 match, and send packets according to the most-specific matching entry 889 in the FIB. If the FIB entry has multiple next-hop addresses, the 890 EBR selects the next-hop with the best metric value. If multiple 891 next hops have the same metric value, the VET node can use Equal Cost 892 Multi Path (ECMP) to forward different flows via different next-hop 893 addresses, where flows are determined, e.g., by computing a hash of 894 the inner packet's source address, destination address and flow label 895 fields. 897 As a last resort when there is no matching entry in the FIB (i.e., 898 not even default), VET nodes can discover next-hop addresses within 899 the enterprise network through on-demand name service queries for the 900 EID prefix taken from a packet's destination address (or, by some 901 other inner address to outer address mapping mechanism). For 902 example, for the IPv6 destination address '2001:DB8:1:2::1' and 903 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 904 service lookup for the domain name: 905 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 907 Name-service lookups in enterprise networks with a centralized 908 management structure use an infrastructure-based service, e.g., an 909 enterprise-local DNS. Name-service lookups in enterprise networks 910 with a distributed management structure and/or that lack an 911 infrastructure-based name service instead use LLMNR over the VET 912 interface. When LLMNR is used, the EBR that performs the lookup 913 sends an LLMNR query (with the prefix taken from the IP destination 914 address encoded in dotted-nibble format as shown above) and accepts 915 the union of all replies it receives from other EBRs on the VET 916 interface. When an EBR receives an LLMNR query, it responds to the 917 query IFF it aggregates an IP prefix that covers the prefix in the 918 query. If the name-service lookup succeeds, it will return RLOC 919 addresses (e.g., in DNS A records) that correspond to next-hop EBRs 920 to which the VET node can forward packets. 922 5.5. VET Interface Encapsulation/Decapsulation 924 VET interfaces encapsulate inner network layer packets in any 925 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 926 etc.) followed by a SEAL header (if necessary) followed by an outer 927 UDP header (if necessary) followed by an outer IP header. Following 928 all encapsulations, the VET interface submits the encapsulated packet 929 to the outer IP forwarding engine for transmission on an underlying 930 interface. The following sections provide further details on 931 encapsulation: 933 5.5.1. Inner Network Layer Protocol 935 The inner network layer protocol sees the VET interface as an 936 ordinary network interface, and views the outer network layer 937 protocol as an L2 transport. The inner- and outer network layer 938 protocol types are mutually independent and can be used in any 939 combination. Inner network layer protocol types include IPv6 940 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 941 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 943 5.5.2. Mid-Layer Encapsulation 945 VET interfaces that use mid-layer encapsulations encapsulate each 946 inner network layer packet in any mid-layer headers and trailers as 947 the first step in a potentially multi-layer encapsulation. 949 5.5.3. SEAL Encapsulation 951 Following any mid-layer encapsulations, VET interfaces that use SEAL 952 add a SEAL header as specified in [I-D.templin-intarea-seal]. 953 Inclusion of a SEAL header must be applied uniformly between all 954 nodes on the VET link. Note that when a VET interface sends a SEAL- 955 encapsulated packet to a VET node that does not use SEAL 956 encapsulation, it may receive an ICMP "port unreachable" or "protocol 957 unreachable" depending on whether/not an outer UDP header is 958 included. 960 SEAL encapsulation should be used on VET links that require path MTU 961 mitigations due to encapsulation overhead and/or mechanisms for VET 962 interface neighbor coordination. When SEAL encapsulation is used, 963 the VET interface sets the 'Next Header' value in the SEAL header to 964 the IP protocol number associated with either the mid-layer 965 encapsulation or the IP protocol number of the inner network layer 966 (if no mid-layer encapsulation is used). 968 The VET interface sets the other fields in the SEAL header as 969 specified in [I-D.templin-intarea-seal]. For SEAL first-segments, 970 the VET interface also sets the R and D flags in the SEAL header in 971 order to control the operation of the SCMP Redirect function (see: 972 Section 5.7.3). The VET interface sets R=1 in the SEAL header of 973 each packet for which it is willing to receive a Redirect message and 974 sets D=1 in the SEAL header of each packet that should be discarded 975 after determining whether a redirect must be sent but before 976 forwarding the packet to the next hop. The VET interface otherwise 977 sets R=0 and D=0. 979 5.5.4. Outer UDP Header Encapsulation 981 Following any mid-layer and/or SEAL encapsulations, VET interfaces 982 that use UDP encapsulation add an outer UDP header. Inclusion of an 983 outer UDP header must be applied uniformly between all nodes on the 984 VET link. Note that when a VET interface sends a UDP-encapsulated 985 packet to a node that does not recognize the UDP port number, it may 986 receive an ICMP "port unreachable" message. 988 UDP encapsulation should be used on VET links that may traverse 989 Network Address Translators (NATs) and/or legacy networking gear that 990 only recognizes certain network layer protocols, e.g., Equal Cost 991 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc. 992 When UDP encapsulation is used, the VET interface encapsulates the 993 mid-layer packet in an outer UDP header then sets the UDP port 994 numbers as specified for the outermost mid-layer protocol (e.g., 995 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 996 is used as the outermost mid-layer protocol, the VET interface sets 997 the UDP source port number to a hash calculated over the inner 998 network layer {destination, source} values or (optionally) over the 999 inner network layer {dest addr, source addr, protocol, dest port, 1000 source port} values. The VET interface uses a hash function of its 1001 own choosing, but it must be consistent in the manner in which the 1002 hash is applied.. 1004 For VET links configured over IPv4 enterprise networks, the VET 1005 interface sets the UDP checksum field to zero. For VET links 1006 configured over IPv6 enterprise networks, the VET interface must 1007 instead calculate the UDP checksum and set the calculated value in 1008 the checksum field as required for UDP operation over IPv6. 1010 5.5.5. Outer IP Header Encapsulation 1012 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1013 interface adds an outer IP header. Outer IP header construction is 1014 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1015 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1016 Service/Traffic Class" and "Congestion Experienced" values in the 1017 inner network layer header are copied into the corresponding fields 1018 in the outer IP header. The VET interface also sets the IP protocol 1019 number to the appropriate value for the first protocol layer within 1020 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1021 as the outer IP protocol, the VET interface sets the flow label value 1022 in the outer IPv6 header the same as described in 1023 [I-D.carpenter-flow-ecmp]. 1025 5.5.6. Decapsulation 1027 When a VET interface receives an encapsulated packet, it retains the 1028 outer headers and processes the SEAL header as specified in 1029 [I-D.templin-intarea-seal]. Following SEAL-layer reassembly (if 1030 necessary), the VET interface further examines the R and D bits in 1031 the SEAL header to determine whether Redirects are permitted and 1032 whether the packet should be discarded following redirect 1033 determination (see: Section 5.7.3). 1035 Next, if the packet will be forwarded from the receiving VET 1036 interface into a forwarding VET interface, the VET node copies the 1037 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1038 Experienced" values in the outer IP header received on the receiving 1039 VET interface into the corresponding fields in the outer IP header to 1040 be sent over the forwarding VET interface (i.e., the values are 1041 transferred between outer headers and *not* copied from the inner 1042 network layer header). This is true even if the packet is forwarded 1043 out the same VET interface that it arrived on, and necessary to 1044 support diagnostic functions (e.g., traceroute) and avoid looping. 1046 During decapsulation, when the next-hop is via a non-VET interface, 1047 the "Congestion Experienced" value in the outer IP header is copied 1048 into the corresponding field in the inner network layer header. 1050 5.6. Mobility and Multihoming Considerations 1052 EBRs that travel between distinct enterprise networks must either 1053 abandon their PA prefixes that are relative to the "old" enterprise 1054 and obtain PA prefixes relative to the "new" enterprise, or somehow 1055 coordinate with a "home" enterprise to retain ownership of the 1056 prefixes. In the first instance, the EBR would be required to 1057 coordinate a network renumbering event using the new PA prefixes 1058 [RFC4192][RFC5887]. In the second instance, an ancillary mobility 1059 management mechanism must be used. 1061 EBRs can retain their PI prefixes as they travel between distinct 1062 enterprise networks as long as they update their PI prefix to public 1063 IP address mappings with their PI prefix vendors. This is 1064 accomplished by performing the same PI prefix vendor-specific short 1065 transactions as specified in Section 5.1.1. In this way, EBRs can 1066 update their PI prefix to RLOC mappings in real time as their RLOCs 1067 change. 1069 The EBGs of a multihomed enterprise network should participate in a 1070 private inner network layer routing protocol instance between 1071 themselves (possibly over an alternate topology) to accommodate 1072 network partitions/merges as well as intra-enterprise mobility 1073 events. 1075 5.7. Neighbor Coordination on VET Interfaces using SEAL 1077 VET interfaces that use SEAL use the SEAL Control Message Protocol 1078 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1079 coordinate reachability, routing information, and mappings between 1080 the inner and outer network layer protocols. SCMP directly parallels 1081 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1082 [RFC4443] protocols, but operates from within the tunnel and supports 1083 operation for any combinations of inner and outer network layer 1084 protocols. 1086 The following subsections discuss VET interface neighbor coordination 1087 using SCMP: 1089 5.7.1. Router Discovery 1091 VET hosts and EBRs can send SCMP Router Solicitation (RS) messages to 1092 one or more EBGs in the PRL to receive solicited SCMP Router 1093 Advertisements (RAs). They then process the RAs the same as for IPv6 1094 ND RA messages, except that they ignore the 'M' and 'O' bits. 1096 When an EBG receives an SCMP RS message on a VET interface, it 1097 prepares a solicited SCMP RA message. The RA includes Router 1098 Lifetimes, Default Router Preferences, PIOs and any other options/ 1099 parameters that the EBG is configured to include. The EBG may also 1100 include Route Information Options (RIOs) formatted as specified in 1101 Section 5.7.3, i.e., the RIO may contain both IPv6 and non-IPv6 1102 prefixes in RIOs as identified by an Address Family designator. 1104 5.7.2. Neighbor Unreachability Detection 1106 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1107 interface neighbors by monitoring hints of forward progress as 1108 evidence that a neighbor is reachable. SEAL includes an explicit 1109 acknowledgement mechanism that can provide hints of forward progress. 1110 When data packets are flowing, the VET node can periodically set the 1111 A bit in data packets to elicit Neighbor Advertisement (NA) messages 1112 from the neighbor. When no data packets are flowing, the VET node 1113 can send periodic Neighbor Solicitation (NS) messages for the same 1114 purpose. 1116 Responsiveness to routing changes is directly related to the delay in 1117 detecting that a neighbor has gone unreachable. In order to provide 1118 responsiveness comparable to dynamic routing protocols, a reasonably 1119 short neighbor reachable time (e.g., 5sec) should be used. 1121 Additionally, a VET node may receive outer IP ICMP "Destination 1122 Unreachable; net / host unreachable" messages from an ER on the path 1123 indicating that the path to a VET neighbor may be failing. The node 1124 should first check the packet-in-error to obtain reasonable assurance 1125 that the ICMP message is authentic. If the node receives excessive 1126 ICMP unreachable errors through multiple RLOCs associated with the 1127 same FIB entry, it should delete the FIB entry and allow subsequent 1128 packets to flow through a different route. 1130 5.7.3. Redirect Function 1132 A VET node (i.e., the redirectee) may receive a redirect message when 1133 it forwards packets over a VET interface to a neighboring VET node 1134 (i.e., the redirector). The redirector will forward the packet and 1135 return an SCMP Redirect message if necessary to inform the redirectee 1136 of a better next hop. Unlike ordinary ICMP redirects, the redirector 1137 sends an SCMP Redirect message (subject to rate limiting) whenever it 1138 receives a packet with R=1 in the SEAL header for which there is a 1139 better next hop on the same VET interface that it arrived on 1140 regardless of whether the inner source address of the packet was on- 1141 link. The redirector also discards packets with D=1 in the SEAL 1142 header after determining whether a redirect must be sent and before 1143 forwarding the packet to the next hop. 1145 The SCMP Redirect message is formatted the same as for ordinary 1146 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1147 the Destination and Target Address fields are unnecessary and 1148 therefore omitted. The format of the SCMP Redirect message is shown 1149 in Figure 2 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Type = 137 | Code = 0 | Checksum | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Reserved | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Options ... 1158 +-+-+-+-+-+-+-+-+-+-+-+- 1160 Figure 2: SCMP Redirect Message Format 1162 The redirector then adds any necessary Options to the Redirect 1163 message. It first includes one or more Target Link-Layer Address 1164 Options (TLLAOs) (see: Section 4.6.1 of [RFC4861]) that include RLOCs 1165 corresponding to better next hops. The TLLAO formats for IPv4 and 1166 IPv6 RLOCs are shown in Figure 3 and Figure 4: 1168 0 1 2 3 1169 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 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Type = 2 | Length = 1 | Reserved | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | IPv4 address (bytes 0 thru 3) | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Figure 3: SCMP TLLAO Option for IPv4 RLOCs 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Type = 2 | Length = 3 | Reserved | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Reserved | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | IPv6 address (bytes 0 thru 3) | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | IPv6 address (bytes 4 thru 7) | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | IPv6 address (bytes 8 thru 11) | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | IPv6 address (bytes 12 thru 15) | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Figure 4: SCMP TLLAO Option for IPv6 RLOCs 1196 The redirector next includes a Route Information Option (RIO) (see: 1197 [RFC4191]) that contains a prefix from its FIB that covers the 1198 destination address of the original packet. SCMP uses a modified 1199 version of the RIO option formatted as shown in Figure 5: 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Type = 24 | Length | Prefix Length | AF |Prf|E|RSV| 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Route Lifetime | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Prefix (Variable Length) | 1209 . . 1210 . . 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Figure 5: SCMP Route Information Option Format 1215 In this modified format, the redirector prepares the Route Lifetime 1216 and Prefix fields in the RIO option the same as specified in 1217 [RFC4191]. It then sets the fields in the header as follows: 1219 o the 'Type', 'Length' and 'Prf' fields are set the same as 1220 specified in [RFC4191]. 1222 o the 'RSV' field is set to 0. 1224 o he 'Length' field is set to 1, 2, or 3 as specified in [RFC4191], 1225 or set to 4 if the 'Prefix Length' is greater than 128 in order to 1226 accommodate prefixes of non-IP protocols of up to 192 bits in 1227 length. 1229 o the 'Prefix Length' field ranges from 0 to 192. The 'Prefix' 1230 field is 0, 8, 16 or 24 octets depending on the length, and the 1231 embedded prefix may be up to 192 bits in length. 1233 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1234 that indicates the embedded prefix protocol type. This document 1235 defines the following values for AF: 1237 * 000 - IPv4 1239 * 001 - IPv6 1241 * 010 - OSI/CLNP NSAP 1243 o the 'E' bit is set to 1 if this prefix is assigned to an End User 1244 Network, and set to 0 otherwise. 1246 Following the RIO option, the redirector includes any other necessary 1247 options (e.g., SEND options) followed by a Redirected Header 1248 containing the leading portion of the packet that triggered the 1249 redirect as the final option in the message. The redirector then 1250 encapsulates the Redirect message the same as for any other SCMP 1251 message and sends it to the redirectee. 1253 When the redirectee receives the Redirect, it first authenticates the 1254 message (i.e., by checking the SEAL_ID in the Redirected Header, by 1255 examining SEND options, etc.) then uses the EID prefix in the RIO 1256 with its respective lifetime to update its FIB. The redirectee also 1257 caches the IPv4 or IPv6 addresses in TLLAOs as the layer 2 addresses 1258 of potential next-hops. 1260 The redirectee retains the FIB entry created as a result of receipt 1261 of an SCMP Redirect until the route lifetime expires, or until the 1262 redirected target neighbor becomes unreachable. In this way, RLOC 1263 liveness detection parallels IPv6 Neighbor Unreachability Detection 1264 as discussed in the next section. 1266 5.7.4. Mobility 1268 When a VET node moves to a new network point of attachment resulting 1269 in the change of an old RLOC to a new RLOC, it informs any 1270 correspondents of the change by sending specially-crafted SCMP 1271 Neighbor Advertisement (NA) messages. The VET node can ensure 1272 reliable delivery of the NA messages by setting the 'A' bit in the 1273 SEAL header in order to receive an explicit acknowledgement. The VET 1274 node should retry up to three times to get an explicit 1275 acknowledgement before abandoning the attempt. 1277 The NA messages use the new RLOC as the outer IP source address and 1278 include the old RLOC in a Source Link Layer Address Option (SLLAO) 1279 formatted exactly as specified for TLLAOs in Section 5.7.3. When the 1280 neighbor receives the NA, it authenticates the message then replaces 1281 the old RLOC address with the new RLOC address. Methods for 1282 authenticating the NA are out of scope for this document. 1284 5.8. Neighbor Coordination on VET Interfaces using IPsec 1286 VET interfaces that use IPsec encapsulation use the Internet Key 1287 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1288 association setup and maintenance. The IKEv2 can be seen as a 1289 logical equivalent of the SEAL SCMP in terms of VET interface 1290 neighbor coordinations. In particular, IKEv2 also provides 1291 mechanisms for redirection [RFC5685] and mobility [RFC4555]. 1293 IPsec additionally provides an extended Identification field and 1294 integrity check vector; these features allow IPsec to utilize outer 1295 IP fragmentation and reassembly with less risk of exposure to data 1296 corruption due to reassembly misassociations. On the other hand, 1297 IPsec entails the use of symmetric security associations and hence 1298 may not be appropriate to all enterprise network use cases. 1300 5.9. Multicast 1302 In multicast-capable deployments, ERs provide an enterprise-wide 1303 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1304 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1305 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1306 over their enterprise-interior interfaces such that outer IP 1307 multicast messages of site-scope or greater scope will be propagated 1308 across the enterprise network. For such deployments, VET nodes can 1309 also provide an inner multicast/broadcast capability over their VET 1310 interfaces through mapping of the inner multicast address space to 1311 the outer multicast address space. In that case, operation of link- 1312 scoped (or greater scoped) inner multicasting services (e.g., a link- 1313 scoped neighbor discovery protocol) over the VET interface is 1314 available, but link-scoped services should be used sparingly to 1315 minimize enterprise-wide flooding. 1317 VET nodes encapsulate inner multicast messages sent over the VET 1318 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1319 followed by an outer IP header with a site-scoped outer IP multicast 1320 address as the destination. For the case of IPv6 and IPv4 as the 1321 inner/outer protocols (respectively), [RFC2529] provides mappings 1322 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1323 address space (for other encapsulations, mappings are established 1324 through administrative configuration or through an unspecified 1325 alternate static mapping). 1327 Multicast mapping for inner multicast groups over outer IP multicast 1328 groups can be accommodated, e.g., through VET interface snooping of 1329 inner multicast group membership and routing protocol control 1330 messages. To support inner-to-outer multicast address mapping, the 1331 VET interface acts as a virtual outer IP multicast host connected to 1332 its underlying interfaces. When the VET interface detects that an 1333 inner multicast group joins or leaves, it forwards corresponding 1334 outer IP multicast group membership reports on an underlying 1335 interface over which the VET interface is configured. If the VET 1336 node is configured as an outer IP multicast router on the underlying 1337 interfaces, the VET interface forwards locally looped-back group 1338 membership reports to the outer IP multicast routing process. If the 1339 VET node is configured as a simple outer IP multicast host, the VET 1340 interface instead forwards actual group membership reports (e.g., 1341 IGMP messages) directly over an underlying interface. 1343 Since inner multicast groups are mapped to site-scoped outer IP 1344 multicast groups, the VET node must ensure that the site-scope outer 1345 IP multicast messages received on the underlying interfaces for one 1346 VET interface do not "leak out" to the underlying interfaces of 1347 another VET interface. This is accommodated through normal site- 1348 scoped outer IP multicast group filtering at enterprise network 1349 boundaries. 1351 5.10. Service Discovery 1353 VET nodes can perform enterprise-wide service discovery using a 1354 suitable name-to-address resolution service. Examples of flooding- 1355 based services include the use of LLMNR [RFC4795] over the VET 1356 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1357 over an underlying interface. More scalable and efficient service 1358 discovery mechanisms are for further study. 1360 5.11. Enterprise Network Partitioning 1362 An enterprise network can be partitioned into multiple distinct 1363 logical groupings. In that case, each partition must configure its 1364 own distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1365 'isatapv2.zone2.example.com', etc.). 1367 EBGs can further create multiple IP subnets within a partition by 1368 sending RAs with PIOs containing different IPv6 prefixes to different 1369 groups of nodes. EBGs can identify subnets, e.g., by examining RLOC 1370 prefixes, observing the enterprise interior interfaces over which RSs 1371 are received, etc. 1373 5.12. EBG Prefix State Recovery 1375 EBGs must retain explicit state that tracks the inner PA prefixes 1376 delegated to EBRs within the enterprise network, e.g., so that 1377 packets are delivered to the correct EBRs. When an EBG loses some or 1378 all of its state (e.g., due to a power failure), it must recover the 1379 state so that packets can be forwarded over correct routes. 1381 5.13. Support for Legacy ISATAP Services 1383 EBGs support legacy ISATAP services according to the specifications 1384 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1385 interfaces and VET interfaces over the same sets of underlying 1386 interfaces as long as the PRLs and IPv6 prefixes associated with the 1387 ISATAP/VET interfaces are distinct. 1389 6. IANA Considerations 1391 There are no IANA considerations for this document. 1393 7. Security Considerations 1395 Security considerations for MANETs are found in [RFC2501]. 1397 The security considerations found in [RFC2529] [RFC5214] 1398 [I-D.nakibly-v6ops-tunnel-loops] also apply to VET. In particular: 1400 o VET nodes must ensure that a VET interface does not span multiple 1401 sites as specified in Section 6.2 of [RFC5214]. 1403 o VET nodes must verify that the outer IP source address of a packet 1404 received on a VET interface is correct for the inner source 1405 address; for the case of IPv6 within IPv4 encapsulation, this is 1406 accommodated using the procedures specified in Section 7.3 of 1407 [RFC5214]. 1409 o EBRs must implement both inner and outer ingress filtering in a 1410 manner that is consistent with [RFC2827] as well as ip-proto-41 1411 filtering. When the node at the physical boundary of the 1412 enterprise network is an ordinary ER (i.e., and not an EBR), the 1413 ER itself should implement filtering. 1415 Additionally, VET interfaces that maintain a coherent neighbor cache 1416 drop all outbound packet for which the next hop is not a neighbor and 1417 the source address is not link-local; they also drop all incoming 1418 packets for which the previous hop is not a neighbor and the 1419 destination address is not link-local. (Here, the previous hop is 1420 determined by examining the outer source address.) 1422 Finally, VET interfaces that use IPv6 within IPv4 encapsulation drop 1423 all outbound packets for which the IPv6 source address is "foreign- 1424 prefix::0200:5efe:V4ADDR" and drop all incoming packets for which the 1425 IPv6 destination address is "foreign-prefix::0200:5efe:V4ADDR" . 1426 (Here, "foreign-prefix" is an IPv6 prefix that is not assigned to the 1427 VET interface, and "V4ADDR" is a public IPv4 address over which the 1428 VET interface is configured.) Note that these checks are only 1429 required for VET interfaces that cannot maintain a coherent neighbor 1430 cache. 1432 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1433 where attacks on the neighbor discovery protocol are possible. SEAL 1434 [I-D.templin-intarea-seal] provides a per-packet identification that 1435 can be used to detect source address spoofing. 1437 Rogue neighbor discovery messages with spoofed RLOC source addresses 1438 can consume network resources and cause VET nodes to perform extra 1439 work. Nonetheless, VET nodes should not "blacklist" such RLOCs, as 1440 that may result in a denial of service to the RLOCs' legitimate 1441 owners. 1443 8. Related Work 1445 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1446 automatic tunneling in [RFC2529]; this concept was later called: 1447 "Virtual Ethernet" and investigated by Quang Nguyen under the 1448 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1449 their colleagues have motivated a number of foundational concepts on 1450 which this work is based. 1452 Telcordia has proposed DHCP-related solutions for MANETs through the 1453 CECOM MOSAIC program. 1455 The Naval Research Lab (NRL) Information Technology Division uses 1456 DHCP in their MANET research testbeds. 1458 Security concerns pertaining to tunneling mechanisms are discussed in 1459 [I-D.ietf-v6ops-tunnel-security-concerns]. 1461 Default router and prefix information options for DHCPv6 are 1462 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1464 An automated IPv4 prefix delegation mechanism is proposed in 1465 [I-D.ietf-dhc-subnet-alloc]. 1467 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1468 [I-D.clausen-manet-autoconf-recommendations]. 1470 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1472 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1473 decapsulation issues and other aspects of tunneling. 1475 Various proposals within the IETF have suggested similar mechanisms. 1477 9. Acknowledgements 1479 The following individuals gave direct and/or indirect input that was 1480 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1481 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1482 Chris Dearlove, Remi Despres, Gert Doering, Ralph Droms, Washam Fan, 1483 Dino Farinacci, Vince Fuller, Thomas Goff, David Green, Joel Halpern, 1484 Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, Dan Jen, Darrel Lewis, 1485 Tony Li, Joe Macker, David Meyer, Gabi Nakibly, Thomas Narten, Pekka 1486 Nikander, Dave Oran, Alexandru Petrescu, Mark Smith, John Spence, 1487 Jinmei Tatuya, Dave Thaler, Mark Townsley, Ole Troan, Michaela 1488 Vanderveen, Robin Whittle, James Woodyatt, Lixia Zhang, and others in 1489 the IETF AUTOCONF and MANET working groups. Many others have 1490 provided guidance over the course of many years. 1492 10. Contributors 1494 The following individuals have contributed to this document: 1496 Eric Fleischman (eric.fleischman@boeing.com) 1497 Thomas Henderson (thomas.r.henderson@boeing.com) 1498 Steven Russert (steven.w.russert@boeing.com) 1499 Seung Yi (seung.yi@boeing.com) 1501 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1502 of the document. 1504 Jim Bound's foundational work on enterprise networks provided 1505 significant guidance for this effort. We mourn his loss and honor 1506 his contributions. 1508 11. References 1509 11.1. Normative References 1511 [I-D.templin-intarea-seal] 1512 Templin, F., "The Subnetwork Encapsulation and Adaptation 1513 Layer (SEAL)", draft-templin-intarea-seal-13 (work in 1514 progress), March 2010. 1516 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1517 September 1981. 1519 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1520 RFC 792, September 1981. 1522 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1523 RFC 2131, March 1997. 1525 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1526 (IPv6) Specification", RFC 2460, December 1998. 1528 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1529 Defeating Denial of Service Attacks which employ IP Source 1530 Address Spoofing", BCP 38, RFC 2827, May 2000. 1532 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1533 and M. Carney, "Dynamic Host Configuration Protocol for 1534 IPv6 (DHCPv6)", RFC 3315, July 2003. 1536 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1537 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1538 December 2003. 1540 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1541 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1543 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1544 RFC 3972, March 2005. 1546 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1547 More-Specific Routes", RFC 4191, November 2005. 1549 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1550 Architecture", RFC 4291, February 2006. 1552 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1553 Message Protocol (ICMPv6) for the Internet Protocol 1554 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1556 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1557 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1558 September 2007. 1560 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1561 Address Autoconfiguration", RFC 4862, September 2007. 1563 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1564 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1565 March 2008. 1567 11.2. Informative References 1569 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1570 Switching Networks", May 1974. 1572 [I-D.carpenter-flow-ecmp] 1573 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1574 for equal cost multipath routing and link aggregation in 1575 tunnels", draft-carpenter-flow-ecmp-02 (work in progress), 1576 April 2010. 1578 [I-D.cheshire-dnsext-multicastdns] 1579 Cheshire, S. and M. Krochmal, "Multicast DNS", 1580 draft-cheshire-dnsext-multicastdns-11 (work in progress), 1581 March 2010. 1583 [I-D.clausen-manet-autoconf-recommendations] 1584 Clausen, T. and U. Herberg, "MANET Router Configuration 1585 Recommendations", 1586 draft-clausen-manet-autoconf-recommendations-00 (work in 1587 progress), February 2009. 1589 [I-D.clausen-manet-linktype] 1590 Clausen, T., "The MANET Link Type", 1591 draft-clausen-manet-linktype-00 (work in progress), 1592 October 2008. 1594 [I-D.droms-dhc-dhcpv6-default-router] 1595 Droms, R. and T. Narten, "Default Router and Prefix 1596 Advertisement Options for DHCPv6", 1597 draft-droms-dhc-dhcpv6-default-router-00 (work in 1598 progress), March 2009. 1600 [I-D.ietf-autoconf-manetarch] 1601 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1602 Network Architecture", draft-ietf-autoconf-manetarch-07 1603 (work in progress), November 2007. 1605 [I-D.ietf-dhc-subnet-alloc] 1606 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1607 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1608 (work in progress), May 2010. 1610 [I-D.ietf-grow-va] 1611 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1612 L. Zhang, "FIB Suppression with Virtual Aggregation", 1613 draft-ietf-grow-va-02 (work in progress), March 2010. 1615 [I-D.ietf-lisp] 1616 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1617 "Locator/ID Separation Protocol (LISP)", 1618 draft-ietf-lisp-07 (work in progress), April 2010. 1620 [I-D.ietf-manet-smf] 1621 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1622 draft-ietf-manet-smf-10 (work in progress), March 2010. 1624 [I-D.ietf-softwire-ipv6-6rd] 1625 Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 1626 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 1627 (work in progress), May 2010. 1629 [I-D.ietf-v6ops-tunnel-security-concerns] 1630 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1631 Concerns With IP Tunneling", 1632 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 1633 progress), March 2010. 1635 [I-D.jen-apt] 1636 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1637 L. Zhang, "APT: A Practical Transit Mapping Service", 1638 draft-jen-apt-01 (work in progress), November 2007. 1640 [I-D.nakibly-v6ops-tunnel-loops] 1641 Nakibly, G. and F. Templin, "Routing Loop Attack using 1642 IPv6 Automatic Tunnels: Problem Statement and Proposed 1643 Mitigations", draft-nakibly-v6ops-tunnel-loops-02 (work in 1644 progress), May 2010. 1646 [I-D.russert-rangers] 1647 Russert, S., Fleischman, E., and F. Templin, "Operational 1648 Scenarios for IRON and RANGER", draft-russert-rangers-02 1649 (work in progress), March 2010. 1651 [I-D.templin-iron] 1652 Templin, F., "The Internet Routing Overlay Network 1653 (IRON)", draft-templin-iron-01 (work in progress), 1654 April 2010. 1656 [I-D.templin-isatap-dhcp] 1657 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1658 Option for the Intra-Site Automatic Tunnel Addressing 1659 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1660 progress), December 2009. 1662 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1663 July 1978. 1665 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1666 Protocol Specification", October 2008. 1668 [RFC0994] International Organization for Standardization (ISO) and 1669 American National Standards Institute (ANSI), "Final text 1670 of DIS 8473, Protocol for Providing the Connectionless- 1671 mode Network Service", RFC 994, March 1986. 1673 [RFC1035] Mockapetris, P., "Domain names - implementation and 1674 specification", STD 13, RFC 1035, November 1987. 1676 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1677 a subnetwork for experimentation with the OSI network 1678 layer", RFC 1070, February 1989. 1680 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1681 Communication Layers", STD 3, RFC 1122, October 1989. 1683 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1684 Routing and Addressing Architecture", RFC 1753, 1685 December 1994. 1687 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1688 E. Lear, "Address Allocation for Private Internets", 1689 BCP 5, RFC 1918, February 1996. 1691 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1692 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1694 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1695 October 1996. 1697 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1698 Extensions", RFC 2132, March 1997. 1700 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1701 IPv6 Specification", RFC 2473, December 1998. 1703 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1704 over Non-Broadcast Multiple Access (NBMA) networks", 1705 RFC 2491, January 1999. 1707 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1708 (MANET): Routing Protocol Performance Issues and 1709 Evaluation Considerations", RFC 2501, January 1999. 1711 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1712 Domains without Explicit Tunnels", RFC 2529, March 1999. 1714 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1715 February 2000. 1717 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1718 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1719 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1720 RFC 3819, July 2004. 1722 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1723 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1724 May 2005. 1726 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1727 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1728 January 2005. 1730 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1731 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1732 RFC 3948, January 2005. 1734 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1735 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1736 September 2005. 1738 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1739 Addresses", RFC 4193, October 2005. 1741 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1742 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1744 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1745 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1747 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1748 Internet Protocol", RFC 4301, December 2005. 1750 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1751 RFC 4306, December 2005. 1753 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1754 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1755 May 2006. 1757 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1758 (MOBIKE)", RFC 4555, June 2006. 1760 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1761 Multicast Name Resolution (LLMNR)", RFC 4795, 1762 January 2007. 1764 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1765 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1766 Focus", RFC 4852, April 2007. 1768 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1769 June 2007. 1771 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1772 Extensions for Stateless Address Autoconfiguration in 1773 IPv6", RFC 4941, September 2007. 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 Appendix A. Duplicate Address Detection (DAD) Considerations 1794 A priori uniqueness determination (also known as "pre-service DAD") 1795 for an RLOC assigned on an enterprise-interior interface would 1796 require either flooding the entire enterprise network or somehow 1797 discovering a link in the network on which a node that configures a 1798 duplicate address is attached and performing a localized DAD exchange 1799 on that link. But, the control message overhead for such an 1800 enterprise-wide DAD would be substantial and prone to false-negatives 1801 due to packet loss and intermittent connectivity. An alternative to 1802 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1803 enterprise-interior interfaces and employ a passive in-service DAD 1804 (e.g., one that monitors routing protocol messages for duplicate 1805 assignments). 1807 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1808 CGAs, IPv6 privacy addresses, etc. with very small probability of 1809 collision. Pseudo-random IPv4 RLOCs can be generated through random 1810 assignment from a suitably large IPv4 prefix space. 1812 Consistent operational practices can assure uniqueness for EBG- 1813 aggregated addresses/prefixes, while statistical properties for 1814 pseudo-random address self-generation can assure uniqueness for the 1815 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1816 RLOC delegation authority should be used when available, while a 1817 passive in-service DAD mechanism should be used to detect RLOC 1818 duplications when there is no RLOC delegation authority. 1820 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1822 For each distinct enterprise network that it connects to, an EBR 1823 configures a VET interface over possibly multiple underlying 1824 interfaces that all connect to the same network. The VET interface 1825 therefore represents the EBR's logical point of attachment to the 1826 enterprise network, and provides a logical interface for link-layer 1827 multiplexing over its underlying interfaces as described in Section 1828 3.3.4.1 of [RFC1122]: 1830 "Finally, we note another possibility that is NOT multihoming: one 1831 logical interface may be bound to multiple physical interfaces, in 1832 order to increase the reliability or throughput between directly 1833 connected machines by providing alternative physical paths between 1834 them. For instance, two systems might be connected by multiple 1835 point-to-point links. We call this "link-layer multiplexing". 1836 With link-layer multiplexing, the protocols above the link layer 1837 are unaware that multiple physical interfaces are present; the 1838 link-layer device driver is responsible for multiplexing and 1839 routing packets across the physical interfaces." 1841 EBRs can support such a link-layer multiplexing capability across the 1842 enterprise network in accordance with the Weak End System Model (see 1843 Section 3.3.4.2 of [RFC1122]). In particular, when an EBR 1844 autoconfigures an RLOC address, it can associate it with the VET 1845 interface only instead of assigning it to an underlying interface. 1846 The EBR therefore only needs to obtain a single RLOC address even if 1847 there are multiple underlying interfaces, i.e., it does not need to 1848 obtain one for each underlying interface. The EBR can then leave the 1849 underlying interfaces unnumbered, or it can configure a randomly 1850 chosen IP link-local address (e.g., from the prefix 169.254/16 1851 [RFC3927] for IPv4) on underlying interfaces that require a 1852 configuration. The EBR need not check these link-local addresses for 1853 uniqueness within the enterprise network, as they will not normally 1854 be used as the source address for packets. 1856 When the EBR engages in the enterprise-interior routing protocol, it 1857 uses the RLOC address assigned to the VET interface as the source 1858 address for all routing protocol control messages, however it must 1859 also supply an interface identifier (e.g., a small integer) that 1860 uniquely identifies the underlying interface that the control message 1861 is sent over. For example, if the underlying interfaces are known as 1862 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1863 sends a routing protocol control message over the "eth7" interface. 1864 This is necessary to ensure that other routers can determine the 1865 specific interface over which the EBR's routing protocol control 1866 message was sent, but the token need only be unique within the EBR 1867 itself and need not be unique throughout the enterprise network. 1869 When the EBR discovers an RLOC route via the enterprise interior 1870 routing protocol, it configures a preferred route in the IP FIB that 1871 points to the VET interface instead of the underlying interface. At 1872 the same time, the EBR also configures an ancillary route that points 1873 to the underlying interface. If the EBR discovers that the same RLOC 1874 route is reachable via multiple underlying interfaces, it configures 1875 multiple ancillary routes (i.e., one for each interface). If the EBR 1876 discovers that the RLOC route is no longer reachable via any 1877 underlying interface, it removes the route in the IP FIB that points 1878 to the VET interface. 1880 With these arrangements, all locally-generated packets with RLOC 1881 destinations will flow through the VET interface (and thereby use the 1882 VET interface's RLOC address as the source address) instead of 1883 through the underlying interfaces. In the same fashion, all 1884 forwarded packets with RLOC destinations will flow through the VET 1885 interface instead of through the underlying interfaces. 1887 This arrangement has several operational advantages that enable a 1888 number of traffic engineering capabilities. First, the VET interface 1889 can insert the SEAL header so that ID-based duplicate packet 1890 detection is enabled within the enterprise network. Secondly, SEAL 1891 can dynamically adjust its packet sizing parameters so that an 1892 optimum Maximum Transmission Unit (MTU) can be determined. This is 1893 true even if the VET interface reroutes traffic between underlying 1894 interfaces with different MTUs. 1896 Most importantly, the EBR can configure default and more-specific 1897 routes on the VET interface to direct traffic through a specific 1898 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1899 will ensure that a specific eEBR is chosen, and the best eEBR can be 1900 chosen when multiple are available. Also, local applications see a 1901 stable IP source address even if there are multiple underlying 1902 interfaces. This link-layer multiplexing can therefore provide 1903 continuous operation across failovers between multiple links attached 1904 to the same enterprise network without any need for readdressing. 1905 Finally, the VET interface can forward packets with RLOC-based 1906 destinations over an underlying interface without any encapsulation 1907 if encapsulation avoidance is desired. 1909 It must be specifically noted that the above arrangement constitutes 1910 a case in which the same RLOC may be used as both the inner and outer 1911 IP source address. This will not present a problem as long as both 1912 ends configure a VET interface in the same fashion. 1914 It must also be noted that EID-based communications can use the same 1915 VET interface arrangement, except that the EID-based next hop must be 1916 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1917 within IPvX encapsulation, as well as for IPv4 within IPv6 1918 encapsulation, this requires a VET interface specific address mapping 1919 database. For IPv6 within IPv4 encapsulation, the mapping is 1920 accomplished through simple static extraction of an IPv4 address 1921 embedded within the IPv6 address. 1923 Appendix C. Anycast Services 1925 Some of the IPv4 addresses that appear in the Potential Router List 1926 may be anycast addresses, i.e., they may be configured on the VET 1927 interfaces of multiple EBRs/EBGs. In that case, each VET router 1928 interface that configures the same anycast address must provide 1929 equivalent packet forwarding and neighbor discovery services. 1931 Use of an anycast address as the IP destination address of tunneled 1932 packets can have subtle interactions with tunnel path MTU and 1933 neighbor discovery. For example, if the initial fragments of a 1934 fragmented tunneled packet with an anycast IP destination address are 1935 routed to different egress tunnel endpoints than the remaining 1936 fragments, the multiple endpoints will be left with incomplete 1937 reassembly buffers. This issue can be mitigated by ensuring that 1938 each egress tunnel endpoint implements a proactive reassembly buffer 1939 garbage collection strategy. Additionally, ingress tunnel endpoints 1940 that send packets with an anycast IP destination address must use the 1941 minimum path MTU for all egress tunnel endpoints that configure the 1942 same anycast address as the tunnel MTU. Finally, ingress tunnel 1943 endpoints should treat ICMP unreachable messages from a router within 1944 the tunnel as at most a weak indication of neighbor unreachability, 1945 since the failures may only be transient and a different path to an 1946 alternate anycast router quickly selected through reconvergence of 1947 the underlying routing protocol. 1949 Use of an anycast address as the IP source address of tunneled 1950 packets can lead to more serious issues. For example, when the IP 1951 source address of a tunneled packet is anycast, ICMP messages 1952 produced by routers within the tunnel might be delivered to different 1953 ingress tunnel endpoints than the ones that produced the packets. In 1954 that case, functions such as path MTU discovery and neighbor 1955 unreachability detection may experience non-deterministic behavior 1956 that can lead to communications failures. Additionally, the 1957 fragments of multiple tunneled packets produced by multiple ingress 1958 tunnel endpoints may be delivered to the same reassembly buffer at a 1959 single egress tunnel endpoint. In that case, data corruption may 1960 result due to fragment misassociation during reassembly. 1962 In view of these considerations, EBRs/EBGs that configure an anycast 1963 address should also configure one or more unicast addresses from the 1964 Potential Router List; they should further accept tunneled packets 1965 destined to any of their anycast or unicast addresses, but should 1966 send tunneled packets using a unicast address as the source address. 1967 In order to influence traffic to use an anycast route (and thereby 1968 leverage the natural fault tolerance afforded by anycast), ISATAP 1969 routers should set higher preferences on the default routes they 1970 advertise using an anycast address as the source and set lower 1971 preferences on the default routes they advertise using a unicast 1972 address as the source (see: [RFC4191]). 1974 Appendix D. Change Log 1976 (Note to RFC editor - this section to be removed before publication 1977 as an RFC.) 1979 Changes from -12 to -13: 1981 o Changed "VGL" *back* to "PRL" 1983 o More changes for multi-protocol support 1984 o Changes to Redirect function 1986 Changes from -11 to -12: 1988 o Major section rearrangement 1990 o Changed "PRL" to "VGL" 1992 o Brought back text that was lost in the -10 to -11 transition 1994 Changes from -10 to -11: 1996 o Major changes with significant simplifications 1998 o Now support stateless PD using 6rd mechanisms 2000 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2002 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2004 Changes from -09 to -10: 2006 o Changed "enterprise" to "enterprise network" throughout 2008 o dropped "inner IP", since inner layer may be non-IP 2010 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2011 messages remain *within* the tunnel interface instead of being 2012 exposed to the inner network layer protocol engine. 2014 Changes from -08 to -09: 2016 o Expanded discussion of encapsulation/decapsulation procedures 2018 o cited IRON 2020 Changes from -07 to -08: 2022 o Specified the approach to global mapping using virtual aggregation 2023 and BGP 2025 Changes from -06 to -07: 2027 o reworked redirect function 2029 o created new section on VET interface encapsulation 2030 o clarifications on nexthop selection 2032 o fixed several bugs 2034 Changed from -05 to -06: 2036 o reworked VET interface ND 2038 o anycast clarifications 2040 Changes from -03 to -04: 2042 o security consideration clarifications 2044 Changes from -02 to -03: 2046 o security consideration clarifications 2048 o new PRLNAME for VET is "isatav2.example.com" 2050 o VET now uses SEAL natively 2052 o EBGs can support both legacy ISATAP and VET over the same 2053 underlying interfaces. 2055 Changes from -01 to -02: 2057 o Defined CGA and privacy address configuration on VET interfaces 2059 o Interface identifiers added to routing protocol control messages 2060 for link-layer multiplexing 2062 Changes from -00 to -01: 2064 o Section 4.1 clarifications on link-local assignment and RLOC 2065 autoconfiguration. 2067 o Appendix B clarifications on Weak End System Model 2069 Changes from RFC5558 to -00: 2071 o New appendix on RLOC configuration on VET interfaces. 2073 Author's Address 2075 Fred L. Templin (editor) 2076 Boeing Research & Technology 2077 P.O. Box 3707 MC 7L-49 2078 Seattle, WA 98124 2079 USA 2081 Email: fltemplin@acm.org