idnits 2.17.1 draft-templin-intarea-vet-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2010) is 5071 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-15 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) == Outdated reference: A later version (-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-03 == Outdated reference: A later version (-17) exists of draft-templin-iron-03 -- 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 (~~), 13 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 8, 2010 5 Expires: December 10, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-15.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 10, 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 . . . . . . . . . 13 62 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 14 63 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 15 64 4.2.2. Provider-Aggregated (PA) EID Prefix 65 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 66 4.2.3. Provider-Independent (PI) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 68 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 18 69 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 19 70 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 19 71 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 19 72 5.1.1. PI Prefix Routing Considerations . . . . . . . . . . . 19 73 5.2. Default Route Configuration and Selection . . . . . . . . 20 74 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 20 75 5.4. Next Hop Determination . . . . . . . . . . . . . . . . . . 21 76 5.5. VET Interface Encapsulation/Decapsulation . . . . . . . . 22 77 5.5.1. Inner Network Layer Protocol . . . . . . . . . . . . . 22 78 5.5.2. Mid-Layer Encapsulation . . . . . . . . . . . . . . . 22 79 5.5.3. SEAL Encapsulation . . . . . . . . . . . . . . . . . . 22 80 5.5.4. Outer UDP Header Encapsulation . . . . . . . . . . . . 23 81 5.5.5. Outer IP Header Encapsulation . . . . . . . . . . . . 24 82 5.5.6. Decapsulation . . . . . . . . . . . . . . . . . . . . 24 83 5.6. Mobility and Multihoming Considerations . . . . . . . . . 24 84 5.7. Neighbor Coordination on VET Interfaces using SEAL . . . . 25 85 5.7.1. Router Discovery . . . . . . . . . . . . . . . . . . . 25 86 5.7.2. Neighbor Unreachability Detection . . . . . . . . . . 26 87 5.7.3. Redirect Function . . . . . . . . . . . . . . . . . . 26 88 5.7.4. Mobility . . . . . . . . . . . . . . . . . . . . . . . 29 89 5.8. Neighbor Coordination on VET Interfaces using IPsec . . . 29 90 5.9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 30 91 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 92 5.11. Enterprise Network Partitioning . . . . . . . . . . . . . 31 93 5.12. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 31 94 5.13. Support for Legacy ISATAP Services . . . . . . . . . . . . 31 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 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 . . 40 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 . . . . . . . . . . . . . . . . . . . . . . . . . 46 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/ICMPv4 130 [RFC0791][RFC0792] and IPv6/ICMPv6 [RFC2460][RFC4443] are discussed 131 within this context (other network layer protocols are also 132 considered). The use of standard DHCP [RFC2131] [RFC3315] is assumed 133 unless otherwise specified. 135 Provider-Edge Interfaces 136 x x x 137 | | | 138 +--------------------+---+--------+----------+ E 139 | | | | | n 140 | I | | .... | | t 141 | n +---+---+--------+---+ | e 142 | t | +--------+ /| | r 143 | e I x----+ | Host | I /*+------+--< p I 144 | r n | |Function| n|**| | r n 145 | n t | +--------+ t|**| | i t 146 | a e x----+ V e|**+------+--< s e 147 | l r . | E r|**| . | e r 148 | f . | T f|**| . | f 149 | V a . | +--------+ a|**| . | I a 150 | i c . | | Router | c|**| . | n c 151 | r e x----+ |Function| e \*+------+--< t e 152 | t s | +--------+ \| | e s 153 | u +---+---+--------+---+ | r 154 | a | | .... | | i 155 | l | | | | o 156 +--------------------+---+--------+----------+ r 157 | | | 158 x x x 159 Enterprise-Edge Interfaces 161 Figure 1: Enterprise Router (ER) Architecture 163 Figure 1 above depicts the architectural model for an Enterprise 164 Router (ER). As shown in the figure, an ER may have a variety of 165 interface types including enterprise-edge, enterprise-interior, 166 provider-edge, internal-virtual, as well as VET interfaces used for 167 encapsulating inner network layer protocol packets for transmission 168 over outer IPv4 or IPv6 networks. The different types of interfaces 169 are defined, and the autoconfiguration mechanisms used for each type 170 are specified. This architecture applies equally for MANET routers, 171 in which enterprise-interior interfaces correspond to the wireless 172 multihop radio interfaces typically associated with MANETs. Out of 173 scope for this document is the autoconfiguration of provider 174 interfaces, which must be coordinated in a manner specific to the 175 service provider's network. 177 Enterprise networks require a means for supporting both Provider- 178 Independent (PI) and Provider-Aggregated (PA) addressing. This is 179 especially true for enterprise network scenarios that involve 180 mobility and multihoming. The VET specification provides adaptable 181 mechanisms that address these and other issues in a wide variety of 182 enterprise network use cases. 184 The VET framework builds on a Non-Broadcast Multiple Access (NBMA) 185 [RFC2491] virtual interface model in a manner similar to other 186 automatic tunneling technologies [RFC2529][RFC5214]. VET interfaces 187 support the encapsulation of inner network layer protocol packets 188 over IP networks (i.e., either IPv4 or IPv6). VET is also compatible 189 with mid-layer encapsulation technologies including IPsec [RFC4301], 190 and supports both stateful and stateless prefix delegation. 192 VET and its associated technologies (including the Subnetwork 193 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal]) 194 are functional building blocks for a new Internetworking architecture 195 based on the Internet Routing Overlay Network (IRON) 196 [I-D.templin-iron] and Routing and Addressing in Networks with Global 197 Enterprise Recursion (RANGER) [RFC5720] [I-D.russert-rangers]. Many 198 of the VET principles can be traced to the deliberations of the ROAD 199 group in January 1992, and also to still earlier initiatives 200 including NIMROD [RFC1753] and the Catenet model for internetworking 201 [CATENET] [IEN48] [RFC2775]. [RFC1955] captures the high-level 202 architectural aspects of the ROAD group deliberations in a "New 203 Scheme for Internet Routing and Addressing (ENCAPS) for IPNG". 205 VET is related to the present-day activities of the IETF INTAREA, 206 AUTOCONF, DHC, IPv6, MANET, and V6OPS working groups, as well as the 207 IRTF RRG working group. 209 2. Terminology 211 The mechanisms within this document build upon the fundamental 212 principles of IP encapsulation. The term "inner" refers to the 213 innermost {address, protocol, header, packet, etc.} *before* 214 encapsulation, and the term "outer" refers to the outermost {address, 215 protocol, header, packet, etc.} *after* encapsulation. VET also 216 accommodates "mid-layer" encapsulations including the Subnetwork 217 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal], 218 IPsec [RFC4301], etc. 220 The terminology in the normative references apply; the following 221 terms are defined within the scope of this document: 223 Virtual Enterprise Traversal (VET) 224 an abstraction that uses IP encapsulation to create overlays for 225 traversing IPv4 and IPv6 enterprise networks. 227 enterprise network 228 the same as defined in [RFC4852]. An enterprise network is 229 further understood to refer to a cooperative networked collective 230 of devices within a structured IP routing and addressing plan and 231 with a commonality of business, social, political, etc., 232 interests. Minimally, the only commonality of interest in some 233 enterprise network scenarios may be the cooperative provisioning 234 of connectivity itself. 236 subnetwork 237 the same as defined in [RFC3819]. 239 site 240 a logical and/or physical grouping of interfaces that connect a 241 topological area less than or equal to an enterprise network in 242 scope. From a network organizational standpoint, a site within an 243 enterprise network can be considered as an enterprise unto itself. 245 Mobile Ad hoc Network (MANET) 246 a connected topology of mobile or fixed routers that maintain a 247 routing structure among themselves over dynamic links. The 248 characteristics of MANETs are defined in [RFC2501], Section 3, and 249 a wide variety of MANETs share common properties with enterprise 250 networks. 252 enterprise/site/MANET 253 throughout the remainder of this document, the term "enterprise 254 network" is used to collectively refer to any of {enterprise, 255 site, MANET}, i.e., the VET mechanisms and operational principles 256 can be applied to enterprises, sites, and MANETs of any size or 257 shape. 259 Enterprise Router (ER) 260 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 261 mobile router that comprises a router function, a host function, 262 one or more enterprise-interior interfaces, and zero or more 263 internal virtual, enterprise-edge, provider-edge, and VET 264 interfaces. At a minimum, an ER forwards outer IP packets over 265 one or more sets of enterprise-interior interfaces, where each set 266 connects to a distinct enterprise network. 268 Enterprise Border Router (EBR) 269 an ER that connects edge networks to the enterprise network and/or 270 connects multiple enterprise networks together. An EBR is a 271 tunnel endpoint router, and it configures a separate VET interface 272 over each set of enterprise-interior interfaces that connect the 273 EBR to each distinct enterprise network. In particular, an EBR 274 may configure multiple VET interfaces - one for each distinct 275 enterprise network. All EBRs are also ERs. 277 Enterprise Border Gateway (EBG) 278 an EBR that connects child enterprise networks to provider 279 networks - either directly via a provider-edge interface or 280 indirectly via another VET interface configured over a parent 281 enterprise network. EBRs may act as EBGs on some VET interfaces 282 and as ordinary EBRs on other VET interfaces. All EBGs are also 283 EBRs. 285 VET host 286 any node (host or router) that configures a VET interface for 287 host-operation only. Note that a node may configure some of its 288 VET interfaces as host interfaces and others as router interfaces. 290 VET node 291 any node (host or router) that configures and uses a VET 292 interface. 294 enterprise-interior interface 295 an ER's attachment to a link within an enterprise network. 296 Packets sent over enterprise-interior interfaces may be forwarded 297 over multiple additional enterprise-interior interfaces within the 298 enterprise network before they are forwarded via an enterprise- 299 edge interface, provider-edge interface, or a VET interface 300 configured over a different enterprise network. Enterprise- 301 interior interfaces connect laterally within the IP network 302 hierarchy. 304 enterprise-edge interface 305 an EBR's attachment to a link (e.g., an Ethernet, a wireless 306 personal area network, etc.) on an arbitrarily complex edge 307 network that the EBR connects to an enterprise network and/or 308 provider network. Enterprise-edge interfaces connect to lower 309 levels within the IP network hierarchy. 311 provider-edge interface 312 an EBR's attachment to the Internet or to a provider network via 313 which the Internet can be reached. Provider-edge interfaces 314 connect to higher levels within the IP network hierarchy. 316 internal-virtual interface 317 an interface that is internal to an EBR and does not in itself 318 directly attach to a tangible physical link (e.g., an Ethernet 319 cable, a WiFi radio, etc.). Examples include a loopback 320 interface, a virtual private network interface, or some form of 321 tunnel interface. 323 VET link 324 a virtual link that uses automatic tunneling to create an overlay 325 network that spans an enterprise-interior routing region. VET 326 links can be segmented (e.g., by filtering gateways) into multiple 327 distinct segments that can be joined together by bridges or IP 328 routers the same as for any link. Bridging would view the 329 multiple (bridged) segments as a single VET link, whereas IP 330 routing would view the multiple segments as multiple distinct VET 331 links. VET link segments can further be partitioned into multiple 332 logical areas, where each area is identified by a distinct set of 333 EBGs. 335 VET links in non-multicast enterprise networks are Non-Broadcast, 336 Multiple Access (NBMA); VET links in enterprise networks that 337 support multicast are multicast capable. 339 VET interface 340 a VET node's attachment to a VET link. VET nodes configure each 341 VET interface over a set of underlying enterprise-interior 342 interfaces that connect to a routing region spanned by a single 343 VET link. When there are multiple distinct VET links (each with 344 their own distinct set of underlying interfaces), the VET node 345 configures separate VET interfaces for each link. 347 The VET interface encapsulates each inner packet in any mid-layer 348 headers followed by an outer IP header, then forwards the packet 349 on an underlying interface such that the Time to Live (TTL) - Hop 350 Limit in the inner header is not decremented as the packet 351 traverses the link. The VET interface therefore presents an 352 automatic tunneling abstraction that represents the link as a 353 single IP hop. 355 Provider Aggregated (PA) prefix 356 a network layer protocol prefix that is delegated to an EBR by a 357 provider network. 359 Provider-Independent (PI) address/prefix 360 a network layer protocol prefix that is delegated to an EBR by an 361 independent prefix registration authority. 363 Routing Locator (RLOC) 364 a public-scope or enterprise-local-scope IP address that can 365 appear in enterprise-interior and/or interdomain routing tables. 366 Public-scope RLOCs are delegated to specific enterprise networks 367 and routable within both the enterprise-interior and interdomain 368 routing regions. Enterprise-local-scope RLOCs (e.g., IPv6 Unique 369 Local Addresses [RFC4193], IPv4 privacy addresses [RFC1918], etc.) 370 are self-generated by individual enterprise networks and routable 371 only within the enterprise-interior routing region. 373 ERs use RLOCs for operating the enterprise-interior routing 374 protocol and for next-hop determination in forwarding packets 375 addressed to other RLOCs. End systems can use RLOCs as addresses 376 for end-to-end communications between peers within the same 377 enterprise network. VET interfaces treat RLOCs as *outer* IP 378 addresses during encapsulation. 380 Endpoint Interface iDentifier (EID) 381 a public-scope network layer address that is routable within an 382 enterprise-edge or VET overlay network. EID prefixes are separate 383 and distinct from any RLOC prefix space, but are mapped to RLOC 384 addresses to support routing over VET interfaces. 386 EBRs use EIDs for operating the enterprise-edge or VET overlay 387 network routing protocol and for next-hop determination in 388 forwarding packets addressed to other EIDs. End systems can use 389 EIDs as addresses for end-to-end communications between peers 390 either within the same enterprise network or within different 391 enterprise networks. VET interfaces treat EIDs as *inner* network 392 layer addresses during encapsulation. 394 Note that an EID can also be used as an *outer* network layer 395 address if there are nested encapsulations. In that case, the EID 396 would appear as an RLOC to the innermost encapsulation. 398 The following additional acronyms are used throughout the document: 400 CGA - Cryptographically Generated Address 401 DHCP(v4, v6) - Dynamic Host Configuration Protocol 402 ECMP - Equal Cost Multi Path 403 FIB - Forwarding Information Base 404 ICMP - either ICMPv4 or ICMPv6 405 IP - either IPv4 or IPv6 406 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 407 NBMA - Non-Broadcast, Multiple Access 408 ND - Neighbor Discovery 409 NS/NA - Neighbor Solicitation/Advertisement 410 PIO - Prefix Information Option 411 PRL - Potential Router List 412 PRLNAME - Identifying name for the PRL 413 RIB - Routing Information Base 414 RIO - Route Information Option 415 RPF - Reverse Path Forwarding 416 RS/RA - Router Solicitation/Advertisement 417 SCMP - SEAL Control Message Protocol 418 SEAL - Subnetwork Encapsulation and Adaptation Layer 419 SLAAC - IPv6 StateLess Address AutoConfiguration 421 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 422 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 423 document are to be interpreted as described in [RFC2119]. When used 424 in lower case (e.g., must, must not, etc.), these words MUST NOT be 425 interpreted as described in [RFC2119], but are rather interpreted as 426 they would be in common English. 428 3. Enterprise Network Characteristics 430 Enterprise networks consist of links that are connected by Enterprise 431 Routers (ERs) as depicted in Figure 1. ERs typically participate in 432 a routing protocol over enterprise-interior interfaces to discover 433 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 434 Enterprise Border Routers (EBRs) are ERs that connect edge networks 435 to the enterprise network and/or join multiple enterprise networks 436 together. Enterprise Border Gateways (EBGs) are EBRs that connect 437 enterprise networks to provider networks. 439 Conceptually, an ER embodies both a host function and router 440 function, and supports communications according to the weak end- 441 system model [RFC1122]. The router function engages in the 442 enterprise-interior routing protocol, connects any of the ER's edge 443 networks to the enterprise networks, and may also connect the 444 enterprise network to provider networks (see Figure 1). The host 445 function typically supports network management applications, but may 446 also support diverse applications typically associated with general- 447 purpose computing platforms. 449 An enterprise network may be as simple as a small collection of ERs 450 and their attached edge networks; an enterprise network may also 451 contain other enterprise networks and/or be a subnetwork of a larger 452 enterprise network. An enterprise network may further encompass a 453 set of branch offices and/or nomadic hosts connected to a home office 454 over one or several service providers, e.g., through Virtual Private 455 Network (VPN) tunnels. Finally, an enterprise network may contain 456 many internal partitions that are logical or physical groupings of 457 nodes for the purpose of load balancing, organizational separation, 458 etc. In that case, each internal partition resembles an individual 459 segment of a bridged LAN. 461 Enterprise networks that comprise link types with sufficiently 462 similar properties (e.g., Layer 2 (L2) address formats, maximum 463 transmission units (MTUs), etc.) can configure a sub-IP layer routing 464 service such that IP sees the network as an ordinary shared link the 465 same as for a (bridged) campus LAN. In that case, a single IP hop is 466 sufficient to traverse the network without need for encapsulation. 467 Enterprise networks that comprise link types with diverse properties 468 and/or configure multiple IP subnets must also provide an enterprise- 469 interior routing service that operates as an IP layer mechanism. In 470 that case, multiple IP hops may be necessary to traverse the network 471 such that care must be taken to avoid multi-link subnet issues 472 [RFC4903]. 474 In addition to other interface types, VET nodes configure VET 475 interfaces that view all other nodes on the VET link as neighbors on 476 a virtual NBMA link. VET nodes configure a separate VET interface 477 for each distinct VET link to which they connect, and discover other 478 EBRs on the link that can be used for forwarding packets to off-link 479 destinations. 481 For each distinct enterprise network, a trust basis must be 482 established and consistently applied. For example, in enterprise 483 networks in which EBRs establish symmetric security associations, 484 mechanisms such as IPsec [RFC4301] can be used to assure 485 authentication and confidentiality. In other enterprise network 486 scenarios, asymmetric securing mechanisms such as SEcure Neighbor 487 Discovery (SEND) [RFC3971] may be necessary. Still other enterprise 488 networks may find it sufficient to employ mechanisms (e.g., SEAL 489 [I-D.templin-intarea-seal]) that can defeat off-path attacks. 491 Finally, in enterprise networks with a centralized management 492 structure (e.g., a corporate campus network), an overlay routing/ 493 mapping service and a synchronized set of EBGs can provide sufficient 494 infrastructure support for virtual enterprise traversal. In that 495 case, the EBGs can provide a "default mapper" [I-D.jen-apt] service 496 used for short-term packet forwarding until route-optimized paths 497 between neighboring EBRs can be established. In enterprise networks 498 with a distributed management structure (e.g., disconnected MANETs), 499 peer-to-peer coordination between the EBRs themselves may be 500 required. Recognizing that various use cases will entail a continuum 501 between a fully distributed and fully centralized approach, the 502 following sections present the mechanisms of Virtual Enterprise 503 Traversal as they apply to a wide variety of scenarios. 505 4. Autoconfiguration 507 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 508 specified in the following subsections. 510 4.1. Enterprise Router (ER) Autoconfiguration 512 ERs configure enterprise-interior interfaces and engage in any 513 routing protocols over those interfaces. 515 When an ER joins an enterprise network, it first configures an IPv6 516 link-local address on each enterprise-interior interface and 517 configures an IPv4 link-local address on each enterprise-interior 518 interface that requires an IPv4 link-local capability. IPv6 link- 519 local address generation mechanisms include Cryptographically 520 Generated Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses 521 [RFC4941], StateLess Address AutoConfiguration (SLAAC) using EUI-64 522 interface identifiers [RFC4291] [RFC4862], etc. The mechanisms 523 specified in [RFC3927] provide an IPv4 link-local address generation 524 capability. 526 Next, the ER configures one or more RLOCs and engages in any routing 527 protocols on its enterprise-interior interfaces. The ER can 528 configure RLOCs via explicit management, DHCP autoconfiguration, 529 pseudo-random self-generation from a suitably large address pool, or 530 through an alternate autoconfiguration mechanism. The ER may 531 optionally configure and assign a separate RLOC for each underlying 532 interface, or it may configure only a single RLOC and assign it to a 533 VET interface configured over the underlying interfaces (see Section 534 4.2.1). In the latter case, the ER can use the VET interface for 535 link layer multiplexing and traffic engineering purposes as specified 536 in Appendix B. 538 Alternatively (or in addition), the ER can request RLOC prefix 539 delegations via an automated prefix delegation exchange over an 540 enterprise-interior interface and can assign the prefix(es) on 541 enterprise-edge interfaces. Note that in some cases, the same 542 enterprise-edge interfaces may assign both RLOC and EID addresses if 543 there is a means for source address selection. In other cases (e.g., 544 for separation of security domains), RLOCs and EIDs are assigned on 545 separate sets of enterprise-edge interfaces. 547 Pseudo-random self-generation of IPv6 RLOCs can be from a large 548 public or local-use IPv6 address range (e.g., IPv6 Unique Local 549 Addresses [RFC4193]). Pseudo-random self-generation of IPv4 RLOCs 550 can be from a large public or local-use IPv4 address range (e.g., 551 [RFC1918]). When self-generation is used alone, the ER continuously 552 monitors the RLOCs for uniqueness, e.g., by monitoring the 553 enterprise-interior routing protocol. (Note however that anycast 554 RLOCs MAY be assigned to multiple enterprise interior interfaces; 555 hence, monitoring for uniqueness applies only to RLOCs that are 556 intended as unicast.) 557 DHCP generation of RLOCs uses standard DHCP procedures but may 558 require support from relays within the enterprise network. For 559 DHCPv6, relays that do not already know the RLOC of a server within 560 the enterprise network forward requests to the 'All_DHCP_Servers' 561 site-scoped IPv6 multicast group [RFC3315]. For DHCPv4, relays that 562 do not already know the RLOC of a server within the enterprise 563 network forward requests to the site-scoped IPv4 multicast group 564 address 'All_DHCPv4_Servers', which SHOULD be set to 239.255.2.1 565 unless an alternate multicast group for the site is known. DHCPv4 566 servers that delegate RLOCs SHOULD therefore join the 567 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 568 received for that group. 570 A combined approach using both DHCP and self-generation is also 571 possible when the ER configures both a DHCP client and relay that are 572 connected, e.g., via a pair of back-to-back connected Ethernet 573 interfaces, a tun/tap interface, a loopback interface, inter-process 574 communication, etc. The ER first self-generates an RLOC from a 575 temporary addressing range used only for the bootstrapping purpose of 576 procuring an actual RLOC taken from a preferred addressing range. 577 The ER then engages in the enterprise-interior routing protocol and 578 performs a DHCP client/relay exchange using the temporary RLOC as the 579 address of the relay. When the DHCP server delegates an actual RLOC 580 address/prefix, the ER abandons the temporary RLOC and re-engages in 581 the enterprise-interior routing protocol using an RLOC taken from the 582 delegation. 584 In some enterprise network use cases (e.g., MANETs), assignment of 585 RLOCs on enterprise-interior interfaces as singleton addresses (i.e., 586 as addresses with /32 prefix lengths for IPv4, or as addresses with 587 /128 prefix lengths for IPv6) MAY be necessary to avoid multi-link 588 subnet issues. In other use cases, assignment of an RLOC on a VET 589 interface as specified in Appendix B can provide link layer 590 multiplexing and traffic engineering over multiple underlying 591 interfaces using only a single IP address. 593 4.2. Enterprise Border Router (EBR) Autoconfiguration 595 EBRs are ERs that configure VET interfaces over distinct sets of 596 underlying interfaces belonging to the same enterprise network; an 597 EBR can connect to multiple enterprise networks, in which case it 598 would configure multiple VET interfaces. In addition to the ER 599 autoconfiguration procedures specified in Section 4.1, EBRs perform 600 the following autoconfiguration operations. 602 4.2.1. VET Interface Initialization 604 EBRs configure a VET interface over a set of underlying interfaces 605 belonging to the same enterprise network such that all other nodes on 606 the VET link appear as single-hop neighbors from the standpoint of 607 the inner network layer protocol through the use of encapsulation. 608 If there are multiple inner network layer protocols (e.g., IPv4, 609 IPv6, OSI, etc.) the EBR configures a separate VET interface for each 610 protocol. 612 After the EBR configures a VET interface, it binds an RLOC to the 613 interface to serve as the source address for outer IP packets then 614 assigns link-local addresses to the interface if necessary. When 615 IPv6 and IPv4 are used as the inner/outer protocols (respectively), 616 the EBR autoconfigures an IPv6 link-local address on the VET 617 interface using a modified EUI-64 interface identifier based on the 618 IPv4 address (see Section 2.2.1 of [RFC5342]). Link-local address 619 configuration for other inner/outer protocol combinations is through 620 administrative configuration, random self-generation (e.g., 621 [RFC4941], etc.) or through an unspecified alternate method. 622 However, link-local address configuration for other inner/outer 623 protocol combinations may not be necessary if a non-link-local 624 address can be configured through other means (e.g., administrative 625 configuration, DHCP, etc.). 627 The EBR next discovers a Potential Router List (PRL) that includes 628 the RLOC addresses of EBGs. The PRL names the VET interface, and is 629 specific to the address family of the inner network layer protocol 630 (e.g., IPv4, IPv6, OSI, etc.). If there are multiple address 631 families, then there will be multiple VET interfaces; each with its 632 own PRL. 634 The PRL can be discovered through information conveyed in the 635 enterprise-interior routing protocol, through a DHCP option 636 [I-D.templin-isatap-dhcp], etc. In multicast-capable enterprise 637 networks, EBRs can also listen for advertisements on the 'rasadv' 638 [RASADV] multicast group address. 640 Whether or not other information is available, the EBR can resolve an 641 identifying name for the PRL ('PRLNAME') formed as 642 'hostname.domainname', where 'hostname' is an enterprise-specific 643 name string and 'domainname' is an enterprise-specific Domain Name 644 System (DNS) suffix [RFC1035]. The EBR discovers 'PRLNAME' through 645 manual configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 646 protocol advertisements, link-layer information (e.g., an IEEE 802.11 647 Service Set Identifier (SSID)), or through some other means specific 648 to the enterprise network. The EBR can also obtain 'PRLNAME' as part 649 of an arrangement with a private-sector PI prefix vendor (see: 651 Section 4.2.3). 653 In the absence of other information, the EBR sets the 'hostname' 654 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 655 component to an enterprise-specific DNS suffix (e.g., "example.com"). 656 Isolated enterprise networks that do not connect to the outside world 657 may have no enterprise-specific DNS suffix, in which case the 658 'PRLNAME' consists only of the 'hostname' component. (Note that the 659 default hostname "isatapv2" is intentionally distinct from the 660 convention specified in [RFC5214].) 662 After discovering 'PRLNAME', the EBR resolves the name into a list of 663 RLOC addresses through a name service lookup. For centrally managed 664 enterprise networks, the EBR resolves 'PRLNAME' using an enterprise- 665 local name service (e.g., the DNS). For enterprises with no 666 centralized management structure, the EBR resolves 'PRLNAME' using 667 Link-Local Multicast Name Resolution (LLMNR) [RFC4795] over the VET 668 interface. In that case, all EBGs in the PRL respond to the LLMNR 669 query, and the EBR accepts the union of all responses. 671 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 673 EBRs that connect their enterprise networks to a provider network 674 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 675 stateless autoconfiguration mechanisms. The stateful and stateless 676 approaches are discussed in the following subsections. 678 4.2.2.1. Stateful Prefix Delegation 680 For IPv4, EBRs acquire IPv4 PA EID prefixes via an automated IPv4 681 prefix delegation exchange, explicit management, etc. 683 For IPv6, EBRs acquire IPv6 PA EID prefixes via DHCPv6 Prefix 684 Delegation exchanges with an EBG acting as a DHCP relay/server. In 685 particular, the EBR (acting as a requesting router) can use DHCPv6 686 prefix delegation [RFC3633] over the VET interface to obtain prefixes 687 from the server (acting as a delegating router). The EBR obtains 688 prefixes using either a 2-message or 4-message DHCPv6 exchange 689 [RFC3315]. For example, to perform the 2-message exchange, the EBR's 690 DHCPv6 client forwards a Solicit message with an IA_PD option to its 691 DHCPv6 relay, i.e., the EBR acts as a combined client/relay (see 692 Section 4.1). The relay then forwards the message over the VET 693 interface using VET encapsulation (see: Section 5.4) to an EBG which 694 either services the request or relays it further. The forwarded 695 Solicit message will elicit a reply from the server containing prefix 696 delegations. The EBR can also propose a specific prefix to the 697 DHCPv6 server per Section 7 of [RFC3633]. The server will check the 698 proposed prefix for consistency and uniqueness, then return it in the 699 reply to the EBR if it was able to perform the delegation. 701 After the EBR receives IPv4 and/or IPv6 prefix delegations, it can 702 provision the prefixes on enterprise-edge interfaces as well as on 703 other VET interfaces configured over child enterprise networks for 704 which it acts as an EBG. The EBR can also provision the prefixes on 705 enterprise-interior interfaces to service any hosts attached to the 706 link. 708 The prefix delegations remain active as long as the EBR continues to 709 renew them before lease lifetimes expire. The lease lifetime also 710 keeps the delegation state active even if communications between the 711 EBR and delegation server are disrupted for a period of time (e.g., 712 due to an enterprise network partition, power failure, etc.). 714 Stateful prefix delegation for non-IP protocols is out of scope. 716 4.2.2.2. Stateless Prefix Delegation 718 When IPv6 and IPv4 are used as the inner and outer protocols, 719 respectively, a stateless IPv6 PA prefix delegation capability is 720 available using the mechanisms specified in 721 [RFC5569][I-D.ietf-softwire-ipv6-6rd]. EBRs can use these mechanisms 722 to statelessly configure IPv6 PA prefixes that embed one of the EBR's 723 IPv4 RLOCs. 725 Using this stateless prefix delegation, if the IPv4 RLOC changes the 726 IPv6 prefix also changes and the EBR is obliged to renumber any 727 interfaces on which sub-prefixes from the prefix are assigned. This 728 method may therefore be most suitable for enterprise networks in 729 which IPv4 RLOC assignments rarely change, or in enterprise networks 730 in which only services that do not depend on a long-term stable IPv6 731 prefix (e.g., client-side web browsing) are used. 733 Stateless prefix delegation for other protocol combinations is out of 734 scope. 736 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 738 EBRs can acquire Provider Independent (PI) prefixes to facilitate 739 multihoming, mobility and traffic engineering without requiring site- 740 wide renumbering events. These PI prefixes are made available to 741 EBRs through provider-independent registries and without need to 742 coordinate with Internet Service Provider networks. 744 EBRs that connect major enterprise networks (e.g., large 745 corporations, academic campuses, ISP networks, etc.) to a parent 746 enterprise network and/or the global Internet can acquire highly- 747 aggregated PI prefixes (e.g., an IPv6 ::/20, an IPv4 /16, etc.) 748 through a registration authority such as the Internet Assigned 749 Numbers Authority (IANA) or a major regional Internet registry. EBRs 750 that connect small enterprise networks (e.g., SOHO networks, MANETs, 751 etc.) to a parent enterprise network can acquire de-aggregated PI 752 prefixes through arrangements with a PI prefix commercial vendor 753 organization. 755 After an EBR receives PI prefixes, it can sub-delegate portions of 756 the prefixes on enterprise-edge interfaces, on other VET interfaces 757 for which it is configured as an EBG and on enterprise-interior 758 interfaces to service any hosts attached to the link. The EBR can 759 also sub-delegate portions of its PI prefixes to requesting routers 760 within child enterprise networks. These requesting routers consider 761 their sub-delegated portions of the PI prefix as PA, and consider the 762 delegating routers as their points of connection to a provider 763 network. 765 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 767 EBGs are EBRs that connect child enterprise networks to provider 768 networks via provider-edge interfaces and/or via VET interfaces 769 configured over parent enterprise networks. EBGs autoconfigure their 770 provider-edge interfaces in a manner that is specific to the provider 771 connections, and they autoconfigure their VET interfaces that were 772 configured over parent enterprise networks using the EBR 773 autoconfiguration procedures specified in Section 4.2. 775 For each of its VET interfaces configured over a child enterprise 776 network, the EBG initializes the interface the same as for an 777 ordinary EBR (see Section 4.2.1). It then arranges to add one or 778 more of its RLOCs associated with the child enterprise network to the 779 PRL. In particular, for each VET interface configured over a child 780 enterprise network the EBG adds the RLOCs to name service resource 781 records for 'PRLNAME'. 783 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 784 configured over child enterprise networks with a distributed 785 management structure. 787 EBGs configure a DHCP relay/server on VET interfaces configured over 788 child enterprise networks that require DHCP services. 790 To avoid looping, EBGs MUST NOT configure a default route on a VET 791 interface configured over a child enterprise network interface. 793 4.4. VET Host Autoconfiguration 795 Nodes that cannot be attached via an EBR's enterprise-edge interface 796 (e.g., nomadic laptops that connect to a home office via a Virtual 797 Private Network (VPN)) can instead be configured for operation as a 798 simple host connected to the VET interface. Such VET hosts perform 799 the same VET interface initialization and border gateway discovery 800 procedures as specified for EBRs in Section 4.2.1, but they configure 801 their VET interfaces as host interfaces (and not router interfaces). 802 Note also that a node may be configured as a host on some VET 803 interfaces and as an EBR/EBG on other VET interfaces. 805 5. Internetworking Operation 807 Following the autoconfiguration procedures specified in Section 4, 808 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 809 operations as discussed in the following sections. 811 5.1. Routing Protocol Participation 813 ERs engage in any intra-enterprise routing protocols over enterprise- 814 interior interfaces to exchange routing information for forwarding IP 815 packets with RLOC addresses. EBRs and EBGs can additionally engage 816 in any inter-enterprise routing protocols over VET, enterprise-edge 817 and provider-edge interfaces to exchange routing information for 818 forwarding IP packets with EID addresses. Note that the EID-based 819 inter-enterprise IP routing domains are separate and distinct from 820 any RLOC-based enterprise interior IP routing domains. 822 Routing protocol participation on non-multicast VET interfaces uses 823 the NBMA interface model, e.g., in the same manner as for OSPF over 824 NBMA interfaces [RFC5340], while routing protocol participation on 825 multicast-capable VET interfaces uses the standard multicast 826 interface model. EBRs use the list of EBGs in the PRL (see: 827 Section 4.2.1) as an initial list of neighbors for inter-enterprise 828 routing protocol participation. 830 5.1.1. PI Prefix Routing Considerations 832 EBRs that connect large enterprise networks to the global Internet 833 advertise their EID PI prefixes directly into the Internet default- 834 free RIB via the Border Gateway Protocol (BGP) [RFC4271] the same as 835 for a major service provider network. EBRs that connect large 836 enterprise networks to provider networks can instead advertise their 837 EID PI prefixes into the providers' routing system(s) if the provider 838 networks are configured to accept them. 840 EBRs that connect small enterprise networks to provider networks 841 obtain one or more public IP address(es) (i.e., either EID or RLOC IP 842 address) then dynamically register the mapping of their PI prefixes 843 to the public IP address. The registrations are through secured end- 844 to-end exchanges between the EBR and a server in the PI prefix 845 vendor's network (e.g., through a vendor-specific short http(s) 846 transaction). The PI prefix vendor network then acts as a virtual 847 "home" enterprise network that connects its customer small enterprise 848 networks to the Internet routing system with no arrangements needed 849 with the customers' Internet Service Providers. The customer small 850 enterprise networks in turn appear as mobile components of the PI 851 prefix vendor's network, i.e., the customer networks are always "away 852 from home". 854 Further details on routing for PI prefixes is discussed in "The 855 Internet Routing Overlay Network (IRON)" [I-D.templin-iron] and "Fib 856 Suppression with Virtual Aggregation" [I-D.ietf-grow-va]. 858 5.2. Default Route Configuration and Selection 860 Configuration of default routes in the presence of VET interfaces 861 must be carefully coordinated according to the inner and outer 862 network protocols. If the inner and outer protocols are different 863 (e.g., IPv6 within IPv4) then default routes of the inner protocol 864 version can be configured with next-hops corresponding to default 865 routers on a VET interface while default routes of the outer protocol 866 version can be configured with next-hops corresponding to default 867 routers on an underlying interface. 869 If the inner and outer protocols are the same (e.g., IPv4 within 870 IPv4), care must be taken in setting the default route to avoid 871 ambiguity. For example, if default routes are configured on the VET 872 interface then more-specific routes could be configured on underlying 873 interfaces to avoid looping. In a preferred method, however, 874 multiple default routes can be configured with some having next-hops 875 corresponding to (EID-based) default routers on VET interfaces and 876 others having next-hops corresponding to (RLOC-based) default routers 877 on underlying interfaces. In that case, special next-hop 878 determination rules must be used (see: Section 5.4). 880 5.3. Address Selection 882 When permitted by policy and supported by enterprise interior 883 routing, VET nodes can avoid encapsulation through communications 884 that directly invoke the outer IP protocol using RLOC addresses 885 instead of EID addresses for end-to-end communications. For example, 886 an enterprise network that provides native IPv4 intra-enterprise 887 services can provide continued support for native IPv4 communications 888 even when encapsulated IPv6 services are available for inter- 889 enterprise communications. In other enterprise network scenarios, 890 the use of EID-based communications (i.e., instead of RLOC-based 891 communications) may be necessary and/or beneficial to support address 892 scaling, NAT traversal avoidance, security domain separation, site 893 multihoming, traffic engineering, etc. . 895 VET nodes can use source address selection rules (e.g., based on name 896 service information) to determine whether to use EID-based or RLOC- 897 based addressing. The remainder of this section discusses 898 internetworking operation for EID-based communications using the VET 899 interface abstraction. 901 5.4. Next Hop Determination 903 VET nodes perform normal next-hop determination via longest prefix 904 match, and send packets according to the most-specific matching entry 905 in the FIB. If the FIB entry has multiple next-hop addresses, the 906 EBR selects the next-hop with the best metric value. If multiple 907 next hops have the same metric value, the VET node can use Equal Cost 908 Multi Path (ECMP) to forward different flows via different next-hop 909 addresses, where flows are determined, e.g., by computing a hash of 910 the inner packet's source address, destination address and flow label 911 fields. 913 If the VET node has multiple default routes of the same inner and 914 outer protocol versions, with some corresponding to EID-based default 915 routers and others corresponding to RLOC-based default routers, it 916 must perform source address based selection of a default route. In 917 particular, if the packet's source address is taken from an EID 918 prefix the VET node selects a default route configured over the VET 919 interface; otherwise, it selects a default route configured over an 920 underlying interface. 922 As a last resort when there is no matching entry in the FIB (i.e., 923 not even default), VET nodes can discover next-hop addresses within 924 the enterprise network through on-demand name service queries for the 925 EID prefix taken from a packet's destination address (or, by some 926 other inner address to outer address mapping mechanism). For 927 example, for the IPv6 destination address '2001:DB8:1:2::1' and 928 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 929 service lookup for the domain name: 930 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 932 Name-service lookups in enterprise networks with a centralized 933 management structure use an infrastructure-based service, e.g., an 934 enterprise-local DNS. Name-service lookups in enterprise networks 935 with a distributed management structure and/or that lack an 936 infrastructure-based name service instead use LLMNR over the VET 937 interface. When LLMNR is used, the EBR that performs the lookup 938 sends an LLMNR query (with the prefix taken from the IP destination 939 address encoded in dotted-nibble format as shown above) and accepts 940 the union of all replies it receives from other EBRs on the VET 941 interface. When an EBR receives an LLMNR query, it responds to the 942 query IFF it aggregates an IP prefix that covers the prefix in the 943 query. If the name-service lookup succeeds, it will return RLOC 944 addresses (e.g., in DNS A records) that correspond to next-hop EBRs 945 to which the VET node can forward packets. 947 5.5. VET Interface Encapsulation/Decapsulation 949 VET interfaces encapsulate inner network layer packets in any 950 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 951 etc.) followed by a SEAL header (if necessary) followed by an outer 952 UDP header (if necessary) followed by an outer IP header. Following 953 all encapsulations, the VET interface submits the encapsulated packet 954 to the outer IP forwarding engine for transmission on an underlying 955 interface. The following sections provide further details on 956 encapsulation: 958 5.5.1. Inner Network Layer Protocol 960 The inner network layer protocol sees the VET interface as an 961 ordinary network interface, and views the outer network layer 962 protocol as an L2 transport. The inner- and outer network layer 963 protocol types are mutually independent and can be used in any 964 combination. Inner network layer protocol types include IPv6 965 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 966 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 968 5.5.2. Mid-Layer Encapsulation 970 VET interfaces that use mid-layer encapsulations encapsulate each 971 inner network layer packet in any mid-layer headers and trailers as 972 the first step in a potentially multi-layer encapsulation. 974 5.5.3. SEAL Encapsulation 976 Following any mid-layer encapsulations, VET interfaces that use SEAL 977 add a SEAL header as specified in [I-D.templin-intarea-seal]. 978 Inclusion of a SEAL header MUST be applied uniformly between all 979 nodes on the VET link. Note that when a VET interface sends a SEAL- 980 encapsulated packet to a VET node that does not use SEAL 981 encapsulation, it may receive an ICMP "port unreachable" or "protocol 982 unreachable" depending on whether/not an outer UDP header is 983 included. 985 SEAL encapsulation is used on VET links that require path MTU 986 mitigations due to encapsulation overhead and/or mechanisms for VET 987 interface neighbor coordination. When SEAL encapsulation is used, 988 the VET interface sets the 'Next Header' value in the SEAL header to 989 the IP protocol number associated with either the mid-layer 990 encapsulation or the IP protocol number of the inner network layer 991 (if no mid-layer encapsulation is used). 993 The VET interface sets the other fields in the SEAL header as 994 specified in [I-D.templin-intarea-seal]. For SEAL first-segments, 995 the VET interface also sets the R and D flags in the SEAL header in 996 order to control the operation of the SCMP Redirect function (see: 997 Section 5.7.3). The VET interface sets R=1 in the SEAL header of 998 each packet for which it is willing to receive a Redirect message 999 from the neighbor, and sets D=1 in the SEAL header of each packet 1000 that it wishes the neighbor to discard the packet after sending a 1001 redirect (if necessary). The VET interface otherwise sets R=0 and 1002 D=0. 1004 5.5.4. Outer UDP Header Encapsulation 1006 Following any mid-layer and/or SEAL encapsulations, VET interfaces 1007 that use UDP encapsulation add an outer UDP header. Inclusion of an 1008 outer UDP header must be applied uniformly between all nodes on the 1009 VET link. Note that when a VET interface sends a UDP-encapsulated 1010 packet to a node that does not recognize the UDP port number, it may 1011 receive an ICMP "port unreachable" message. 1013 VET interfaces use UDP encapsulation on VET links that may traverse 1014 Network Address Translators (NATs) and/or legacy networking gear that 1015 only recognizes certain network layer protocols, e.g., Equal Cost 1016 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc. 1017 When UDP encapsulation is used, the VET interface encapsulates the 1018 mid-layer packet in an outer UDP header then sets the UDP port 1019 numbers as specified for the outermost mid-layer protocol (e.g., 1020 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 1021 is used as the outermost mid-layer protocol, the VET interface sets 1022 the UDP source port number to a hash calculated over the inner 1023 network layer {destination, source} values or (optionally) over the 1024 inner network layer {dest addr, source addr, protocol, dest port, 1025 source port} values. The VET interface uses a hash function of its 1026 own choosing, but it MUST be consistent in the manner in which the 1027 hash is applied.. 1029 For VET links configured over IPv4 enterprise networks, the VET 1030 interface sets the UDP checksum field to zero. For VET links 1031 configured over IPv6 enterprise networks, the VET interface instead 1032 calculates the UDP checksum and set the calculated value in the 1033 checksum field as required for UDP operation over IPv6. 1035 5.5.5. Outer IP Header Encapsulation 1037 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1038 interface adds an outer IP header. Outer IP header construction is 1039 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1040 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1041 Service/Traffic Class" and "Congestion Experienced" values in the 1042 inner network layer header are copied into the corresponding fields 1043 in the outer IP header. The VET interface also sets the IP protocol 1044 number to the appropriate value for the first protocol layer within 1045 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1046 as the outer IP protocol, the VET interface sets the flow label value 1047 in the outer IPv6 header the same as described in 1048 [I-D.carpenter-flow-ecmp]. 1050 5.5.6. Decapsulation 1052 When a VET interface receives an encapsulated packet, it retains the 1053 outer headers and processes the SEAL header as specified in 1054 [I-D.templin-intarea-seal]. Following SEAL-layer reassembly (if 1055 necessary), the VET interface further examines the R and D bits in 1056 the SEAL header to determine whether Redirects are permitted and 1057 whether the packet is to be discarded following redirect 1058 determination (see: Section 5.7.3). 1060 Next, if the packet will be forwarded from the receiving VET 1061 interface into a forwarding VET interface, the VET node copies the 1062 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1063 Experienced" values in the outer IP header received on the receiving 1064 VET interface into the corresponding fields in the outer IP header to 1065 be sent over the forwarding VET interface (i.e., the values are 1066 transferred between outer headers and *not* copied from the inner 1067 network layer header). This is true even if the packet is forwarded 1068 out the same VET interface that it arrived on, and necessary to 1069 support diagnostic functions (e.g., traceroute) and avoid looping. 1071 During decapsulation, when the next-hop is via a non-VET interface, 1072 the "Congestion Experienced" value in the outer IP header is copied 1073 into the corresponding field in the inner network layer header. 1075 5.6. Mobility and Multihoming Considerations 1077 EBRs that travel between distinct enterprise networks must either 1078 abandon their PA prefixes that are relative to the "old" enterprise 1079 and obtain PA prefixes relative to the "new" enterprise, or somehow 1080 coordinate with a "home" enterprise to retain ownership of the 1081 prefixes. In the first instance, the EBR would be required to 1082 coordinate a network renumbering event using the new PA prefixes 1083 [RFC4192][RFC5887]. In the second instance, an ancillary mobility 1084 management mechanism is required. 1086 EBRs can retain their PI prefixes as they travel between distinct 1087 enterprise networks as long as they update their PI prefix to public 1088 IP address mappings with their PI prefix vendors. This is 1089 accomplished by performing the same PI prefix vendor-specific short 1090 transactions as specified in Section 5.1.1. In this way, EBRs can 1091 update their PI prefix to RLOC mappings in real time as their RLOCs 1092 change. 1094 The EBGs of a multihomed enterprise network participate in a private 1095 inner network layer routing protocol instance between themselves 1096 (possibly over an alternate topology) to accommodate network 1097 partitions/merges as well as intra-enterprise mobility events. 1099 5.7. Neighbor Coordination on VET Interfaces using SEAL 1101 VET interfaces that use SEAL use the SEAL Control Message Protocol 1102 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1103 coordinate reachability, routing information, and mappings between 1104 the inner and outer network layer protocols. SCMP directly parallels 1105 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1106 [RFC4443] protocols, but operates from within the tunnel and supports 1107 operation for any combinations of inner and outer network layer 1108 protocols. 1110 The following subsections discuss VET interface neighbor coordination 1111 using SCMP: 1113 5.7.1. Router Discovery 1115 VET hosts and EBRs can send SCMP Router Solicitation (RS) messages to 1116 one or more EBGs in the PRL to receive solicited SCMP Router 1117 Advertisements (RAs). They then process the RAs the same as for IPv6 1118 ND RA messages, except that they ignore the 'M' and 'O' bits. 1120 When an EBG receives an SCMP RS message on a VET interface, it 1121 prepares a solicited SCMP RA message. The RA includes Router 1122 Lifetimes, Default Router Preferences, PIOs and any other options/ 1123 parameters that the EBG is configured to include. If necessary, the 1124 EBG also includes Route Information Options (RIOs) formatted as 1125 specified in Section 5.7.3, i.e., the RIO may contain both IPv6 and 1126 non-IPv6 prefixes in RIOs as identified by an Address Family 1127 designator. 1129 5.7.2. Neighbor Unreachability Detection 1131 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1132 interface neighbors by monitoring hints of forward progress as 1133 evidence that a neighbor is reachable. SEAL includes an explicit 1134 acknowledgement mechanism that can provide hints of forward progress. 1135 When data packets are flowing, the VET node can periodically set the 1136 A bit in data packets to elicit Neighbor Advertisement (NA) messages 1137 from the neighbor. When no data packets are flowing, the VET node 1138 can send periodic Neighbor Solicitation (NS) messages for the same 1139 purpose. 1141 Responsiveness to routing changes is directly related to the delay in 1142 detecting that a neighbor has gone unreachable. In order to provide 1143 responsiveness comparable to dynamic routing protocols, a reasonably 1144 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1146 Additionally, a VET node may receive outer IP ICMP "Destination 1147 Unreachable; net / host unreachable" messages from an ER on the path 1148 indicating that the path to a VET neighbor may be failing. The node 1149 SHOULD first check the packet-in-error to obtain reasonable assurance 1150 that the ICMP message is authentic. If the node receives excessive 1151 ICMP unreachable errors through multiple RLOCs associated with the 1152 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1153 packets to flow through a different route. 1155 5.7.3. Redirect Function 1157 A VET node (i.e., the redirectee) may receive a redirect message when 1158 it forwards packets over a VET interface to a neighboring VET node 1159 (i.e., the redirector). The redirector will forward the packet and 1160 return an SCMP Redirect message if necessary to inform the redirectee 1161 of a better next hop. Unlike ordinary ICMP redirects, the redirector 1162 sends an SCMP Redirect message (subject to rate limiting) whenever it 1163 receives a packet with R=1 in the SEAL header for which there is a 1164 better next hop on the same VET interface that it arrived on 1165 regardless of whether the inner source address of the packet was on- 1166 link. The redirector also discards packets with D=1 in the SEAL 1167 header after sending a redirect (if necessary) and before forwarding 1168 the packet to the next hop. 1170 The SCMP Redirect message is formatted the same as for ordinary 1171 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1172 the Destination and Target Address fields are unnecessary and 1173 therefore omitted. The format of the SCMP Redirect message is shown 1174 in Figure 2 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Type = 137 | Code = 0 | Checksum | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Reserved | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Options ... 1183 +-+-+-+-+-+-+-+-+-+-+-+- 1185 Figure 2: SCMP Redirect Message Format 1187 The redirector then adds any necessary Options to the Redirect 1188 message. It first includes one or more Target Link-Layer Address 1189 Options (TLLAOs) (see: Section 4.6.1 of [RFC4861]) that include RLOCs 1190 corresponding to better next hops. The TLLAO formats for IPv4 and 1191 IPv6 RLOCs are shown in Figure 3 and Figure 4: 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Type = 2 | Length = 1 | Reserved | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | IPv4 address (bytes 0 thru 3) | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 Figure 3: SCMP TLLAO Option for IPv4 RLOCs 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Type = 2 | Length = 3 | Reserved | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Reserved | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | IPv6 address (bytes 0 thru 3) | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | IPv6 address (bytes 4 thru 7) | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | IPv6 address (bytes 8 thru 11) | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | IPv6 address (bytes 12 thru 15) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 Figure 4: SCMP TLLAO Option for IPv6 RLOCs 1221 The redirector next includes a Route Information Option (RIO) (see: 1222 [RFC4191]) that contains a prefix from its FIB that covers the 1223 destination address of the original packet. SCMP uses a modified 1224 version of the RIO option formatted as shown in Figure 5: 1226 0 1 2 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Type = 24 | Length | Prefix Length | AF |Prf|E|RSV| 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Route Lifetime | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Prefix (Variable Length) | 1234 . . 1235 . . 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 Figure 5: SCMP Route Information Option Format 1240 In this modified format, the redirector prepares the Route Lifetime 1241 and Prefix fields in the RIO option the same as specified in 1242 [RFC4191]. It then sets the fields in the header as follows: 1244 o the 'Type', 'Length' and 'Prf' fields are set the same as 1245 specified in [RFC4191]. 1247 o the 'RSV' field is set to 0. 1249 o he 'Length' field is set to 1, 2, or 3 as specified in [RFC4191], 1250 or set to 4 if the 'Prefix Length' is greater than 128 in order to 1251 accommodate prefixes of non-IP protocols of up to 192 bits in 1252 length. 1254 o the 'Prefix Length' field ranges from 0 to 192. The 'Prefix' 1255 field is 0, 8, 16 or 24 octets depending on the length, and the 1256 embedded prefix MAY be up to 192 bits in length. 1258 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1259 that indicates the embedded prefix protocol type. This document 1260 defines the following values for AF: 1262 * 000 - IPv4 1264 * 001 - IPv6 1266 * 010 - OSI/CLNP NSAP 1268 o the 'E' bit is set to 1 if this prefix is assigned to an End User 1269 Network, and set to 0 otherwise. 1271 Following the RIO option, the redirector includes any other necessary 1272 options (e.g., SEND options) followed by a Redirected Header 1273 containing the leading portion of the packet that triggered the 1274 redirect as the final option in the message. The redirector then 1275 encapsulates the Redirect message the same as for any other SCMP 1276 message and sends it to the redirectee. 1278 When the redirectee receives the Redirect, it first authenticates the 1279 message (i.e., by checking the SEAL_ID in the Redirected Header, by 1280 examining SEND options, etc.) then uses the EID prefix in the RIO 1281 with its respective lifetime to update its FIB. The redirectee also 1282 caches the IPv4 or IPv6 addresses in TLLAOs as the layer 2 addresses 1283 of potential next-hops. 1285 The redirectee retains the FIB entry created as a result of receipt 1286 of an SCMP Redirect until the route lifetime expires, or until the 1287 redirected target neighbor becomes unreachable. In this way, RLOC 1288 liveness detection parallels IPv6 Neighbor Unreachability Detection 1289 as discussed in the next section. 1291 5.7.4. Mobility 1293 When a VET node moves to a new network point of attachment resulting 1294 in the change of an old RLOC to a new RLOC, it informs any 1295 correspondents of the change by sending specially-crafted SCMP 1296 Neighbor Advertisement (NA) messages. The VET node can ensure 1297 reliable delivery of the NA messages by setting the 'A' bit in the 1298 SEAL header in order to receive an explicit acknowledgement. The VET 1299 node SHOULD retry up to three times to get an explicit 1300 acknowledgement before abandoning the attempt. 1302 The NA messages use the new RLOC as the outer IP source address and 1303 include the old RLOC in a Source Link Layer Address Option (SLLAO) 1304 formatted exactly as specified for TLLAOs in Section 5.7.3. When the 1305 neighbor receives the NA, it authenticates the message then replaces 1306 the old RLOC address with the new RLOC address. Methods for 1307 authenticating the NA are out of scope for this document. 1309 5.8. Neighbor Coordination on VET Interfaces using IPsec 1311 VET interfaces that use IPsec encapsulation use the Internet Key 1312 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1313 association setup and maintenance. The IKEv2 can be seen as a 1314 logical equivalent of the SEAL SCMP in terms of VET interface 1315 neighbor coordinations. In particular, IKEv2 also provides 1316 mechanisms for redirection [RFC5685] and mobility [RFC4555]. 1318 IPsec additionally provides an extended Identification field and 1319 integrity check vector; these features allow IPsec to utilize outer 1320 IP fragmentation and reassembly with less risk of exposure to data 1321 corruption due to reassembly misassociations. On the other hand, 1322 IPsec entails the use of symmetric security associations and hence 1323 may not be appropriate to all enterprise network use cases. 1325 5.9. Multicast 1327 In multicast-capable deployments, ERs provide an enterprise-wide 1328 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1329 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1330 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1331 over their enterprise-interior interfaces such that outer IP 1332 multicast messages of site-scope or greater scope will be propagated 1333 across the enterprise network. For such deployments, VET nodes can 1334 also provide an inner multicast/broadcast capability over their VET 1335 interfaces through mapping of the inner multicast address space to 1336 the outer multicast address space. In that case, operation of link- 1337 scoped (or greater scoped) inner multicasting services (e.g., a link- 1338 scoped neighbor discovery protocol) over the VET interface is 1339 available, but should be used sparingly to minimize enterprise-wide 1340 flooding. 1342 VET nodes encapsulate inner multicast messages sent over the VET 1343 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1344 followed by an outer IP header with a site-scoped outer IP multicast 1345 address as the destination. For the case of IPv6 and IPv4 as the 1346 inner/outer protocols (respectively), [RFC2529] provides mappings 1347 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1348 address space (for other encapsulations, mappings are established 1349 through administrative configuration or through an unspecified 1350 alternate static mapping). 1352 Multicast mapping for inner multicast groups over outer IP multicast 1353 groups can be accommodated, e.g., through VET interface snooping of 1354 inner multicast group membership and routing protocol control 1355 messages. To support inner-to-outer multicast address mapping, the 1356 VET interface acts as a virtual outer IP multicast host connected to 1357 its underlying interfaces. When the VET interface detects that an 1358 inner multicast group joins or leaves, it forwards corresponding 1359 outer IP multicast group membership reports on an underlying 1360 interface over which the VET interface is configured. If the VET 1361 node is configured as an outer IP multicast router on the underlying 1362 interfaces, the VET interface forwards locally looped-back group 1363 membership reports to the outer IP multicast routing process. If the 1364 VET node is configured as a simple outer IP multicast host, the VET 1365 interface instead forwards actual group membership reports (e.g., 1366 IGMP messages) directly over an underlying interface. 1368 Since inner multicast groups are mapped to site-scoped outer IP 1369 multicast groups, the VET node MUST ensure that the site-scope outer 1370 IP multicast messages received on the underlying interfaces for one 1371 VET interface do not "leak out" to the underlying interfaces of 1372 another VET interface. This is accommodated through normal site- 1373 scoped outer IP multicast group filtering at enterprise network 1374 boundaries. 1376 5.10. Service Discovery 1378 VET nodes can perform enterprise-wide service discovery using a 1379 suitable name-to-address resolution service. Examples of flooding- 1380 based services include the use of LLMNR [RFC4795] over the VET 1381 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1382 over an underlying interface. More scalable and efficient service 1383 discovery mechanisms are for further study. 1385 5.11. Enterprise Network Partitioning 1387 An enterprise network can be partitioned into multiple distinct 1388 logical groupings. In that case, each partition configures its own 1389 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1390 'isatapv2.zone2.example.com', etc.). 1392 EBGs can further create multiple IP subnets within a partition by 1393 sending RAs with PIOs containing different IPv6 prefixes to different 1394 groups of nodes. EBGs can identify subnets, e.g., by examining RLOC 1395 prefixes, observing the enterprise interior interfaces over which RSs 1396 are received, etc. 1398 5.12. EBG Prefix State Recovery 1400 EBGs retain explicit state that tracks the inner PA prefixes 1401 delegated to EBRs within the enterprise network, e.g., so that 1402 packets are delivered to the correct EBRs. When an EBG loses some or 1403 all of its state (e.g., due to a power failure), it must recover the 1404 state so that packets can be forwarded over correct routes. 1406 5.13. Support for Legacy ISATAP Services 1408 EBGs support legacy ISATAP services according to the specifications 1409 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1410 interfaces and VET interfaces over the same sets of underlying 1411 interfaces as long as the PRLs and IPv6 prefixes associated with the 1412 ISATAP/VET interfaces are distinct. 1414 6. IANA Considerations 1416 There are no IANA considerations for this document. 1418 7. Security Considerations 1420 Security considerations for MANETs are found in [RFC2501]. 1422 The security considerations found in 1423 [RFC2529][RFC5214][I-D.nakibly-v6ops-tunnel-loops] also apply to VET. 1425 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1426 where attacks on the neighbor coordination protocol are possible. 1427 SEAL [I-D.templin-intarea-seal] provides a per-packet identification 1428 that can be used to detect source address spoofing. 1430 Rogue neighbor coordination messages with spoofed RLOC source 1431 addresses can consume network resources and cause VET nodes to 1432 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1433 such RLOCs, as that may result in a denial of service to the RLOCs' 1434 legitimate owners. 1436 VET EBRs and EBGs observe the recommendations for network ingress 1437 filtering [RFC2827]. 1439 8. Related Work 1441 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1442 automatic tunneling in [RFC2529]; this concept was later called: 1443 "Virtual Ethernet" and investigated by Quang Nguyen under the 1444 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1445 their colleagues have motivated a number of foundational concepts on 1446 which this work is based. 1448 Telcordia has proposed DHCP-related solutions for MANETs through the 1449 CECOM MOSAIC program. 1451 The Naval Research Lab (NRL) Information Technology Division uses 1452 DHCP in their MANET research testbeds. 1454 Security concerns pertaining to tunneling mechanisms are discussed in 1455 [I-D.ietf-v6ops-tunnel-security-concerns]. 1457 Default router and prefix information options for DHCPv6 are 1458 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1460 An automated IPv4 prefix delegation mechanism is proposed in 1461 [I-D.ietf-dhc-subnet-alloc]. 1463 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1464 [I-D.clausen-manet-autoconf-recommendations]. 1466 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1468 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1469 decapsulation issues and other aspects of tunneling. 1471 Various proposals within the IETF have suggested similar mechanisms. 1473 9. Acknowledgements 1475 The following individuals gave direct and/or indirect input that was 1476 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1477 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1478 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1479 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1480 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1481 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1482 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1483 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1484 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1485 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1486 working groups. Many others have provided guidance over the course 1487 of many years. 1489 10. Contributors 1491 The following individuals have contributed to this document: 1493 Eric Fleischman (eric.fleischman@boeing.com) 1494 Thomas Henderson (thomas.r.henderson@boeing.com) 1495 Steven Russert (steven.w.russert@boeing.com) 1496 Seung Yi (seung.yi@boeing.com) 1498 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1499 of the document. 1501 Jim Bound's foundational work on enterprise networks provided 1502 significant guidance for this effort. We mourn his loss and honor 1503 his contributions. 1505 11. References 1507 11.1. Normative References 1509 [I-D.templin-intarea-seal] 1510 Templin, F., "The Subnetwork Encapsulation and Adaptation 1511 Layer (SEAL)", draft-templin-intarea-seal-15 (work in 1512 progress), June 2010. 1514 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1515 September 1981. 1517 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1518 RFC 792, September 1981. 1520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1521 Requirement Levels", BCP 14, RFC 2119, March 1997. 1523 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1524 RFC 2131, March 1997. 1526 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1527 (IPv6) Specification", RFC 2460, December 1998. 1529 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1530 Defeating Denial of Service Attacks which employ IP Source 1531 Address Spoofing", BCP 38, RFC 2827, May 2000. 1533 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1534 and M. Carney, "Dynamic Host Configuration Protocol for 1535 IPv6 (DHCPv6)", RFC 3315, July 2003. 1537 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1538 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1539 December 2003. 1541 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1542 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1544 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1545 RFC 3972, March 2005. 1547 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1548 More-Specific Routes", RFC 4191, November 2005. 1550 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1551 Architecture", RFC 4291, February 2006. 1553 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1554 Message Protocol (ICMPv6) for the Internet Protocol 1555 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1557 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1558 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1559 September 2007. 1561 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1562 Address Autoconfiguration", RFC 4862, September 2007. 1564 [RFC5342] Eastlake. , D., "IANA Considerations and IETF Protocol 1565 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, 1566 September 2008. 1568 11.2. Informative References 1570 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1571 Switching Networks", May 1974. 1573 [I-D.carpenter-flow-ecmp] 1574 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1575 for equal cost multipath routing and link aggregation in 1576 tunnels", draft-carpenter-flow-ecmp-02 (work in progress), 1577 April 2010. 1579 [I-D.cheshire-dnsext-multicastdns] 1580 Cheshire, S. and M. Krochmal, "Multicast DNS", 1581 draft-cheshire-dnsext-multicastdns-11 (work in progress), 1582 March 2010. 1584 [I-D.clausen-manet-autoconf-recommendations] 1585 Clausen, T. and U. Herberg, "MANET Router Configuration 1586 Recommendations", 1587 draft-clausen-manet-autoconf-recommendations-00 (work in 1588 progress), February 2009. 1590 [I-D.clausen-manet-linktype] 1591 Clausen, T., "The MANET Link Type", 1592 draft-clausen-manet-linktype-00 (work in progress), 1593 October 2008. 1595 [I-D.droms-dhc-dhcpv6-default-router] 1596 Droms, R. and T. Narten, "Default Router and Prefix 1597 Advertisement Options for DHCPv6", 1598 draft-droms-dhc-dhcpv6-default-router-00 (work in 1599 progress), March 2009. 1601 [I-D.ietf-dhc-subnet-alloc] 1602 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1603 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1604 (work in progress), May 2010. 1606 [I-D.ietf-grow-va] 1607 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1608 L. Zhang, "FIB Suppression with Virtual Aggregation", 1609 draft-ietf-grow-va-02 (work in progress), March 2010. 1611 [I-D.ietf-lisp] 1612 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1613 "Locator/ID Separation Protocol (LISP)", 1614 draft-ietf-lisp-07 (work in progress), April 2010. 1616 [I-D.ietf-manet-smf] 1617 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1618 draft-ietf-manet-smf-10 (work in progress), March 2010. 1620 [I-D.ietf-softwire-ipv6-6rd] 1621 Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 1622 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 1623 (work in progress), May 2010. 1625 [I-D.ietf-v6ops-tunnel-security-concerns] 1626 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1627 Concerns With IP Tunneling", 1628 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 1629 progress), March 2010. 1631 [I-D.jen-apt] 1632 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1633 L. Zhang, "APT: A Practical Transit Mapping Service", 1634 draft-jen-apt-01 (work in progress), November 2007. 1636 [I-D.nakibly-v6ops-tunnel-loops] 1637 Nakibly, G. and F. Templin, "Routing Loop Attack using 1638 IPv6 Automatic Tunnels: Problem Statement and Proposed 1639 Mitigations", draft-nakibly-v6ops-tunnel-loops-02 (work in 1640 progress), May 2010. 1642 [I-D.russert-rangers] 1643 Russert, S., Fleischman, E., and F. Templin, "Operational 1644 Scenarios for IRON and RANGER", draft-russert-rangers-03 1645 (work in progress), June 2010. 1647 [I-D.templin-iron] 1648 Templin, F., "The Internet Routing Overlay Network 1649 (IRON)", draft-templin-iron-03 (work in progress), 1650 June 2010. 1652 [I-D.templin-isatap-dhcp] 1653 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1654 Option for the Intra-Site Automatic Tunnel Addressing 1655 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1656 progress), December 2009. 1658 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1659 July 1978. 1661 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1662 Protocol Specification", October 2008. 1664 [RFC0994] International Organization for Standardization (ISO) and 1665 American National Standards Institute (ANSI), "Final text 1666 of DIS 8473, Protocol for Providing the Connectionless- 1667 mode Network Service", RFC 994, March 1986. 1669 [RFC1035] Mockapetris, P., "Domain names - implementation and 1670 specification", STD 13, RFC 1035, November 1987. 1672 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1673 a subnetwork for experimentation with the OSI network 1674 layer", RFC 1070, February 1989. 1676 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1677 Communication Layers", STD 3, RFC 1122, October 1989. 1679 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1680 Routing and Addressing Architecture", RFC 1753, 1681 December 1994. 1683 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1684 E. Lear, "Address Allocation for Private Internets", 1685 BCP 5, RFC 1918, February 1996. 1687 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1688 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1690 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1691 October 1996. 1693 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1694 Extensions", RFC 2132, March 1997. 1696 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1697 IPv6 Specification", RFC 2473, December 1998. 1699 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1700 over Non-Broadcast Multiple Access (NBMA) networks", 1701 RFC 2491, January 1999. 1703 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1704 (MANET): Routing Protocol Performance Issues and 1705 Evaluation Considerations", RFC 2501, January 1999. 1707 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1708 Domains without Explicit Tunnels", RFC 2529, March 1999. 1710 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1711 February 2000. 1713 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1714 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1715 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1716 RFC 3819, July 2004. 1718 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1719 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1720 May 2005. 1722 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1723 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1724 January 2005. 1726 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1727 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1728 RFC 3948, January 2005. 1730 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1731 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1732 September 2005. 1734 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1735 Addresses", RFC 4193, October 2005. 1737 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1738 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1740 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1741 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1743 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1744 Internet Protocol", RFC 4301, December 2005. 1746 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1747 RFC 4306, December 2005. 1749 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1750 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1751 May 2006. 1753 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1754 (MOBIKE)", RFC 4555, June 2006. 1756 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1757 Multicast Name Resolution (LLMNR)", RFC 4795, 1758 January 2007. 1760 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1761 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1762 Focus", RFC 4852, April 2007. 1764 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1765 June 2007. 1767 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1768 Extensions for Stateless Address Autoconfiguration in 1769 IPv6", RFC 4941, September 2007. 1771 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1772 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1773 March 2008. 1775 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1776 for IPv6", RFC 5340, July 2008. 1778 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1779 Infrastructures (6rd)", RFC 5569, January 2010. 1781 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1782 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1783 RFC 5685, November 2009. 1785 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1786 Global Enterprise Recursion (RANGER)", RFC 5720, 1787 February 2010. 1789 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1790 Still Needs Work", RFC 5887, May 2010. 1792 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 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 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 -14 to -15: 1981 o new insights into default route configuration and next-hop 1982 determination 1984 Changes from -13 to -14: 1986 o fixed Idnits 1988 Changes from -12 to -13: 1990 o Changed "VGL" *back* to "PRL" 1992 o More changes for multi-protocol support 1994 o Changes to Redirect function 1996 Changes from -11 to -12: 1998 o Major section rearrangement 2000 o Changed "PRL" to "VGL" 2002 o Brought back text that was lost in the -10 to -11 transition 2004 Changes from -10 to -11: 2006 o Major changes with significant simplifications 2008 o Now support stateless PD using 6rd mechanisms 2010 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2012 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2014 Changes from -09 to -10: 2016 o Changed "enterprise" to "enterprise network" throughout 2018 o dropped "inner IP", since inner layer may be non-IP 2020 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2021 messages remain *within* the tunnel interface instead of being 2022 exposed to the inner network layer protocol engine. 2024 Changes from -08 to -09: 2026 o Expanded discussion of encapsulation/decapsulation procedures 2027 o cited IRON 2029 Changes from -07 to -08: 2031 o Specified the approach to global mapping using virtual aggregation 2032 and BGP 2034 Changes from -06 to -07: 2036 o reworked redirect function 2038 o created new section on VET interface encapsulation 2040 o clarifications on nexthop selection 2042 o fixed several bugs 2044 Changed from -05 to -06: 2046 o reworked VET interface ND 2048 o anycast clarifications 2050 Changes from -03 to -04: 2052 o security consideration clarifications 2054 Changes from -02 to -03: 2056 o security consideration clarifications 2058 o new PRLNAME for VET is "isatav2.example.com" 2060 o VET now uses SEAL natively 2062 o EBGs can support both legacy ISATAP and VET over the same 2063 underlying interfaces. 2065 Changes from -01 to -02: 2067 o Defined CGA and privacy address configuration on VET interfaces 2069 o Interface identifiers added to routing protocol control messages 2070 for link-layer multiplexing 2072 Changes from -00 to -01: 2074 o Section 4.1 clarifications on link-local assignment and RLOC 2075 autoconfiguration. 2077 o Appendix B clarifications on Weak End System Model 2079 Changes from RFC5558 to -00: 2081 o New appendix on RLOC configuration on VET interfaces. 2083 Author's Address 2085 Fred L. Templin (editor) 2086 Boeing Research & Technology 2087 P.O. Box 3707 MC 7L-49 2088 Seattle, WA 98124 2089 USA 2091 Email: fltemplin@acm.org