idnits 2.17.1 draft-templin-intarea-vet-14.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 7, 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-14 ** 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-02 -- 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 7, 2010 5 Expires: December 9, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-14.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 9, 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 . . . . . . . . . . . . . . . 20 74 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 20 75 5.4. Next Hop Determination . . . . . . . . . . . . . . . . . . 21 76 5.5. VET Interface Encapsulation/Decapsulation . . . . . . . . 21 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 . . . . . . . . . . . . 23 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 . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . 29 91 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . 31 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 97 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 32 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 103 Appendix A. Duplicate Address Detection (DAD) Considerations . . 39 104 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 40 105 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 42 106 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 43 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 109 1. Introduction 111 Enterprise networks [RFC4852] connect hosts and routers over various 112 link types (see [RFC4861], Section 2.2). The term "enterprise 113 network" in this context extends to a wide variety of use cases and 114 deployment scenarios. For example, an "enterprise" can be as small 115 as a SOHO network, as complex as a multi-organizational corporation, 116 or as large as the global Internet itself. ISP networks are another 117 example use case that fits well with the VET enterprise network 118 model. Mobile Ad hoc Networks (MANETs) [RFC2501] can also be 119 considered as a challenging example of an enterprise network, in that 120 their topologies may change dynamically over time and that they may 121 employ little/no active management by a centralized network 122 administrative authority. These specialized characteristics for 123 MANETs require careful consideration, but the same principles apply 124 equally to other enterprise network scenarios. 126 This document specifies a Virtual Enterprise Traversal (VET) 127 abstraction for autoconfiguration and internetworking operation, 128 where addresses of different scopes may be assigned on various types 129 of interfaces with diverse properties. Both IPv4/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 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 a default route of the inner protocol 864 version can be configured on a VET interface while a default route of 865 the outer protocol version can be configured on an underlying 866 interface. If the inner and outer protocols are the same however 867 (e.g., IPv4 within IPv4), care must be taken in setting the default 868 route to avoid ambiguity. For example, if a default route is 869 configured on the VET interface then more-specific routes must be 870 configured on underlying interfaces to avoid looping. 872 5.3. Address Selection 874 When permitted by policy and supported by enterprise interior 875 routing, VET nodes can avoid encapsulation through communications 876 that directly invoke the outer IP protocol using RLOC addresses 877 instead of EID addresses for end-to-end communications. For example, 878 an enterprise network that provides native IPv4 intra-enterprise 879 services can provide continued support for native IPv4 communications 880 even when encapsulated IPv6 services are available for inter- 881 enterprise communications. In other enterprise network scenarios, 882 the use of EID-based communications (i.e., instead of RLOC-based 883 communications) may be necessary and/or beneficial to support address 884 scaling, NAT traversal avoidance, security domain separation, site 885 multihoming, traffic engineering, etc. . 887 VET nodes can use source address selection rules (e.g., based on name 888 service information) to determine whether to use EID-based or RLOC- 889 based addressing. The remainder of this section discusses 890 internetworking operation for EID-based communications using the VET 891 interface abstraction. 893 5.4. Next Hop Determination 895 VET nodes perform normal next-hop determination via longest prefix 896 match, and send packets according to the most-specific matching entry 897 in the FIB. If the FIB entry has multiple next-hop addresses, the 898 EBR selects the next-hop with the best metric value. If multiple 899 next hops have the same metric value, the VET node can use Equal Cost 900 Multi Path (ECMP) to forward different flows via different next-hop 901 addresses, where flows are determined, e.g., by computing a hash of 902 the inner packet's source address, destination address and flow label 903 fields. 905 As a last resort when there is no matching entry in the FIB (i.e., 906 not even default), VET nodes can discover next-hop addresses within 907 the enterprise network through on-demand name service queries for the 908 EID prefix taken from a packet's destination address (or, by some 909 other inner address to outer address mapping mechanism). For 910 example, for the IPv6 destination address '2001:DB8:1:2::1' and 911 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 912 service lookup for the domain name: 913 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 915 Name-service lookups in enterprise networks with a centralized 916 management structure use an infrastructure-based service, e.g., an 917 enterprise-local DNS. Name-service lookups in enterprise networks 918 with a distributed management structure and/or that lack an 919 infrastructure-based name service instead use LLMNR over the VET 920 interface. When LLMNR is used, the EBR that performs the lookup 921 sends an LLMNR query (with the prefix taken from the IP destination 922 address encoded in dotted-nibble format as shown above) and accepts 923 the union of all replies it receives from other EBRs on the VET 924 interface. When an EBR receives an LLMNR query, it responds to the 925 query IFF it aggregates an IP prefix that covers the prefix in the 926 query. If the name-service lookup succeeds, it will return RLOC 927 addresses (e.g., in DNS A records) that correspond to next-hop EBRs 928 to which the VET node can forward packets. 930 5.5. VET Interface Encapsulation/Decapsulation 932 VET interfaces encapsulate inner network layer packets in any 933 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 934 etc.) followed by a SEAL header (if necessary) followed by an outer 935 UDP header (if necessary) followed by an outer IP header. Following 936 all encapsulations, the VET interface submits the encapsulated packet 937 to the outer IP forwarding engine for transmission on an underlying 938 interface. The following sections provide further details on 939 encapsulation: 941 5.5.1. Inner Network Layer Protocol 943 The inner network layer protocol sees the VET interface as an 944 ordinary network interface, and views the outer network layer 945 protocol as an L2 transport. The inner- and outer network layer 946 protocol types are mutually independent and can be used in any 947 combination. Inner network layer protocol types include IPv6 948 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 949 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 951 5.5.2. Mid-Layer Encapsulation 953 VET interfaces that use mid-layer encapsulations encapsulate each 954 inner network layer packet in any mid-layer headers and trailers as 955 the first step in a potentially multi-layer encapsulation. 957 5.5.3. SEAL Encapsulation 959 Following any mid-layer encapsulations, VET interfaces that use SEAL 960 add a SEAL header as specified in [I-D.templin-intarea-seal]. 961 Inclusion of a SEAL header MUST be applied uniformly between all 962 nodes on the VET link. Note that when a VET interface sends a SEAL- 963 encapsulated packet to a VET node that does not use SEAL 964 encapsulation, it may receive an ICMP "port unreachable" or "protocol 965 unreachable" depending on whether/not an outer UDP header is 966 included. 968 SEAL encapsulation is used on VET links that require path MTU 969 mitigations due to encapsulation overhead and/or mechanisms for VET 970 interface neighbor coordination. When SEAL encapsulation is used, 971 the VET interface sets the 'Next Header' value in the SEAL header to 972 the IP protocol number associated with either the mid-layer 973 encapsulation or the IP protocol number of the inner network layer 974 (if no mid-layer encapsulation is used). 976 The VET interface sets the other fields in the SEAL header as 977 specified in [I-D.templin-intarea-seal]. For SEAL first-segments, 978 the VET interface also sets the R and D flags in the SEAL header in 979 order to control the operation of the SCMP Redirect function (see: 980 Section 5.7.3). The VET interface sets R=1 in the SEAL header of 981 each packet for which it is willing to receive a Redirect message 982 from the neighbor, and sets D=1 in the SEAL header of each packet 983 that it wishes the neighbor to discard the packet after sending a 984 redirect (if necessary). The VET interface otherwise sets R=0 and 985 D=0. 987 5.5.4. Outer UDP Header Encapsulation 989 Following any mid-layer and/or SEAL encapsulations, VET interfaces 990 that use UDP encapsulation add an outer UDP header. Inclusion of an 991 outer UDP header must be applied uniformly between all nodes on the 992 VET link. Note that when a VET interface sends a UDP-encapsulated 993 packet to a node that does not recognize the UDP port number, it may 994 receive an ICMP "port unreachable" message. 996 VET interfaces use UDP encapsulation on VET links that may traverse 997 Network Address Translators (NATs) and/or legacy networking gear that 998 only recognizes certain network layer protocols, e.g., Equal Cost 999 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc. 1000 When UDP encapsulation is used, the VET interface encapsulates the 1001 mid-layer packet in an outer UDP header then sets the UDP port 1002 numbers as specified for the outermost mid-layer protocol (e.g., 1003 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 1004 is used as the outermost mid-layer protocol, the VET interface sets 1005 the UDP source port number to a hash calculated over the inner 1006 network layer {destination, source} values or (optionally) over the 1007 inner network layer {dest addr, source addr, protocol, dest port, 1008 source port} values. The VET interface uses a hash function of its 1009 own choosing, but it MUST be consistent in the manner in which the 1010 hash is applied.. 1012 For VET links configured over IPv4 enterprise networks, the VET 1013 interface sets the UDP checksum field to zero. For VET links 1014 configured over IPv6 enterprise networks, the VET interface instead 1015 calculates the UDP checksum and set the calculated value in the 1016 checksum field as required for UDP operation over IPv6. 1018 5.5.5. Outer IP Header Encapsulation 1020 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1021 interface adds an outer IP header. Outer IP header construction is 1022 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1023 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1024 Service/Traffic Class" and "Congestion Experienced" values in the 1025 inner network layer header are copied into the corresponding fields 1026 in the outer IP header. The VET interface also sets the IP protocol 1027 number to the appropriate value for the first protocol layer within 1028 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1029 as the outer IP protocol, the VET interface sets the flow label value 1030 in the outer IPv6 header the same as described in 1031 [I-D.carpenter-flow-ecmp]. 1033 5.5.6. Decapsulation 1035 When a VET interface receives an encapsulated packet, it retains the 1036 outer headers and processes the SEAL header as specified in 1037 [I-D.templin-intarea-seal]. Following SEAL-layer reassembly (if 1038 necessary), the VET interface further examines the R and D bits in 1039 the SEAL header to determine whether Redirects are permitted and 1040 whether the packet is to be discarded following redirect 1041 determination (see: Section 5.7.3). 1043 Next, if the packet will be forwarded from the receiving VET 1044 interface into a forwarding VET interface, the VET node copies the 1045 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1046 Experienced" values in the outer IP header received on the receiving 1047 VET interface into the corresponding fields in the outer IP header to 1048 be sent over the forwarding VET interface (i.e., the values are 1049 transferred between outer headers and *not* copied from the inner 1050 network layer header). This is true even if the packet is forwarded 1051 out the same VET interface that it arrived on, and necessary to 1052 support diagnostic functions (e.g., traceroute) and avoid looping. 1054 During decapsulation, when the next-hop is via a non-VET interface, 1055 the "Congestion Experienced" value in the outer IP header is copied 1056 into the corresponding field in the inner network layer header. 1058 5.6. Mobility and Multihoming Considerations 1060 EBRs that travel between distinct enterprise networks must either 1061 abandon their PA prefixes that are relative to the "old" enterprise 1062 and obtain PA prefixes relative to the "new" enterprise, or somehow 1063 coordinate with a "home" enterprise to retain ownership of the 1064 prefixes. In the first instance, the EBR would be required to 1065 coordinate a network renumbering event using the new PA prefixes 1066 [RFC4192][RFC5887]. In the second instance, an ancillary mobility 1067 management mechanism is required. 1069 EBRs can retain their PI prefixes as they travel between distinct 1070 enterprise networks as long as they update their PI prefix to public 1071 IP address mappings with their PI prefix vendors. This is 1072 accomplished by performing the same PI prefix vendor-specific short 1073 transactions as specified in Section 5.1.1. In this way, EBRs can 1074 update their PI prefix to RLOC mappings in real time as their RLOCs 1075 change. 1077 The EBGs of a multihomed enterprise network participate in a private 1078 inner network layer routing protocol instance between themselves 1079 (possibly over an alternate topology) to accommodate network 1080 partitions/merges as well as intra-enterprise mobility events. 1082 5.7. Neighbor Coordination on VET Interfaces using SEAL 1084 VET interfaces that use SEAL use the SEAL Control Message Protocol 1085 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1086 coordinate reachability, routing information, and mappings between 1087 the inner and outer network layer protocols. SCMP directly parallels 1088 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1089 [RFC4443] protocols, but operates from within the tunnel and supports 1090 operation for any combinations of inner and outer network layer 1091 protocols. 1093 The following subsections discuss VET interface neighbor coordination 1094 using SCMP: 1096 5.7.1. Router Discovery 1098 VET hosts and EBRs can send SCMP Router Solicitation (RS) messages to 1099 one or more EBGs in the PRL to receive solicited SCMP Router 1100 Advertisements (RAs). They then process the RAs the same as for IPv6 1101 ND RA messages, except that they ignore the 'M' and 'O' bits. 1103 When an EBG receives an SCMP RS message on a VET interface, it 1104 prepares a solicited SCMP RA message. The RA includes Router 1105 Lifetimes, Default Router Preferences, PIOs and any other options/ 1106 parameters that the EBG is configured to include. If necessary, the 1107 EBG also includes Route Information Options (RIOs) formatted as 1108 specified in Section 5.7.3, i.e., the RIO may contain both IPv6 and 1109 non-IPv6 prefixes in RIOs as identified by an Address Family 1110 designator. 1112 5.7.2. Neighbor Unreachability Detection 1114 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1115 interface neighbors by monitoring hints of forward progress as 1116 evidence that a neighbor is reachable. SEAL includes an explicit 1117 acknowledgement mechanism that can provide hints of forward progress. 1118 When data packets are flowing, the VET node can periodically set the 1119 A bit in data packets to elicit Neighbor Advertisement (NA) messages 1120 from the neighbor. When no data packets are flowing, the VET node 1121 can send periodic Neighbor Solicitation (NS) messages for the same 1122 purpose. 1124 Responsiveness to routing changes is directly related to the delay in 1125 detecting that a neighbor has gone unreachable. In order to provide 1126 responsiveness comparable to dynamic routing protocols, a reasonably 1127 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1129 Additionally, a VET node may receive outer IP ICMP "Destination 1130 Unreachable; net / host unreachable" messages from an ER on the path 1131 indicating that the path to a VET neighbor may be failing. The node 1132 SHOULD first check the packet-in-error to obtain reasonable assurance 1133 that the ICMP message is authentic. If the node receives excessive 1134 ICMP unreachable errors through multiple RLOCs associated with the 1135 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1136 packets to flow through a different route. 1138 5.7.3. Redirect Function 1140 A VET node (i.e., the redirectee) may receive a redirect message when 1141 it forwards packets over a VET interface to a neighboring VET node 1142 (i.e., the redirector). The redirector will forward the packet and 1143 return an SCMP Redirect message if necessary to inform the redirectee 1144 of a better next hop. Unlike ordinary ICMP redirects, the redirector 1145 sends an SCMP Redirect message (subject to rate limiting) whenever it 1146 receives a packet with R=1 in the SEAL header for which there is a 1147 better next hop on the same VET interface that it arrived on 1148 regardless of whether the inner source address of the packet was on- 1149 link. The redirector also discards packets with D=1 in the SEAL 1150 header after sending a redirect (if necessary) and before forwarding 1151 the packet to the next hop. 1153 The SCMP Redirect message is formatted the same as for ordinary 1154 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1155 the Destination and Target Address fields are unnecessary and 1156 therefore omitted. The format of the SCMP Redirect message is shown 1157 in Figure 2 1158 0 1 2 3 1159 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 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Type = 137 | Code = 0 | Checksum | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Reserved | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Options ... 1166 +-+-+-+-+-+-+-+-+-+-+-+- 1168 Figure 2: SCMP Redirect Message Format 1170 The redirector then adds any necessary Options to the Redirect 1171 message. It first includes one or more Target Link-Layer Address 1172 Options (TLLAOs) (see: Section 4.6.1 of [RFC4861]) that include RLOCs 1173 corresponding to better next hops. The TLLAO formats for IPv4 and 1174 IPv6 RLOCs are shown in Figure 3 and Figure 4: 1176 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Type = 2 | Length = 1 | Reserved | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | IPv4 address (bytes 0 thru 3) | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 Figure 3: SCMP TLLAO Option for IPv4 RLOCs 1186 0 1 2 3 1187 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 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Type = 2 | Length = 3 | Reserved | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Reserved | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | IPv6 address (bytes 0 thru 3) | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | IPv6 address (bytes 4 thru 7) | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | IPv6 address (bytes 8 thru 11) | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | IPv6 address (bytes 12 thru 15) | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 Figure 4: SCMP TLLAO Option for IPv6 RLOCs 1204 The redirector next includes a Route Information Option (RIO) (see: 1205 [RFC4191]) that contains a prefix from its FIB that covers the 1206 destination address of the original packet. SCMP uses a modified 1207 version of the RIO option formatted as shown in Figure 5: 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Type = 24 | Length | Prefix Length | AF |Prf|E|RSV| 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Route Lifetime | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Prefix (Variable Length) | 1217 . . 1218 . . 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 Figure 5: SCMP Route Information Option Format 1223 In this modified format, the redirector prepares the Route Lifetime 1224 and Prefix fields in the RIO option the same as specified in 1225 [RFC4191]. It then sets the fields in the header as follows: 1227 o the 'Type', 'Length' and 'Prf' fields are set the same as 1228 specified in [RFC4191]. 1230 o the 'RSV' field is set to 0. 1232 o he 'Length' field is set to 1, 2, or 3 as specified in [RFC4191], 1233 or set to 4 if the 'Prefix Length' is greater than 128 in order to 1234 accommodate prefixes of non-IP protocols of up to 192 bits in 1235 length. 1237 o the 'Prefix Length' field ranges from 0 to 192. The 'Prefix' 1238 field is 0, 8, 16 or 24 octets depending on the length, and the 1239 embedded prefix MAY be up to 192 bits in length. 1241 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1242 that indicates the embedded prefix protocol type. This document 1243 defines the following values for AF: 1245 * 000 - IPv4 1247 * 001 - IPv6 1249 * 010 - OSI/CLNP NSAP 1251 o the 'E' bit is set to 1 if this prefix is assigned to an End User 1252 Network, and set to 0 otherwise. 1254 Following the RIO option, the redirector includes any other necessary 1255 options (e.g., SEND options) followed by a Redirected Header 1256 containing the leading portion of the packet that triggered the 1257 redirect as the final option in the message. The redirector then 1258 encapsulates the Redirect message the same as for any other SCMP 1259 message and sends it to the redirectee. 1261 When the redirectee receives the Redirect, it first authenticates the 1262 message (i.e., by checking the SEAL_ID in the Redirected Header, by 1263 examining SEND options, etc.) then uses the EID prefix in the RIO 1264 with its respective lifetime to update its FIB. The redirectee also 1265 caches the IPv4 or IPv6 addresses in TLLAOs as the layer 2 addresses 1266 of potential next-hops. 1268 The redirectee retains the FIB entry created as a result of receipt 1269 of an SCMP Redirect until the route lifetime expires, or until the 1270 redirected target neighbor becomes unreachable. In this way, RLOC 1271 liveness detection parallels IPv6 Neighbor Unreachability Detection 1272 as discussed in the next section. 1274 5.7.4. Mobility 1276 When a VET node moves to a new network point of attachment resulting 1277 in the change of an old RLOC to a new RLOC, it informs any 1278 correspondents of the change by sending specially-crafted SCMP 1279 Neighbor Advertisement (NA) messages. The VET node can ensure 1280 reliable delivery of the NA messages by setting the 'A' bit in the 1281 SEAL header in order to receive an explicit acknowledgement. The VET 1282 node SHOULD retry up to three times to get an explicit 1283 acknowledgement before abandoning the attempt. 1285 The NA messages use the new RLOC as the outer IP source address and 1286 include the old RLOC in a Source Link Layer Address Option (SLLAO) 1287 formatted exactly as specified for TLLAOs in Section 5.7.3. When the 1288 neighbor receives the NA, it authenticates the message then replaces 1289 the old RLOC address with the new RLOC address. Methods for 1290 authenticating the NA are out of scope for this document. 1292 5.8. Neighbor Coordination on VET Interfaces using IPsec 1294 VET interfaces that use IPsec encapsulation use the Internet Key 1295 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1296 association setup and maintenance. The IKEv2 can be seen as a 1297 logical equivalent of the SEAL SCMP in terms of VET interface 1298 neighbor coordinations. In particular, IKEv2 also provides 1299 mechanisms for redirection [RFC5685] and mobility [RFC4555]. 1301 IPsec additionally provides an extended Identification field and 1302 integrity check vector; these features allow IPsec to utilize outer 1303 IP fragmentation and reassembly with less risk of exposure to data 1304 corruption due to reassembly misassociations. On the other hand, 1305 IPsec entails the use of symmetric security associations and hence 1306 may not be appropriate to all enterprise network use cases. 1308 5.9. Multicast 1310 In multicast-capable deployments, ERs provide an enterprise-wide 1311 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1312 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1313 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1314 over their enterprise-interior interfaces such that outer IP 1315 multicast messages of site-scope or greater scope will be propagated 1316 across the enterprise network. For such deployments, VET nodes can 1317 also provide an inner multicast/broadcast capability over their VET 1318 interfaces through mapping of the inner multicast address space to 1319 the outer multicast address space. In that case, operation of link- 1320 scoped (or greater scoped) inner multicasting services (e.g., a link- 1321 scoped neighbor discovery protocol) over the VET interface is 1322 available, but should be used sparingly to minimize enterprise-wide 1323 flooding. 1325 VET nodes encapsulate inner multicast messages sent over the VET 1326 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1327 followed by an outer IP header with a site-scoped outer IP multicast 1328 address as the destination. For the case of IPv6 and IPv4 as the 1329 inner/outer protocols (respectively), [RFC2529] provides mappings 1330 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1331 address space (for other encapsulations, mappings are established 1332 through administrative configuration or through an unspecified 1333 alternate static mapping). 1335 Multicast mapping for inner multicast groups over outer IP multicast 1336 groups can be accommodated, e.g., through VET interface snooping of 1337 inner multicast group membership and routing protocol control 1338 messages. To support inner-to-outer multicast address mapping, the 1339 VET interface acts as a virtual outer IP multicast host connected to 1340 its underlying interfaces. When the VET interface detects that an 1341 inner multicast group joins or leaves, it forwards corresponding 1342 outer IP multicast group membership reports on an underlying 1343 interface over which the VET interface is configured. If the VET 1344 node is configured as an outer IP multicast router on the underlying 1345 interfaces, the VET interface forwards locally looped-back group 1346 membership reports to the outer IP multicast routing process. If the 1347 VET node is configured as a simple outer IP multicast host, the VET 1348 interface instead forwards actual group membership reports (e.g., 1349 IGMP messages) directly over an underlying interface. 1351 Since inner multicast groups are mapped to site-scoped outer IP 1352 multicast groups, the VET node MUST ensure that the site-scope outer 1353 IP multicast messages received on the underlying interfaces for one 1354 VET interface do not "leak out" to the underlying interfaces of 1355 another VET interface. This is accommodated through normal site- 1356 scoped outer IP multicast group filtering at enterprise network 1357 boundaries. 1359 5.10. Service Discovery 1361 VET nodes can perform enterprise-wide service discovery using a 1362 suitable name-to-address resolution service. Examples of flooding- 1363 based services include the use of LLMNR [RFC4795] over the VET 1364 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1365 over an underlying interface. More scalable and efficient service 1366 discovery mechanisms are for further study. 1368 5.11. Enterprise Network Partitioning 1370 An enterprise network can be partitioned into multiple distinct 1371 logical groupings. In that case, each partition configures its own 1372 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1373 'isatapv2.zone2.example.com', etc.). 1375 EBGs can further create multiple IP subnets within a partition by 1376 sending RAs with PIOs containing different IPv6 prefixes to different 1377 groups of nodes. EBGs can identify subnets, e.g., by examining RLOC 1378 prefixes, observing the enterprise interior interfaces over which RSs 1379 are received, etc. 1381 5.12. EBG Prefix State Recovery 1383 EBGs retain explicit state that tracks the inner PA prefixes 1384 delegated to EBRs within the enterprise network, e.g., so that 1385 packets are delivered to the correct EBRs. When an EBG loses some or 1386 all of its state (e.g., due to a power failure), it must recover the 1387 state so that packets can be forwarded over correct routes. 1389 5.13. Support for Legacy ISATAP Services 1391 EBGs support legacy ISATAP services according to the specifications 1392 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1393 interfaces and VET interfaces over the same sets of underlying 1394 interfaces as long as the PRLs and IPv6 prefixes associated with the 1395 ISATAP/VET interfaces are distinct. 1397 6. IANA Considerations 1399 There are no IANA considerations for this document. 1401 7. Security Considerations 1403 Security considerations for MANETs are found in [RFC2501]. 1405 The security considerations found in 1406 [RFC2529][RFC5214][I-D.nakibly-v6ops-tunnel-loops] also apply to VET. 1408 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1409 where attacks on the neighbor coordination protocol are possible. 1410 SEAL [I-D.templin-intarea-seal] provides a per-packet identification 1411 that can be used to detect source address spoofing. 1413 Rogue neighbor coordination messages with spoofed RLOC source 1414 addresses can consume network resources and cause VET nodes to 1415 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1416 such RLOCs, as that may result in a denial of service to the RLOCs' 1417 legitimate owners. 1419 VET EBRs and EBGs observe the recommendations for network ingress 1420 filtering [RFC2827]. 1422 8. Related Work 1424 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1425 automatic tunneling in [RFC2529]; this concept was later called: 1426 "Virtual Ethernet" and investigated by Quang Nguyen under the 1427 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1428 their colleagues have motivated a number of foundational concepts on 1429 which this work is based. 1431 Telcordia has proposed DHCP-related solutions for MANETs through the 1432 CECOM MOSAIC program. 1434 The Naval Research Lab (NRL) Information Technology Division uses 1435 DHCP in their MANET research testbeds. 1437 Security concerns pertaining to tunneling mechanisms are discussed in 1438 [I-D.ietf-v6ops-tunnel-security-concerns]. 1440 Default router and prefix information options for DHCPv6 are 1441 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1443 An automated IPv4 prefix delegation mechanism is proposed in 1444 [I-D.ietf-dhc-subnet-alloc]. 1446 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1447 [I-D.clausen-manet-autoconf-recommendations]. 1449 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1451 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1452 decapsulation issues and other aspects of tunneling. 1454 Various proposals within the IETF have suggested similar mechanisms. 1456 9. Acknowledgements 1458 The following individuals gave direct and/or indirect input that was 1459 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1460 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1461 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1462 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1463 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1464 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1465 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1466 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1467 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1468 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1469 working groups. Many others have provided guidance over the course 1470 of many years. 1472 10. Contributors 1474 The following individuals have contributed to this document: 1476 Eric Fleischman (eric.fleischman@boeing.com) 1477 Thomas Henderson (thomas.r.henderson@boeing.com) 1478 Steven Russert (steven.w.russert@boeing.com) 1479 Seung Yi (seung.yi@boeing.com) 1481 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1482 of the document. 1484 Jim Bound's foundational work on enterprise networks provided 1485 significant guidance for this effort. We mourn his loss and honor 1486 his contributions. 1488 11. References 1490 11.1. Normative References 1492 [I-D.templin-intarea-seal] 1493 Templin, F., "The Subnetwork Encapsulation and Adaptation 1494 Layer (SEAL)", draft-templin-intarea-seal-14 (work in 1495 progress), June 2010. 1497 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1498 September 1981. 1500 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1501 RFC 792, September 1981. 1503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1504 Requirement Levels", BCP 14, RFC 2119, March 1997. 1506 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1507 RFC 2131, March 1997. 1509 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1510 (IPv6) Specification", RFC 2460, December 1998. 1512 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1513 Defeating Denial of Service Attacks which employ IP Source 1514 Address Spoofing", BCP 38, RFC 2827, May 2000. 1516 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1517 and M. Carney, "Dynamic Host Configuration Protocol for 1518 IPv6 (DHCPv6)", RFC 3315, July 2003. 1520 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1521 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1522 December 2003. 1524 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1525 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1527 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1528 RFC 3972, March 2005. 1530 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1531 More-Specific Routes", RFC 4191, November 2005. 1533 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1534 Architecture", RFC 4291, February 2006. 1536 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1537 Message Protocol (ICMPv6) for the Internet Protocol 1538 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1540 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1541 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1542 September 2007. 1544 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1545 Address Autoconfiguration", RFC 4862, September 2007. 1547 [RFC5342] Eastlake. , D., "IANA Considerations and IETF Protocol 1548 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, 1549 September 2008. 1551 11.2. Informative References 1553 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1554 Switching Networks", May 1974. 1556 [I-D.carpenter-flow-ecmp] 1557 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1558 for equal cost multipath routing and link aggregation in 1559 tunnels", draft-carpenter-flow-ecmp-02 (work in progress), 1560 April 2010. 1562 [I-D.cheshire-dnsext-multicastdns] 1563 Cheshire, S. and M. Krochmal, "Multicast DNS", 1564 draft-cheshire-dnsext-multicastdns-11 (work in progress), 1565 March 2010. 1567 [I-D.clausen-manet-autoconf-recommendations] 1568 Clausen, T. and U. Herberg, "MANET Router Configuration 1569 Recommendations", 1570 draft-clausen-manet-autoconf-recommendations-00 (work in 1571 progress), February 2009. 1573 [I-D.clausen-manet-linktype] 1574 Clausen, T., "The MANET Link Type", 1575 draft-clausen-manet-linktype-00 (work in progress), 1576 October 2008. 1578 [I-D.droms-dhc-dhcpv6-default-router] 1579 Droms, R. and T. Narten, "Default Router and Prefix 1580 Advertisement Options for DHCPv6", 1581 draft-droms-dhc-dhcpv6-default-router-00 (work in 1582 progress), March 2009. 1584 [I-D.ietf-dhc-subnet-alloc] 1585 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1586 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1587 (work in progress), May 2010. 1589 [I-D.ietf-grow-va] 1590 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1591 L. Zhang, "FIB Suppression with Virtual Aggregation", 1592 draft-ietf-grow-va-02 (work in progress), March 2010. 1594 [I-D.ietf-lisp] 1595 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1596 "Locator/ID Separation Protocol (LISP)", 1597 draft-ietf-lisp-07 (work in progress), April 2010. 1599 [I-D.ietf-manet-smf] 1600 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1601 draft-ietf-manet-smf-10 (work in progress), March 2010. 1603 [I-D.ietf-softwire-ipv6-6rd] 1604 Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 1605 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 1606 (work in progress), May 2010. 1608 [I-D.ietf-v6ops-tunnel-security-concerns] 1609 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1610 Concerns With IP Tunneling", 1611 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 1612 progress), March 2010. 1614 [I-D.jen-apt] 1615 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1616 L. Zhang, "APT: A Practical Transit Mapping Service", 1617 draft-jen-apt-01 (work in progress), November 2007. 1619 [I-D.nakibly-v6ops-tunnel-loops] 1620 Nakibly, G. and F. Templin, "Routing Loop Attack using 1621 IPv6 Automatic Tunnels: Problem Statement and Proposed 1622 Mitigations", draft-nakibly-v6ops-tunnel-loops-02 (work in 1623 progress), May 2010. 1625 [I-D.russert-rangers] 1626 Russert, S., Fleischman, E., and F. Templin, "Operational 1627 Scenarios for IRON and RANGER", draft-russert-rangers-03 1628 (work in progress), June 2010. 1630 [I-D.templin-iron] 1631 Templin, F., "The Internet Routing Overlay Network 1632 (IRON)", draft-templin-iron-02 (work in progress), 1633 June 2010. 1635 [I-D.templin-isatap-dhcp] 1636 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1637 Option for the Intra-Site Automatic Tunnel Addressing 1638 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1639 progress), December 2009. 1641 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1642 July 1978. 1644 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1645 Protocol Specification", October 2008. 1647 [RFC0994] International Organization for Standardization (ISO) and 1648 American National Standards Institute (ANSI), "Final text 1649 of DIS 8473, Protocol for Providing the Connectionless- 1650 mode Network Service", RFC 994, March 1986. 1652 [RFC1035] Mockapetris, P., "Domain names - implementation and 1653 specification", STD 13, RFC 1035, November 1987. 1655 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1656 a subnetwork for experimentation with the OSI network 1657 layer", RFC 1070, February 1989. 1659 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1660 Communication Layers", STD 3, RFC 1122, October 1989. 1662 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1663 Routing and Addressing Architecture", RFC 1753, 1664 December 1994. 1666 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1667 E. Lear, "Address Allocation for Private Internets", 1668 BCP 5, RFC 1918, February 1996. 1670 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1671 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1673 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1674 October 1996. 1676 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1677 Extensions", RFC 2132, March 1997. 1679 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1680 IPv6 Specification", RFC 2473, December 1998. 1682 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1683 over Non-Broadcast Multiple Access (NBMA) networks", 1684 RFC 2491, January 1999. 1686 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1687 (MANET): Routing Protocol Performance Issues and 1688 Evaluation Considerations", RFC 2501, January 1999. 1690 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1691 Domains without Explicit Tunnels", RFC 2529, March 1999. 1693 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1694 February 2000. 1696 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1697 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1698 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1699 RFC 3819, July 2004. 1701 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1702 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1703 May 2005. 1705 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1706 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1707 January 2005. 1709 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1710 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1711 RFC 3948, January 2005. 1713 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1714 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1715 September 2005. 1717 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1718 Addresses", RFC 4193, October 2005. 1720 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1721 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1723 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1724 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1726 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1727 Internet Protocol", RFC 4301, December 2005. 1729 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1730 RFC 4306, December 2005. 1732 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1733 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1734 May 2006. 1736 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1737 (MOBIKE)", RFC 4555, June 2006. 1739 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1740 Multicast Name Resolution (LLMNR)", RFC 4795, 1741 January 2007. 1743 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1745 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1746 Focus", RFC 4852, April 2007. 1748 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1749 June 2007. 1751 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1752 Extensions for Stateless Address Autoconfiguration in 1753 IPv6", RFC 4941, September 2007. 1755 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1756 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1757 March 2008. 1759 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1760 for IPv6", RFC 5340, July 2008. 1762 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1763 Infrastructures (6rd)", RFC 5569, January 2010. 1765 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1766 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1767 RFC 5685, November 2009. 1769 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1770 Global Enterprise Recursion (RANGER)", RFC 5720, 1771 February 2010. 1773 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1774 Still Needs Work", RFC 5887, May 2010. 1776 Appendix A. Duplicate Address Detection (DAD) Considerations 1778 A priori uniqueness determination (also known as "pre-service DAD") 1779 for an RLOC assigned on an enterprise-interior interface would 1780 require either flooding the entire enterprise network or somehow 1781 discovering a link in the network on which a node that configures a 1782 duplicate address is attached and performing a localized DAD exchange 1783 on that link. But, the control message overhead for such an 1784 enterprise-wide DAD would be substantial and prone to false-negatives 1785 due to packet loss and intermittent connectivity. An alternative to 1786 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1787 enterprise-interior interfaces and employ a passive in-service DAD 1788 (e.g., one that monitors routing protocol messages for duplicate 1789 assignments). 1791 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1792 CGAs, IPv6 privacy addresses, etc. with very small probability of 1793 collision. Pseudo-random IPv4 RLOCs can be generated through random 1794 assignment from a suitably large IPv4 prefix space. 1796 Consistent operational practices can assure uniqueness for EBG- 1797 aggregated addresses/prefixes, while statistical properties for 1798 pseudo-random address self-generation can assure uniqueness for the 1799 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1800 RLOC delegation authority should be used when available, while a 1801 passive in-service DAD mechanism should be used to detect RLOC 1802 duplications when there is no RLOC delegation authority. 1804 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1806 For each distinct enterprise network that it connects to, an EBR 1807 configures a VET interface over possibly multiple underlying 1808 interfaces that all connect to the same network. The VET interface 1809 therefore represents the EBR's logical point of attachment to the 1810 enterprise network, and provides a logical interface for link-layer 1811 multiplexing over its underlying interfaces as described in Section 1812 3.3.4 of [RFC1122]: 1814 "Finally, we note another possibility that is NOT multihoming: one 1815 logical interface may be bound to multiple physical interfaces, in 1816 order to increase the reliability or throughput between directly 1817 connected machines by providing alternative physical paths between 1818 them. For instance, two systems might be connected by multiple 1819 point-to-point links. We call this "link-layer multiplexing". 1820 With link-layer multiplexing, the protocols above the link layer 1821 are unaware that multiple physical interfaces are present; the 1822 link-layer device driver is responsible for multiplexing and 1823 routing packets across the physical interfaces." 1825 EBRs can support such a link-layer multiplexing capability across the 1826 enterprise network in accordance with the Weak End System Model (see 1827 Section 3.3.4 of [RFC1122]). In particular, when an EBR 1828 autoconfigures an RLOC address, it can associate it with the VET 1829 interface only instead of assigning it to an underlying interface. 1830 The EBR therefore only needs to obtain a single RLOC address even if 1831 there are multiple underlying interfaces, i.e., it does not need to 1832 obtain one for each underlying interface. The EBR can then leave the 1833 underlying interfaces unnumbered, or it can configure a randomly 1834 chosen IP link-local address (e.g., from the prefix 169.254/16 1835 [RFC3927] for IPv4) on underlying interfaces that require a 1836 configuration. The EBR need not check these link-local addresses for 1837 uniqueness within the enterprise network, as they will not normally 1838 be used as the source address for packets. 1840 When the EBR engages in the enterprise-interior routing protocol, it 1841 uses the RLOC address assigned to the VET interface as the source 1842 address for all routing protocol control messages, however it must 1843 also supply an interface identifier (e.g., a small integer) that 1844 uniquely identifies the underlying interface that the control message 1845 is sent over. For example, if the underlying interfaces are known as 1846 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1847 sends a routing protocol control message over the "eth7" interface. 1848 This is necessary to ensure that other routers can determine the 1849 specific interface over which the EBR's routing protocol control 1850 message was sent, but the token need only be unique within the EBR 1851 itself and need not be unique throughout the enterprise network. 1853 When the EBR discovers an RLOC route via the enterprise interior 1854 routing protocol, it configures a preferred route in the IP FIB that 1855 points to the VET interface instead of the underlying interface. At 1856 the same time, the EBR also configures an ancillary route that points 1857 to the underlying interface. If the EBR discovers that the same RLOC 1858 route is reachable via multiple underlying interfaces, it configures 1859 multiple ancillary routes (i.e., one for each interface). If the EBR 1860 discovers that the RLOC route is no longer reachable via any 1861 underlying interface, it removes the route in the IP FIB that points 1862 to the VET interface. 1864 With these arrangements, all locally-generated packets with RLOC 1865 destinations will flow through the VET interface (and thereby use the 1866 VET interface's RLOC address as the source address) instead of 1867 through the underlying interfaces. In the same fashion, all 1868 forwarded packets with RLOC destinations will flow through the VET 1869 interface instead of through the underlying interfaces. 1871 This arrangement has several operational advantages that enable a 1872 number of traffic engineering capabilities. First, the VET interface 1873 can insert the SEAL header so that ID-based duplicate packet 1874 detection is enabled within the enterprise network. Secondly, SEAL 1875 can dynamically adjust its packet sizing parameters so that an 1876 optimum Maximum Transmission Unit (MTU) can be determined. This is 1877 true even if the VET interface reroutes traffic between underlying 1878 interfaces with different MTUs. 1880 Most importantly, the EBR can configure default and more-specific 1881 routes on the VET interface to direct traffic through a specific 1882 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1883 will ensure that a specific eEBR is chosen, and the best eEBR can be 1884 chosen when multiple are available. Also, local applications see a 1885 stable IP source address even if there are multiple underlying 1886 interfaces. This link-layer multiplexing can therefore provide 1887 continuous operation across failovers between multiple links attached 1888 to the same enterprise network without any need for readdressing. 1889 Finally, the VET interface can forward packets with RLOC-based 1890 destinations over an underlying interface without any encapsulation 1891 if encapsulation avoidance is desired. 1893 It must be specifically noted that the above arrangement constitutes 1894 a case in which the same RLOC may be used as both the inner and outer 1895 IP source address. This will not present a problem as long as both 1896 ends configure a VET interface in the same fashion. 1898 It must also be noted that EID-based communications can use the same 1899 VET interface arrangement, except that the EID-based next hop must be 1900 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1901 within IPvX encapsulation, as well as for IPv4 within IPv6 1902 encapsulation, this requires a VET interface specific address mapping 1903 database. For IPv6 within IPv4 encapsulation, the mapping is 1904 accomplished through simple static extraction of an IPv4 address 1905 embedded within the IPv6 address. 1907 Appendix C. Anycast Services 1909 Some of the IPv4 addresses that appear in the Potential Router List 1910 may be anycast addresses, i.e., they may be configured on the VET 1911 interfaces of multiple EBRs/EBGs. In that case, each VET router 1912 interface that configures the same anycast address must provide 1913 equivalent packet forwarding and neighbor discovery services. 1915 Use of an anycast address as the IP destination address of tunneled 1916 packets can have subtle interactions with tunnel path MTU and 1917 neighbor discovery. For example, if the initial fragments of a 1918 fragmented tunneled packet with an anycast IP destination address are 1919 routed to different egress tunnel endpoints than the remaining 1920 fragments, the multiple endpoints will be left with incomplete 1921 reassembly buffers. This issue can be mitigated by ensuring that 1922 each egress tunnel endpoint implements a proactive reassembly buffer 1923 garbage collection strategy. Additionally, ingress tunnel endpoints 1924 that send packets with an anycast IP destination address must use the 1925 minimum path MTU for all egress tunnel endpoints that configure the 1926 same anycast address as the tunnel MTU. Finally, ingress tunnel 1927 endpoints should treat ICMP unreachable messages from a router within 1928 the tunnel as at most a weak indication of neighbor unreachability, 1929 since the failures may only be transient and a different path to an 1930 alternate anycast router quickly selected through reconvergence of 1931 the underlying routing protocol. 1933 Use of an anycast address as the IP source address of tunneled 1934 packets can lead to more serious issues. For example, when the IP 1935 source address of a tunneled packet is anycast, ICMP messages 1936 produced by routers within the tunnel might be delivered to different 1937 ingress tunnel endpoints than the ones that produced the packets. In 1938 that case, functions such as path MTU discovery and neighbor 1939 unreachability detection may experience non-deterministic behavior 1940 that can lead to communications failures. Additionally, the 1941 fragments of multiple tunneled packets produced by multiple ingress 1942 tunnel endpoints may be delivered to the same reassembly buffer at a 1943 single egress tunnel endpoint. In that case, data corruption may 1944 result due to fragment misassociation during reassembly. 1946 In view of these considerations, EBRs/EBGs that configure an anycast 1947 address should also configure one or more unicast addresses from the 1948 Potential Router List; they should further accept tunneled packets 1949 destined to any of their anycast or unicast addresses, but should 1950 send tunneled packets using a unicast address as the source address. 1951 In order to influence traffic to use an anycast route (and thereby 1952 leverage the natural fault tolerance afforded by anycast), ISATAP 1953 routers should set higher preferences on the default routes they 1954 advertise using an anycast address as the source and set lower 1955 preferences on the default routes they advertise using a unicast 1956 address as the source (see: [RFC4191]). 1958 Appendix D. Change Log 1960 (Note to RFC editor - this section to be removed before publication 1961 as an RFC.) 1963 Changes from -13 to -14: 1965 o fixed Idnits 1967 Changes from -12 to -13: 1969 o Changed "VGL" *back* to "PRL" 1971 o More changes for multi-protocol support 1973 o Changes to Redirect function 1975 Changes from -11 to -12: 1977 o Major section rearrangement 1979 o Changed "PRL" to "VGL" 1980 o Brought back text that was lost in the -10 to -11 transition 1982 Changes from -10 to -11: 1984 o Major changes with significant simplifications 1986 o Now support stateless PD using 6rd mechanisms 1988 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 1990 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 1992 Changes from -09 to -10: 1994 o Changed "enterprise" to "enterprise network" throughout 1996 o dropped "inner IP", since inner layer may be non-IP 1998 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 1999 messages remain *within* the tunnel interface instead of being 2000 exposed to the inner network layer protocol engine. 2002 Changes from -08 to -09: 2004 o Expanded discussion of encapsulation/decapsulation procedures 2006 o cited IRON 2008 Changes from -07 to -08: 2010 o Specified the approach to global mapping using virtual aggregation 2011 and BGP 2013 Changes from -06 to -07: 2015 o reworked redirect function 2017 o created new section on VET interface encapsulation 2019 o clarifications on nexthop selection 2021 o fixed several bugs 2023 Changed from -05 to -06: 2025 o reworked VET interface ND 2026 o anycast clarifications 2028 Changes from -03 to -04: 2030 o security consideration clarifications 2032 Changes from -02 to -03: 2034 o security consideration clarifications 2036 o new PRLNAME for VET is "isatav2.example.com" 2038 o VET now uses SEAL natively 2040 o EBGs can support both legacy ISATAP and VET over the same 2041 underlying interfaces. 2043 Changes from -01 to -02: 2045 o Defined CGA and privacy address configuration on VET interfaces 2047 o Interface identifiers added to routing protocol control messages 2048 for link-layer multiplexing 2050 Changes from -00 to -01: 2052 o Section 4.1 clarifications on link-local assignment and RLOC 2053 autoconfiguration. 2055 o Appendix B clarifications on Weak End System Model 2057 Changes from RFC5558 to -00: 2059 o New appendix on RLOC configuration on VET interfaces. 2061 Author's Address 2063 Fred L. Templin (editor) 2064 Boeing Research & Technology 2065 P.O. Box 3707 MC 7L-49 2066 Seattle, WA 98124 2067 USA 2069 Email: fltemplin@acm.org