idnits 2.17.1 draft-templin-intarea-vet-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 1, 2010) is 4896 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-24 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-12 == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-02 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-11 == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-03 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-10 == Outdated reference: A later version (-17) exists of draft-templin-iron-13 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Standards Track December 1, 2010 5 Expires: June 4, 2011 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-17.txt 10 Abstract 12 Enterprise networks connect hosts and routers over various link 13 types, and often also connect to provider networks and/or the global 14 Internet. Enterprise network nodes require a means to automatically 15 provision addresses/prefixes and support internetworking operation in 16 a wide variety of use cases including Small Office, Home Office 17 (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, 18 multi-organizational corporate networks and the interdomain core of 19 the global Internet itself. This document specifies a Virtual 20 Enterprise Traversal (VET) abstraction for autoconfiguration and 21 operation of nodes in enterprise networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 4, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Enterprise Network Characteristics . . . . . . . . . . . . . . 11 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 61 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 13 62 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 14 63 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 15 64 4.2.2. Provider-Aggregated (PA) EID Prefix 65 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 66 4.2.3. Provider-(In)dependent (PI) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 68 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 18 69 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 19 70 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 19 71 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 19 72 5.1.1. PI Prefix Routing Considerations . . . . . . . . . . . 20 73 5.2. Default Route Configuration and Selection . . . . . . . . 20 74 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 21 75 5.4. Next Hop Determination . . . . . . . . . . . . . . . . . . 21 76 5.5. VET Interface Encapsulation/Decapsulation . . . . . . . . 22 77 5.5.1. Inner Network Layer Protocol . . . . . . . . . . . . . 22 78 5.5.2. Mid-Layer Encapsulation . . . . . . . . . . . . . . . 23 79 5.5.3. SEAL Encapsulation . . . . . . . . . . . . . . . . . . 23 80 5.5.4. Outer UDP Header Encapsulation . . . . . . . . . . . . 23 81 5.5.5. Outer IP Header Encapsulation . . . . . . . . . . . . 24 82 5.5.6. Decapsulation . . . . . . . . . . . . . . . . . . . . 24 83 5.6. Mobility and Multihoming Considerations . . . . . . . . . 25 84 5.7. Neighbor Coordination on VET Interfaces using SEAL . . . . 25 85 5.7.1. Router Discovery . . . . . . . . . . . . . . . . . . . 25 86 5.7.2. Neighbor Unreachability Detection . . . . . . . . . . 26 87 5.7.3. Redirect Function . . . . . . . . . . . . . . . . . . 26 88 5.7.4. Mobility . . . . . . . . . . . . . . . . . . . . . . . 29 89 5.8. Neighbor Coordination on VET Interfaces using IPsec . . . 29 90 5.9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 30 91 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 92 5.11. Enterprise Network Partitioning . . . . . . . . . . . . . 31 93 5.12. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 31 94 5.13. Support for Legacy ISATAP Services . . . . . . . . . . . . 31 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 97 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 32 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 103 Appendix A. Duplicate Address Detection (DAD) Considerations . . 40 104 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 40 105 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 42 106 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 43 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 109 1. Introduction 111 Enterprise networks [RFC4852] connect hosts and routers over various 112 link types (see [RFC4861], Section 2.2). The term "enterprise 113 network" in this context extends to a wide variety of use cases and 114 deployment scenarios. For example, an "enterprise" can be as small 115 as a SOHO network, as complex as a multi-organizational corporation, 116 or as large as the global Internet itself. Internet Service Provider 117 (ISP) networks are another example use case that fits well with the 118 VET enterprise network model. Mobile Ad hoc Networks (MANETs) 119 [RFC2501] can also be considered as a challenging example of an 120 enterprise network, in that their topologies may change dynamically 121 over time and that they may employ little/no active management by a 122 centralized network administrative authority. These specialized 123 characteristics for MANETs require careful consideration, but the 124 same principles apply 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 (In)dependent (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 additional encapsulations 489 (e.g., SEAL [I-D.templin-intarea-seal]) that include a nonce to 490 detect off-path attacks. 492 Finally, in enterprise networks with a centralized management 493 structure (e.g., a corporate campus network), an overlay routing/ 494 mapping service and a synchronized set of EBGs can provide sufficient 495 infrastructure support for virtual enterprise traversal. In that 496 case, the EBGs can provide a "default mapper" [I-D.jen-apt] service 497 used for short-term packet forwarding until route-optimized paths 498 between neighboring EBRs can be established. In enterprise networks 499 with a distributed management structure (e.g., disconnected MANETs), 500 peer-to-peer coordination between the EBRs themselves may be 501 required. Recognizing that various use cases will entail a continuum 502 between a fully distributed and fully centralized approach, the 503 following sections present the mechanisms of Virtual Enterprise 504 Traversal as they apply to a wide variety of scenarios. 506 4. Autoconfiguration 508 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 509 specified in the following subsections. 511 4.1. Enterprise Router (ER) Autoconfiguration 513 ERs configure enterprise-interior interfaces and engage in any 514 routing protocols over those interfaces. 516 When an ER joins an enterprise network, it first configures an IPv6 517 link-local address on each enterprise-interior interface and 518 configures an IPv4 link-local address on each enterprise-interior 519 interface that requires an IPv4 link-local capability. IPv6 link- 520 local address generation mechanisms include Cryptographically 521 Generated Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses 522 [RFC4941], StateLess Address AutoConfiguration (SLAAC) using EUI-64 523 interface identifiers [RFC4291] [RFC4862], etc. The mechanisms 524 specified in [RFC3927] provide an IPv4 link-local address generation 525 capability. 527 Next, the ER configures one or more RLOCs and engages in any routing 528 protocols on its enterprise-interior interfaces. The ER can 529 configure RLOCs via explicit management, DHCP autoconfiguration, 530 pseudo-random self-generation from a suitably large address pool, or 531 through an alternate autoconfiguration mechanism. The ER may 532 optionally configure and assign a separate RLOC for each underlying 533 interface, or it may configure only a single RLOC and assign it to a 534 VET interface configured over the underlying interfaces (see Section 535 4.2.1). In the latter case, the ER can use the VET interface for 536 link layer multiplexing and traffic engineering purposes as specified 537 in Appendix B. 539 Alternatively (or in addition), the ER can request RLOC prefix 540 delegations via an automated prefix delegation exchange over an 541 enterprise-interior interface and can assign the prefix(es) on 542 enterprise-edge interfaces. Note that in some cases, the same 543 enterprise-edge interfaces may assign both RLOC and EID addresses if 544 there is a means for source address selection. In other cases (e.g., 545 for separation of security domains), RLOCs and EIDs are assigned on 546 separate sets of enterprise-edge interfaces. 548 Pseudo-random self-generation of IPv6 RLOCs can be from a large 549 public or local-use IPv6 address range (e.g., IPv6 Unique Local 550 Addresses [RFC4193]). Pseudo-random self-generation of IPv4 RLOCs 551 can be from a large public or local-use IPv4 address range (e.g., 552 [RFC1918]). When self-generation is used alone, the ER continuously 553 monitors the RLOCs for uniqueness, e.g., by monitoring the 554 enterprise-interior routing protocol. (Note however that anycast 555 RLOCs MAY be assigned to multiple enterprise interior interfaces; 556 hence, monitoring for uniqueness applies only to RLOCs that are 557 intended as unicast.) 558 DHCP generation of RLOCs uses standard DHCP procedures but may 559 require support from relays within the enterprise network. For 560 DHCPv6, relays that do not already know the RLOC of a server within 561 the enterprise network forward requests to the 'All_DHCP_Servers' 562 site-scoped IPv6 multicast group [RFC3315]. For DHCPv4, relays that 563 do not already know the RLOC of a server within the enterprise 564 network forward requests to the site-scoped IPv4 multicast group 565 address 'All_DHCPv4_Servers', which SHOULD be set to 239.255.2.1 566 unless an alternate multicast group for the site is known. DHCPv4 567 servers that delegate RLOCs SHOULD therefore join the 568 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 569 received for that group. 571 A combined approach using both DHCP and self-generation is also 572 possible when the ER configures both a DHCP client and relay that are 573 connected, e.g., via a pair of back-to-back connected Ethernet 574 interfaces, a tun/tap interface, a loopback interface, inter-process 575 communication, etc. The ER first self-generates an RLOC from a 576 temporary addressing range used only for the bootstrapping purpose of 577 procuring an actual RLOC taken from a preferred addressing range. 578 The ER then engages in the enterprise-interior routing protocol and 579 performs a DHCP client/relay exchange using the temporary RLOC as the 580 address of the relay. When the DHCP server delegates an actual RLOC 581 address/prefix, the ER abandons the temporary RLOC and re-engages in 582 the enterprise-interior routing protocol using an RLOC taken from the 583 delegation. 585 In some enterprise network use cases (e.g., MANETs), assignment of 586 RLOCs on enterprise-interior interfaces as singleton addresses (i.e., 587 as addresses with /32 prefix lengths for IPv4, or as addresses with 588 /128 prefix lengths for IPv6) MAY be necessary to avoid multi-link 589 subnet issues. In other use cases, assignment of an RLOC on a VET 590 interface as specified in Appendix B can provide link layer 591 multiplexing and traffic engineering over multiple underlying 592 interfaces using only a single IP address. 594 4.2. Enterprise Border Router (EBR) Autoconfiguration 596 EBRs are ERs that configure VET interfaces over distinct sets of 597 underlying interfaces belonging to the same enterprise network; an 598 EBR can connect to multiple enterprise networks, in which case it 599 would configure multiple VET interfaces. In addition to the ER 600 autoconfiguration procedures specified in Section 4.1, EBRs perform 601 the following autoconfiguration operations. 603 4.2.1. VET Interface Initialization 605 EBRs configure a VET interface over a set of underlying interfaces 606 belonging to the same enterprise network such that all other nodes on 607 the VET link appear as single-hop neighbors from the standpoint of 608 the inner network layer protocol through the use of encapsulation. 609 If there are multiple inner network layer protocols (e.g., IPv4, 610 IPv6, OSI, etc.) the EBR configures a separate VET interface for each 611 protocol. 613 After the EBR configures a VET interface, it associates one or more 614 RLOCs with the interface to serve as the source addresses for outer 615 IP packets to be sent over underlying interfaces. The EBR then 616 assigns link-local addresses to the interface if necessary. When 617 IPv6 and IPv4 are used as the inner/outer protocols (respectively), 618 the EBR autoconfigures an IPv6 link-local address on the VET 619 interface using a modified EUI-64 interface identifier based on an 620 IPv4 address (see Section 2.2.1 of [RFC5342]). Link-local address 621 configuration for other inner/outer protocol combinations is through 622 administrative configuration, random self-generation (e.g., 623 [RFC4941], etc.) or through an unspecified alternate method. 624 However, link-local address configuration for other inner/outer 625 protocol combinations may not be necessary if a non-link-local 626 address can be configured through other means (e.g., administrative 627 configuration, DHCP, etc.). 629 The EBR next discovers a Potential Router List (PRL) that includes 630 the RLOC addresses of EBGs. The PRL names the VET interface, and is 631 specific to the address family of the inner network layer protocol 632 (e.g., IPv4, IPv6, OSI, etc.). If there are multiple address 633 families, then there will be multiple VET interfaces; each with its 634 own PRL. 636 The PRL can be discovered through information conveyed in the 637 enterprise-interior routing protocol, through a DHCP option 638 [I-D.templin-isatap-dhcp], an unspecified anycast EBG discovery 639 message exchange, etc. In multicast-capable enterprise networks, 640 EBRs can also listen for advertisements on the 'rasadv' [RASADV] 641 multicast group address. 643 Whether or not other information is available, the EBR can resolve an 644 identifying name for the PRL ('PRLNAME') formed as 645 'hostname.domainname', where 'hostname' is an enterprise-specific 646 name string and 'domainname' is an enterprise-specific Domain Name 647 System (DNS) suffix [RFC1035]. The EBR discovers 'PRLNAME' through 648 manual configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 649 protocol advertisements, link-layer information (e.g., an IEEE 802.11 650 Service Set Identifier (SSID)), or through some other means specific 651 to the enterprise network. The EBR can also obtain 'PRLNAME' as part 652 of an arrangement with a private-sector PI prefix vendor (see: 653 Section 4.2.3). 655 In the absence of other information, the EBR sets the 'hostname' 656 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 657 component to an enterprise-specific DNS suffix (e.g., "example.com"). 658 Isolated enterprise networks that do not connect to the outside world 659 may have no enterprise-specific DNS suffix, in which case the 660 'PRLNAME' consists only of the 'hostname' component. (Note that the 661 default hostname "isatapv2" is intentionally distinct from the 662 convention specified in [RFC5214].) 664 After discovering 'PRLNAME', the EBR resolves the name into a list of 665 RLOC addresses through a name service lookup. For centrally managed 666 enterprise networks, the EBR resolves 'PRLNAME' using an enterprise- 667 local name service (e.g., the DNS). For enterprises with no 668 centralized management structure, the EBR resolves 'PRLNAME' using 669 Link-Local Multicast Name Resolution (LLMNR) [RFC4795] over the VET 670 interface. In that case, all EBGs in the PRL respond to the LLMNR 671 query, and the EBR accepts the union of all responses. 673 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 675 EBRs that connect their enterprise networks to a provider network 676 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 677 stateless autoconfiguration mechanisms. The stateful and stateless 678 approaches are discussed in the following subsections. 680 4.2.2.1. Stateful Prefix Delegation 682 For IPv4, EBRs acquire IPv4 PA EID prefixes via an automated IPv4 683 prefix delegation exchange, explicit management, etc. 685 For IPv6, EBRs acquire IPv6 PA EID prefixes via DHCPv6 Prefix 686 Delegation exchanges with an EBG acting as a DHCP relay/server. In 687 particular, the EBR (acting as a requesting router) can use DHCPv6 688 prefix delegation [RFC3633] over the VET interface to obtain prefixes 689 from the server (acting as a delegating router). The EBR obtains 690 prefixes using either a 2-message or 4-message DHCPv6 exchange 691 [RFC3315]. For example, to perform the 2-message exchange, the EBR's 692 DHCPv6 client forwards a Solicit message with an IA_PD option to its 693 DHCPv6 relay, i.e., the EBR acts as a combined client/relay (see 694 Section 4.1). The relay then forwards the message over the VET 695 interface using VET encapsulation (see: Section 5.4) to an EBG which 696 either services the request or relays it further. The forwarded 697 Solicit message will elicit a reply from the server containing prefix 698 delegations. The EBR can also propose a specific prefix to the 699 DHCPv6 server per Section 7 of [RFC3633]. The server will check the 700 proposed prefix for consistency and uniqueness, then return it in the 701 reply to the EBR if it was able to perform the delegation. 703 After the EBR receives IPv4 and/or IPv6 prefix delegations, it can 704 provision the prefixes on enterprise-edge interfaces as well as on 705 other VET interfaces configured over child enterprise networks for 706 which it acts as an EBG. The EBR can also provision the prefixes on 707 enterprise-interior interfaces to service any hosts attached to the 708 link. 710 The prefix delegations remain active as long as the EBR continues to 711 renew them via the delegating EBG before lease lifetimes expire. The 712 lease lifetime also keeps the delegation state active even if 713 communications between the EBR and delegating EBG are disrupted for a 714 period of time (e.g., due to an enterprise network partition, power 715 failure, etc.). Note however that if the EBR abandons or otherwise 716 loses continuity with the prefixes, it may be obliged to perform 717 network-wide renumbering if it subsequently receives a new and 718 different set of prefixes. 720 Stateful prefix delegation for non-IP protocols is out of scope. 722 4.2.2.2. Stateless Prefix Delegation 724 When IPv6 and IPv4 are used as the inner and outer protocols, 725 respectively, a stateless IPv6 PA prefix delegation capability is 726 available using the mechanisms specified in [RFC5569][RFC5969]. EBRs 727 can use these mechanisms to statelessly configure IPv6 PA prefixes 728 that embed one of the EBR's IPv4 RLOCs. 730 Using this stateless prefix delegation, if the IPv4 RLOC changes the 731 IPv6 prefix also changes and the EBR is obliged to renumber any 732 interfaces on which sub-prefixes from the delegated prefix are 733 assigned. This method may therefore be most suitable for enterprise 734 networks in which IPv4 RLOC assignments rarely change, or in 735 enterprise networks in which only services that do not depend on a 736 long-term stable IPv6 prefix (e.g., client-side web browsing) are 737 used. 739 Stateless prefix delegation for other protocol combinations is out of 740 scope. 742 4.2.3. Provider-(In)dependent (PI) EID Prefix Autoconfiguration 744 EBRs can acquire Provider (In)dependent (PI) prefixes to facilitate 745 multihoming, mobility and traffic engineering without requiring site- 746 wide renumbering events. These PI prefixes are made available to 747 EBRs through a prefix registration authority that may or may not be 748 associated with a specific ISP. 750 EBRs that connect major enterprise networks (e.g., large 751 corporations, academic campuses, ISP networks, etc.) to a parent 752 enterprise network and/or the global Internet can acquire highly- 753 aggregated PI prefixes (e.g., an IPv6 ::/20, an IPv4 /16, etc.) 754 through a registration authority such as the Internet Assigned 755 Numbers Authority (IANA) or a major regional Internet registry. EBRs 756 that connect small enterprise networks (e.g., SOHO networks, MANETs, 757 etc.) to a parent enterprise network can acquire de-aggregated PI 758 prefixes through arrangements with a PI prefix commercial vendor 759 organization. 761 After an EBR receives PI prefixes, it can sub-delegate portions of 762 the prefixes on enterprise-edge interfaces, on other VET interfaces 763 for which it is configured as an EBG and on enterprise-interior 764 interfaces to service any hosts attached to the link. The EBR can 765 also sub-delegate portions of its PI prefixes to requesting routers 766 within child enterprise networks. These requesting routers consider 767 their sub-delegated portions of the PI prefix as PA, and consider the 768 delegating routers as their points of connection to a provider 769 network. 771 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 773 EBGs are EBRs that connect child enterprise networks to provider 774 networks via provider-edge interfaces and/or via VET interfaces 775 configured over parent enterprise networks. EBGs autoconfigure their 776 provider-edge interfaces in a manner that is specific to the provider 777 connections, and they autoconfigure their VET interfaces that were 778 configured over parent enterprise networks using the EBR 779 autoconfiguration procedures specified in Section 4.2. 781 For each of its VET interfaces configured over a child enterprise 782 network, the EBG initializes the interface the same as for an 783 ordinary EBR (see Section 4.2.1). It then arranges to add one or 784 more of its RLOCs associated with the child enterprise network to the 785 PRL. In particular, for each VET interface configured over a child 786 enterprise network the EBG adds the RLOCs to name service resource 787 records for 'PRLNAME'. 789 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 790 configured over child enterprise networks with a distributed 791 management structure. EBGs may also engage in an unspecified anycast 792 EBG discovery message exchange if they are configured to do so. 794 EBGs configure a DHCP relay/server on VET interfaces configured over 795 child enterprise networks that require DHCP services. 797 To avoid looping, EBGs MUST NOT configure a default route on a VET 798 interface configured over a child enterprise network interface. 800 4.4. VET Host Autoconfiguration 802 Nodes that cannot be attached via an EBR's enterprise-edge interface 803 (e.g., nomadic laptops that connect to a home office via a Virtual 804 Private Network (VPN)) can instead be configured for operation as a 805 simple host with a VET interface. Such VET hosts perform the same 806 VET interface initialization and EBG discovery procedures as 807 specified for EBRs in Section 4.2.1, but they configure their VET 808 interfaces as host interfaces (and not router interfaces). Note also 809 that a node may be configured as a host on some VET interfaces and as 810 an EBR/EBG on other VET interfaces. 812 A VET host may receive non-link-local addresses and/or prefixes to 813 assign to the VET interface via DHCP exchanges and/or through 814 information conveyed in Router Advertisements (RAs). If prefixes are 815 provided, however, there must be assurance that either 1) the VET 816 link will not partition, or 2) that each VET host interface connected 817 to the VET link will configure a unique set of prefixes. VET hosts 818 therefore depend on DHCP and/or RA exchanges to provide only prefixes 819 that are appropriate according to these specific cases (i.e., shared 820 prefixes vs. individual prefixes), and depend on the EBGs within the 821 enterprise keeping track of which prefixes were assigned to which 822 hosts. 824 5. Internetworking Operation 826 Following the autoconfiguration procedures specified in Section 4, 827 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 828 operations as discussed in the following sections. 830 5.1. Routing Protocol Participation 832 ERs engage in any intra-enterprise routing protocols over enterprise- 833 interior interfaces to exchange routing information for forwarding IP 834 packets with RLOC addresses. EBRs and EBGs can additionally engage 835 in any inter-enterprise routing protocols over VET, enterprise-edge 836 and provider-edge interfaces to exchange routing information for 837 forwarding IP packets with EID addresses. Note that the EID-based 838 inter-enterprise IP routing domains are separate and distinct from 839 any RLOC-based enterprise interior IP routing domains. 841 Routing protocol participation on non-multicast VET interfaces uses 842 the NBMA interface model, e.g., in the same manner as for OSPF over 843 NBMA interfaces [RFC5340], while routing protocol participation on 844 multicast-capable VET interfaces uses the standard multicast 845 interface model. EBRs use the list of EBGs in the PRL (see: 846 Section 4.2.1) as an initial list of neighbors for inter-enterprise 847 routing protocol participation. 849 5.1.1. PI Prefix Routing Considerations 851 EBRs that connect large enterprise networks to the global Internet 852 advertise their EID PI prefixes directly into the Internet default- 853 free RIB via the Border Gateway Protocol (BGP) [RFC4271] the same as 854 for a major service provider network. EBRs that connect large 855 enterprise networks to provider networks can instead advertise their 856 EID PI prefixes into the providers' routing system(s) if the provider 857 networks are configured to accept them. 859 EBRs that connect small enterprise networks to provider networks 860 obtain one or more public IP address(es) (i.e., either EID or RLOC IP 861 address) then dynamically register the mapping of their PI prefixes 862 to the public IP address. The registrations are through secured end- 863 to-end exchanges between the EBR and a server in the PI prefix 864 vendor's network (e.g., through a vendor-specific short http(s) 865 transaction). The PI prefix vendor network then acts as a virtual 866 "home" enterprise network that connects its customer small enterprise 867 networks to the Internet routing system. The customer small 868 enterprise networks in turn appear as mobile components of the PI 869 prefix vendor's network, i.e., the customer networks are always "away 870 from home". 872 Further details on routing for PI prefixes is discussed in "The 873 Internet Routing Overlay Network (IRON)" [I-D.templin-iron] and "Fib 874 Suppression with Virtual Aggregation" [I-D.ietf-grow-va]. 876 5.2. Default Route Configuration and Selection 878 Configuration of default routes in the presence of VET interfaces 879 must be carefully coordinated according to the inner and outer 880 network protocols. If the inner and outer protocols are different 881 (e.g., IPv6 within IPv4) then default routes of the inner protocol 882 version can be configured with next-hops corresponding to default 883 routers on a VET interface while default routes of the outer protocol 884 version can be configured with next-hops corresponding to default 885 routers on an underlying interface. 887 If the inner and outer protocols are the same (e.g., IPv4 within 888 IPv4), care must be taken in setting the default route to avoid 889 ambiguity. For example, if default routes are configured on the VET 890 interface then more-specific routes could be configured on underlying 891 interfaces to avoid looping. In a preferred method, however, 892 multiple default routes can be configured with some having next-hops 893 corresponding to (EID-based) default routers on VET interfaces and 894 others having next-hops corresponding to (RLOC-based) default routers 895 on underlying interfaces. In that case, special next-hop 896 determination rules must be used (see: Section 5.4). 898 5.3. Address Selection 900 When permitted by policy and supported by enterprise interior 901 routing, VET nodes can avoid encapsulation through communications 902 that directly invoke the outer IP protocol using RLOC addresses 903 instead of EID addresses for end-to-end communications. For example, 904 an enterprise network that provides native IPv4 intra-enterprise 905 services can provide continued support for native IPv4 communications 906 even when encapsulated IPv6 services are available for inter- 907 enterprise communications. In other enterprise network scenarios, 908 the use of EID-based communications (i.e., instead of RLOC-based 909 communications) may be necessary and/or beneficial to support address 910 scaling, NAT traversal avoidance, security domain separation, site 911 multihoming, traffic engineering, etc. . 913 VET nodes can use source address selection rules (e.g., based on name 914 service information) to determine whether to use EID-based or RLOC- 915 based addressing. The remainder of this section discusses 916 internetworking operation for EID-based communications using the VET 917 interface abstraction. 919 5.4. Next Hop Determination 921 VET nodes perform normal next-hop determination via longest prefix 922 match, and send packets according to the most-specific matching entry 923 in the FIB. If the FIB entry has multiple next-hop addresses, the 924 EBR selects the next-hop with the best metric value. If multiple 925 next hops have the same metric value, the VET node can use Equal Cost 926 Multi Path (ECMP) to forward different flows via different next-hop 927 addresses, where flows are determined, e.g., by computing a hash of 928 the inner packet's source address, destination address and flow label 929 fields. 931 If the VET node has multiple default routes of the same inner and 932 outer protocol versions, with some corresponding to EID-based default 933 routers and others corresponding to RLOC-based default routers, it 934 must perform source address based selection of a default route. In 935 particular, if the packet's source address is taken from an EID 936 prefix the VET node selects a default route configured over the VET 937 interface; otherwise, it selects a default route configured over an 938 underlying interface. 940 As a last resort when there is no matching entry in the FIB (i.e., 941 not even default), VET nodes can discover next-hop addresses within 942 the enterprise network through on-demand name service queries for the 943 EID prefix taken from a packet's destination address (or, by some 944 other inner address to outer address mapping mechanism). For 945 example, for the IPv6 destination address '2001:DB8:1:2::1' and 946 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 947 service lookup for the domain name: 948 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 950 Name-service lookups in enterprise networks with a centralized 951 management structure use an infrastructure-based service, e.g., an 952 enterprise-local DNS. Name-service lookups in enterprise networks 953 with a distributed management structure and/or that lack an 954 infrastructure-based name service instead use LLMNR over the VET 955 interface. When LLMNR is used, the EBR that performs the lookup 956 sends an LLMNR query (with the prefix taken from the IP destination 957 address encoded in dotted-nibble format as shown above) and accepts 958 the union of all replies it receives from other EBRs on the VET 959 interface. When an EBR receives an LLMNR query, it responds to the 960 query IFF it aggregates an IP prefix that covers the prefix in the 961 query. If the name-service lookup succeeds, it will return RLOC 962 addresses (e.g., in DNS A records) that correspond to next-hop EBRs 963 to which the VET node can forward packets. 965 5.5. VET Interface Encapsulation/Decapsulation 967 VET interfaces encapsulate inner network layer packets in any 968 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 969 etc.) followed by a SEAL header (if necessary) followed by an outer 970 UDP header (if necessary) followed by an outer IP header. Following 971 all encapsulations, the VET interface submits the encapsulated packet 972 to the outer IP forwarding engine for transmission on an underlying 973 interface. The following sections provide further details on 974 encapsulation: 976 5.5.1. Inner Network Layer Protocol 978 The inner network layer protocol sees the VET interface as an 979 ordinary network interface, and views the outer network layer 980 protocol as an L2 transport. The inner- and outer network layer 981 protocol types are mutually independent and can be used in any 982 combination. Inner network layer protocol types include IPv6 983 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 984 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 986 5.5.2. Mid-Layer Encapsulation 988 VET interfaces that use mid-layer encapsulations encapsulate each 989 inner network layer packet in any mid-layer headers and trailers as 990 the first step in a potentially multi-layer encapsulation. 992 5.5.3. SEAL Encapsulation 994 Following any mid-layer encapsulations, VET interfaces that use SEAL 995 add a SEAL header as specified in [I-D.templin-intarea-seal]. 996 Inclusion of a SEAL header MUST be applied uniformly between all 997 nodes on the VET link. Note that when a VET interface sends a SEAL- 998 encapsulated packet to a VET node that does not use SEAL 999 encapsulation, it may receive an ICMP "port unreachable" or "protocol 1000 unreachable" depending on whether/not an outer UDP header is 1001 included. 1003 SEAL encapsulation is used on VET links that require path MTU 1004 mitigations due to encapsulation overhead and/or mechanisms for VET 1005 interface neighbor coordination. When SEAL encapsulation is used, 1006 the VET interface sets the 'Next Header' value in the SEAL header to 1007 the IP protocol number associated with either the mid-layer 1008 encapsulation or the IP protocol number of the inner network layer 1009 (if no mid-layer encapsulation is used). The VET interface sets the 1010 other fields in the SEAL header as specified in 1011 [I-D.templin-intarea-seal]. 1013 5.5.4. Outer UDP Header Encapsulation 1015 Following any mid-layer and/or SEAL encapsulations, VET interfaces 1016 that use UDP encapsulation add an outer UDP header. Inclusion of an 1017 outer UDP header must be applied uniformly between all nodes on the 1018 VET link. Note that when a VET interface sends a UDP-encapsulated 1019 packet to a node that does not recognize the UDP port number, it may 1020 receive an ICMP "port unreachable" message. 1022 VET interfaces use UDP encapsulation on VET links that may traverse 1023 Network Address Translators (NATs) and/or legacy networking gear that 1024 only recognizes certain network layer protocols, e.g., Equal Cost 1025 MultiPath (ECMP) routers, Link Aggregation Gateways (LAGs), etc. 1026 When UDP encapsulation is used, the VET interface encapsulates the 1027 mid-layer packet in an outer UDP header then sets the UDP port 1028 numbers as specified for the outermost mid-layer protocol (e.g., 1029 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 1030 is used as the outermost mid-layer protocol, the VET interface sets 1031 the UDP source port number to a hash calculated over the inner 1032 network layer {destination, source} values or (optionally) over the 1033 inner network layer {dest addr, source addr, protocol, dest port, 1034 source port} values. The VET interface uses a hash function of its 1035 own choosing, but it MUST be consistent in the manner in which the 1036 hash is applied.. 1038 For VET links configured over IPv4 enterprise networks, the VET 1039 interface sets the UDP checksum field to zero. For VET links 1040 configured over IPv6 enterprise networks, considerations for setting 1041 the UDP checksum are discussed in [I-D.ietf-6man-udpzero]. 1043 5.5.5. Outer IP Header Encapsulation 1045 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1046 interface adds an outer IP header. Outer IP header construction is 1047 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1048 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1049 Service/Traffic Class" and "Congestion Experienced" values in the 1050 inner network layer header are copied into the corresponding fields 1051 in the outer IP header. The VET interface also sets the IP protocol 1052 number to the appropriate value for the first protocol layer within 1053 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1054 as the outer IP protocol, the VET interface sets the flow label value 1055 in the outer IPv6 header the same as described in 1056 [I-D.carpenter-flow-ecmp]. 1058 5.5.6. Decapsulation 1060 When a VET interface receives an encapsulated packet, it retains the 1061 outer headers and processes the SEAL header as specified in 1062 [I-D.templin-intarea-seal]. 1064 Next, if the packet will be forwarded from the receiving VET 1065 interface into a forwarding VET interface, the VET node copies the 1066 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1067 Experienced" values in the outer IP header received on the receiving 1068 VET interface into the corresponding fields in the outer IP header to 1069 be sent over the forwarding VET interface (i.e., the values are 1070 transferred between outer headers and *not* copied from the inner 1071 network layer header). This is true even if the packet is forwarded 1072 out the same VET interface that it arrived on, and necessary to 1073 support diagnostic functions (e.g., traceroute) and avoid looping. 1075 During decapsulation, when the next-hop is via a non-VET interface, 1076 the "Congestion Experienced" value in the outer IP header is copied 1077 into the corresponding field in the inner network layer header. 1079 5.6. Mobility and Multihoming Considerations 1081 EBRs that travel between distinct enterprise networks must either 1082 abandon their PA prefixes that are relative to the "old" enterprise 1083 and obtain PA prefixes relative to the "new" enterprise, or somehow 1084 coordinate with a "home" enterprise to retain ownership of the 1085 prefixes. In the first instance, the EBR would be required to 1086 coordinate a network renumbering event using the new PA prefixes 1087 [RFC4192][RFC5887]. In the second instance, an ancillary mobility 1088 management mechanism is required. 1090 EBRs can retain their PI prefixes as they travel between distinct 1091 enterprise networks as long as they update their PI prefix to public 1092 IP address mappings with their PI prefix vendors. This is 1093 accomplished by performing the same PI prefix vendor-specific short 1094 transactions as specified in Section 5.1.1. In this way, EBRs can 1095 update their PI prefix to RLOC mappings in real time as their RLOCs 1096 change. 1098 The EBGs of a multihomed enterprise network participate in a private 1099 inner network layer routing protocol instance (possibly over an 1100 alternate topology) to accommodate network partitions/merges as well 1101 as intra-enterprise mobility events. 1103 5.7. Neighbor Coordination on VET Interfaces using SEAL 1105 VET interfaces that use SEAL use the SEAL Control Message Protocol 1106 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1107 coordinate reachability, routing information, and mappings between 1108 the inner and outer network layer protocols. SCMP directly parallels 1109 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1110 [RFC4443] protocols, but operates from within the tunnel and supports 1111 operation for any combinations of inner and outer network layer 1112 protocols. 1114 The following subsections discuss VET interface neighbor coordination 1115 using SCMP: 1117 5.7.1. Router Discovery 1119 VET hosts and EBRs can send SCMP Router Solicitation (SRS) messages 1120 to one or more EBGs in the PRL to receive solicited SCMP Router 1121 Advertisements (SRAs). 1123 When an EBG receives an SRS message on a VET interface, it prepares a 1124 solicited SRA message. The SRA includes Router Lifetimes, Default 1125 Router Preferences, PIOs and any other options/parameters that the 1126 EBG is configured to include. If necessary, the EBG also includes 1127 Route Information Options (RIOs) formatted as specified in Section 1128 5.7.3, i.e., the RIO may contain both IPv6 and non-IPv6 prefixes in 1129 RIOs as identified by an Address Family designator. 1131 5.7.2. Neighbor Unreachability Detection 1133 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1134 interface neighbors by monitoring hints of forward progress as 1135 evidence that a neighbor is reachable. SEAL includes an explicit 1136 acknowledgement mechanism that can provide hints of forward progress. 1137 When data packets are flowing, the VET node can periodically set the 1138 A bit in data packets to elicit SCMP responses from the neighbor. 1139 When no data packets are flowing, the VET node can send periodic 1140 probes such as SCMP Neighbor Solicitation (SNS) messages for the same 1141 purpose. 1143 Responsiveness to routing changes is directly related to the delay in 1144 detecting that a neighbor has gone unreachable. In order to provide 1145 responsiveness comparable to dynamic routing protocols, a reasonably 1146 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1148 Additionally, a VET node may receive outer IP ICMP "Destination 1149 Unreachable; net / host unreachable" messages from an ER on the path 1150 indicating that the path to a VET neighbor may be failing. The node 1151 SHOULD first check the packet-in-error to obtain reasonable assurance 1152 that the ICMP message is authentic. If the node receives excessive 1153 ICMP unreachable errors through multiple RLOCs associated with the 1154 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1155 packets to flow through a different route. 1157 5.7.3. Redirect Function 1159 A VET node (i.e., the redirectee) may receive a redirect message when 1160 it forwards packets over a VET interface to a neighboring VET node 1161 (i.e., the redirector). The redirector will forward the packet and 1162 return an SCMP Redirect message if necessary to inform the redirectee 1163 of a better next hop. 1165 The SCMP Redirect message is formatted the same as for ordinary 1166 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1167 the Destination and Target Address fields are unnecessary and 1168 therefore omitted. The format of the SCMP Redirect message is shown 1169 in Figure 2 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Type = 137 | Code = 0 | Checksum | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Reserved | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Options ... 1178 +-+-+-+-+-+-+-+-+-+-+-+- 1180 Figure 2: SCMP Redirect Message Format 1182 The redirector then adds any necessary Options to the Redirect 1183 message. It first includes one or more Target Link-Layer Address 1184 Options (TLLAOs) (see: Section 4.6.1 of [RFC4861]) that include RLOCs 1185 corresponding to better next hops. The TLLAO formats for IPv4 and 1186 IPv6 RLOCs are shown in Figure 3 and Figure 4: 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Type = 2 | Length = 1 | Reserved | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | IPv4 address (bytes 0 thru 3) | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Figure 3: SCMP TLLAO Option for IPv4 RLOCs 1198 0 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Type = 2 | Length = 3 | Reserved | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Reserved | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | IPv6 address (bytes 0 thru 3) | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | IPv6 address (bytes 4 thru 7) | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | IPv6 address (bytes 8 thru 11) | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | IPv6 address (bytes 12 thru 15) | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 Figure 4: SCMP TLLAO Option for IPv6 RLOCs 1216 The redirector next includes a Route Information Option (RIO) (see: 1217 [RFC4191]) that contains a prefix from its FIB that covers the 1218 destination address of the original packet. SCMP uses a modified 1219 version of the RIO option formatted as shown in Figure 5: 1221 0 1 2 3 1222 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 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Type = 24 | Length | Prefix Length | AF |Prf|E|RSV| 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Route Lifetime | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Prefix (Variable Length) | 1229 . . 1230 . . 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 Figure 5: SCMP Route Information Option Format 1235 In this modified format, the redirector prepares the Route Lifetime 1236 and Prefix fields in the RIO option the same as specified in 1237 [RFC4191]. It then sets the fields in the header as follows: 1239 o the 'Type', 'Length' and 'Prf' fields are set the same as 1240 specified in [RFC4191]. 1242 o the 'RSV' field is set to 0. 1244 o he 'Length' field is set to 1, 2, or 3 as specified in [RFC4191], 1245 or set to 4 if the 'Prefix Length' is greater than 128 in order to 1246 accommodate prefixes of non-IP protocols of up to 192 bits in 1247 length. 1249 o the 'Prefix Length' field ranges from 0 to 192. The 'Prefix' 1250 field is 0, 8, 16 or 24 octets depending on the length, and the 1251 embedded prefix MAY be up to 192 bits in length. 1253 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1254 that indicates the embedded prefix protocol type. This document 1255 defines the following values for AF: 1257 * 000 - IPv4 1259 * 001 - IPv6 1261 * 010 - OSI/CLNP NSAP 1263 o the 'E' bit is set to 1 if this prefix is assigned to an End User 1264 Network, and set to 0 otherwise. 1266 Following the RIO option, the redirector includes any other necessary 1267 options (e.g., SEND options) followed by a Redirected Header 1268 containing the leading portion of the packet that triggered the 1269 redirect as the final option in the message. The redirector then 1270 encapsulates the Redirect message the same as for any other SCMP 1271 message and sends it to the redirectee. 1273 When the redirectee receives the Redirect, it first authenticates the 1274 message (i.e., by checking the SEAL_ID in the Redirected Header, by 1275 examining SEND options, etc.) then uses the EID prefix in the RIO 1276 with its respective lifetime to update its FIB. The redirectee also 1277 caches the IPv4 or IPv6 addresses in TLLAOs as the layer 2 addresses 1278 of potential next-hops. 1280 The redirectee retains the FIB entry created as a result of receipt 1281 of an SCMP Redirect until the route lifetime expires, or until the 1282 redirected target neighbor becomes unreachable. In this way, RLOC 1283 liveness detection parallels IPv6 Neighbor Unreachability Detection 1284 as discussed in the next section. 1286 5.7.4. Mobility 1288 When a VET node moves to a new network point of attachment resulting 1289 in the change of an old RLOC to a new RLOC, it leaves short-term 1290 forwarding information with its former network point of attachment. 1291 Thereafter, any existing correspondents that attempt to contact the 1292 mobile node via the former network point of attachment will be 1293 redirected to the new network point of attachment. Any new 1294 correspondents will instead be directed to the new network point of 1295 attachment. 1297 5.8. Neighbor Coordination on VET Interfaces using IPsec 1299 VET interfaces that use IPsec encapsulation use the Internet Key 1300 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1301 association setup and maintenance. The IKEv2 can be seen as a 1302 logical equivalent of the SEAL SCMP in terms of VET interface 1303 neighbor coordinations. In particular, IKEv2 also provides 1304 mechanisms for redirection [RFC5685] and mobility [RFC4555]. 1306 IPsec additionally provides an extended Identification field and 1307 integrity check vector; these features allow IPsec to utilize outer 1308 IP fragmentation and reassembly with less risk of exposure to data 1309 corruption due to reassembly misassociations. On the other hand, 1310 IPsec entails the use of symmetric security associations and hence 1311 may not be appropriate to all enterprise network use cases. 1313 5.9. Multicast 1315 In multicast-capable deployments, ERs provide an enterprise-wide 1316 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1317 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1318 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1319 over their enterprise-interior interfaces such that outer IP 1320 multicast messages of site-scope or greater scope will be propagated 1321 across the enterprise network. For such deployments, VET nodes can 1322 also provide an inner multicast/broadcast capability over their VET 1323 interfaces through mapping of the inner multicast address space to 1324 the outer multicast address space. In that case, operation of link- 1325 scoped (or greater scoped) inner multicasting services (e.g., a link- 1326 scoped neighbor discovery protocol) over the VET interface is 1327 available, but should be used sparingly to minimize enterprise-wide 1328 flooding. 1330 VET nodes encapsulate inner multicast messages sent over the VET 1331 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1332 followed by an outer IP header with a site-scoped outer IP multicast 1333 address as the destination. For the case of IPv6 and IPv4 as the 1334 inner/outer protocols (respectively), [RFC2529] provides mappings 1335 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1336 address space (for other encapsulations, mappings are established 1337 through administrative configuration or through an unspecified 1338 alternate static mapping). 1340 Multicast mapping for inner multicast groups over outer IP multicast 1341 groups can be accommodated, e.g., through VET interface snooping of 1342 inner multicast group membership and routing protocol control 1343 messages. To support inner-to-outer multicast address mapping, the 1344 VET interface acts as a virtual outer IP multicast host connected to 1345 its underlying interfaces. When the VET interface detects that an 1346 inner multicast group joins or leaves, it forwards corresponding 1347 outer IP multicast group membership reports on an underlying 1348 interface over which the VET interface is configured. If the VET 1349 node is configured as an outer IP multicast router on the underlying 1350 interfaces, the VET interface forwards locally looped-back group 1351 membership reports to the outer IP multicast routing process. If the 1352 VET node is configured as a simple outer IP multicast host, the VET 1353 interface instead forwards actual group membership reports (e.g., 1354 IGMP messages) directly over an underlying interface. 1356 Since inner multicast groups are mapped to site-scoped outer IP 1357 multicast groups, the VET node MUST ensure that the site-scope outer 1358 IP multicast messages received on the underlying interfaces for one 1359 VET interface do not "leak out" to the underlying interfaces of 1360 another VET interface. This is accommodated through normal site- 1361 scoped outer IP multicast group filtering at enterprise network 1362 boundaries. 1364 5.10. Service Discovery 1366 VET nodes can perform enterprise-wide service discovery using a 1367 suitable name-to-address resolution service. Examples of flooding- 1368 based services include the use of LLMNR [RFC4795] over the VET 1369 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1370 over an underlying interface. More scalable and efficient service 1371 discovery mechanisms (e.g., anycast) are for further study. 1373 5.11. Enterprise Network Partitioning 1375 An enterprise network can be partitioned into multiple distinct 1376 logical groupings. In that case, each partition configures its own 1377 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1378 'isatapv2.zone2.example.com', etc.). 1380 EBGs can further create multiple IP subnets within a partition, e.g., 1381 by sending RAs with PIOs containing different IP prefixes to 1382 different groups of VET hosts. EBGs can identify subnets, e.g., by 1383 examining RLOC prefixes, observing the enterprise interior interfaces 1384 over which RSs are received, etc. 1386 In the limiting case, EBGs can advertise a unique set of IP prefixes 1387 to each VET host such that each host belongs to a different subnet 1388 (or set of subnets) on the VET interface. 1390 5.12. EBG Prefix State Recovery 1392 EBGs retain explicit state that tracks the inner PA prefixes 1393 delegated to EBRs within the enterprise network, e.g., so that 1394 packets are delivered to the correct EBRs. When an EBG loses some or 1395 all of its state (e.g., due to a power failure), it must recover the 1396 state so that packets can be forwarded over correct routes. 1398 5.13. Support for Legacy ISATAP Services 1400 EBGs support legacy ISATAP services according to the specifications 1401 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1402 interfaces and VET interfaces over the same sets of underlying 1403 interfaces as long as the PRLs and IPv6 prefixes associated with the 1404 ISATAP/VET interfaces are distinct. 1406 6. IANA Considerations 1408 There are no IANA considerations for this document. 1410 7. Security Considerations 1412 Security considerations for MANETs are found in [RFC2501]. 1414 The security considerations found in 1415 [RFC2529][RFC5214][I-D.nakibly-v6ops-tunnel-loops] also apply to VET. 1417 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1418 where attacks on the neighbor coordination protocol are possible. 1419 SEAL [I-D.templin-intarea-seal] provides a per-packet identification 1420 that can be used to detect source address spoofing. 1422 Rogue neighbor coordination messages with spoofed RLOC source 1423 addresses can consume network resources and cause VET nodes to 1424 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1425 such RLOCs, as that may result in a denial of service to the RLOCs' 1426 legitimate owners. 1428 VET EBRs and EBGs observe the recommendations for network ingress 1429 filtering [RFC2827]. 1431 8. Related Work 1433 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1434 automatic tunneling in [RFC2529]; this concept was later called: 1435 "Virtual Ethernet" and investigated by Quang Nguyen under the 1436 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1437 their colleagues have motivated a number of foundational concepts on 1438 which this work is based. 1440 Telcordia has proposed DHCP-related solutions for MANETs through the 1441 CECOM MOSAIC program. 1443 The Naval Research Lab (NRL) Information Technology Division uses 1444 DHCP in their MANET research testbeds. 1446 Security concerns pertaining to tunneling mechanisms are discussed in 1447 [I-D.ietf-v6ops-tunnel-security-concerns]. 1449 Default router and prefix information options for DHCPv6 are 1450 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1452 An automated IPv4 prefix delegation mechanism is proposed in 1453 [I-D.ietf-dhc-subnet-alloc]. 1455 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1456 [I-D.clausen-manet-autoconf-recommendations]. 1458 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1460 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1461 decapsulation issues and other aspects of tunneling. 1463 Various proposals within the IETF have suggested similar mechanisms. 1465 9. Acknowledgements 1467 The following individuals gave direct and/or indirect input that was 1468 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1469 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1470 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1471 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1472 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1473 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1474 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1475 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1476 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1477 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1478 working groups. Many others have provided guidance over the course 1479 of many years. 1481 10. Contributors 1483 The following individuals have contributed to this document: 1485 Eric Fleischman (eric.fleischman@boeing.com) 1486 Thomas Henderson (thomas.r.henderson@boeing.com) 1487 Steven Russert (steven.w.russert@boeing.com) 1488 Seung Yi (seung.yi@boeing.com) 1490 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1491 of the document. 1493 Jim Bound's foundational work on enterprise networks provided 1494 significant guidance for this effort. We mourn his loss and honor 1495 his contributions. 1497 11. References 1499 11.1. Normative References 1501 [I-D.templin-intarea-seal] 1502 Templin, F., "The Subnetwork Encapsulation and Adaptation 1503 Layer (SEAL)", draft-templin-intarea-seal-24 (work in 1504 progress), November 2010. 1506 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1507 September 1981. 1509 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1510 RFC 792, September 1981. 1512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1513 Requirement Levels", BCP 14, RFC 2119, March 1997. 1515 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1516 RFC 2131, March 1997. 1518 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1519 (IPv6) Specification", RFC 2460, December 1998. 1521 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1522 Defeating Denial of Service Attacks which employ IP Source 1523 Address Spoofing", BCP 38, RFC 2827, May 2000. 1525 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1526 and M. Carney, "Dynamic Host Configuration Protocol for 1527 IPv6 (DHCPv6)", RFC 3315, July 2003. 1529 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1530 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1531 December 2003. 1533 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1534 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1536 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1537 RFC 3972, March 2005. 1539 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1540 More-Specific Routes", RFC 4191, November 2005. 1542 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1543 Architecture", RFC 4291, February 2006. 1545 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1546 Message Protocol (ICMPv6) for the Internet Protocol 1547 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1549 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1550 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1551 September 2007. 1553 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1554 Address Autoconfiguration", RFC 4862, September 2007. 1556 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1557 for IEEE 802 Parameters", BCP 141, RFC 5342, 1558 September 2008. 1560 11.2. Informative References 1562 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1563 Switching Networks", May 1974. 1565 [I-D.carpenter-flow-ecmp] 1566 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1567 for equal cost multipath routing and link aggregation in 1568 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 1569 October 2010. 1571 [I-D.cheshire-dnsext-multicastdns] 1572 Cheshire, S. and M. Krochmal, "Multicast DNS", 1573 draft-cheshire-dnsext-multicastdns-12 (work in progress), 1574 October 2010. 1576 [I-D.clausen-manet-autoconf-recommendations] 1577 Clausen, T. and U. Herberg, "MANET Router Configuration 1578 Recommendations", 1579 draft-clausen-manet-autoconf-recommendations-00 (work in 1580 progress), February 2009. 1582 [I-D.clausen-manet-linktype] 1583 Clausen, T., "The MANET Link Type", 1584 draft-clausen-manet-linktype-00 (work in progress), 1585 October 2008. 1587 [I-D.droms-dhc-dhcpv6-default-router] 1588 Droms, R. and T. Narten, "Default Router and Prefix 1589 Advertisement Options for DHCPv6", 1590 draft-droms-dhc-dhcpv6-default-router-00 (work in 1591 progress), March 2009. 1593 [I-D.ietf-6man-udpzero] 1594 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 1595 Considerations", draft-ietf-6man-udpzero-02 (work in 1596 progress), October 2010. 1598 [I-D.ietf-dhc-subnet-alloc] 1599 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1600 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1601 (work in progress), May 2010. 1603 [I-D.ietf-grow-va] 1604 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1605 L. Zhang, "FIB Suppression with Virtual Aggregation", 1606 draft-ietf-grow-va-03 (work in progress), August 2010. 1608 [I-D.ietf-lisp] 1609 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1610 "Locator/ID Separation Protocol (LISP)", 1611 draft-ietf-lisp-09 (work in progress), October 2010. 1613 [I-D.ietf-manet-smf] 1614 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1615 draft-ietf-manet-smf-10 (work in progress), March 2010. 1617 [I-D.ietf-v6ops-tunnel-security-concerns] 1618 Krishnan, S., Thaler, D., and J. Hoagland, "Security 1619 Concerns With IP Tunneling", 1620 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 1621 progress), October 2010. 1623 [I-D.jen-apt] 1624 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1625 L. Zhang, "APT: A Practical Transit Mapping Service", 1626 draft-jen-apt-01 (work in progress), November 2007. 1628 [I-D.nakibly-v6ops-tunnel-loops] 1629 Nakibly, G. and F. Templin, "Routing Loop Attack using 1630 IPv6 Automatic Tunnels: Problem Statement and Proposed 1631 Mitigations", draft-nakibly-v6ops-tunnel-loops-03 (work in 1632 progress), August 2010. 1634 [I-D.russert-rangers] 1635 Russert, S., Fleischman, E., and F. Templin, "RANGER 1636 Scenarios", draft-russert-rangers-05 (work in progress), 1637 July 2010. 1639 [I-D.templin-iron] 1640 Templin, F., "The Internet Routing Overlay Network 1641 (IRON)", draft-templin-iron-13 (work in progress), 1642 October 2010. 1644 [I-D.templin-isatap-dhcp] 1645 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1646 Option for the Intra-Site Automatic Tunnel Addressing 1647 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1648 progress), December 2009. 1650 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1651 July 1978. 1653 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1654 Protocol Specification", October 2008. 1656 [RFC0994] International Organization for Standardization (ISO) and 1657 American National Standards Institute (ANSI), "Final text 1658 of DIS 8473, Protocol for Providing the Connectionless- 1659 mode Network Service", RFC 994, March 1986. 1661 [RFC1035] Mockapetris, P., "Domain names - implementation and 1662 specification", STD 13, RFC 1035, November 1987. 1664 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1665 a subnetwork for experimentation with the OSI network 1666 layer", RFC 1070, February 1989. 1668 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1669 Communication Layers", STD 3, RFC 1122, October 1989. 1671 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1672 Routing and Addressing Architecture", RFC 1753, 1673 December 1994. 1675 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1676 E. Lear, "Address Allocation for Private Internets", 1677 BCP 5, RFC 1918, February 1996. 1679 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1680 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1682 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1683 October 1996. 1685 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1686 Extensions", RFC 2132, March 1997. 1688 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1689 IPv6 Specification", RFC 2473, December 1998. 1691 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1692 over Non-Broadcast Multiple Access (NBMA) networks", 1693 RFC 2491, January 1999. 1695 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1696 (MANET): Routing Protocol Performance Issues and 1697 Evaluation Considerations", RFC 2501, January 1999. 1699 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1700 Domains without Explicit Tunnels", RFC 2529, March 1999. 1702 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1703 February 2000. 1705 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1706 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1707 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1708 RFC 3819, July 2004. 1710 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1711 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1712 May 2005. 1714 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1715 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1716 January 2005. 1718 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1719 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1720 RFC 3948, January 2005. 1722 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1723 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1724 September 2005. 1726 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1727 Addresses", RFC 4193, October 2005. 1729 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1730 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1732 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1733 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1735 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1736 Internet Protocol", RFC 4301, December 2005. 1738 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1739 RFC 4306, December 2005. 1741 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1742 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1743 May 2006. 1745 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1746 (MOBIKE)", RFC 4555, June 2006. 1748 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1749 Multicast Name Resolution (LLMNR)", RFC 4795, 1750 January 2007. 1752 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1753 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1754 Focus", RFC 4852, April 2007. 1756 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1757 June 2007. 1759 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1760 Extensions for Stateless Address Autoconfiguration in 1761 IPv6", RFC 4941, September 2007. 1763 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1764 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1765 March 2008. 1767 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1768 for IPv6", RFC 5340, July 2008. 1770 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1771 Infrastructures (6rd)", RFC 5569, January 2010. 1773 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1774 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1775 RFC 5685, November 2009. 1777 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1778 Global Enterprise Recursion (RANGER)", RFC 5720, 1779 February 2010. 1781 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1782 Still Needs Work", RFC 5887, May 2010. 1784 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1785 Infrastructures (6rd) -- Protocol Specification", 1786 RFC 5969, August 2010. 1788 Appendix A. Duplicate Address Detection (DAD) Considerations 1790 A priori uniqueness determination (also known as "pre-service DAD") 1791 for an RLOC assigned on an enterprise-interior interface would 1792 require either flooding the entire enterprise network or somehow 1793 discovering a link in the network on which a node that configures a 1794 duplicate address is attached and performing a localized DAD exchange 1795 on that link. But, the control message overhead for such an 1796 enterprise-wide DAD would be substantial and prone to false-negatives 1797 due to packet loss and intermittent connectivity. An alternative to 1798 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1799 enterprise-interior interfaces and employ a passive in-service DAD 1800 (e.g., one that monitors routing protocol messages for duplicate 1801 assignments). 1803 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1804 CGAs, IPv6 privacy addresses, etc. with very small probability of 1805 collision. Pseudo-random IPv4 RLOCs can be generated through random 1806 assignment from a suitably large IPv4 prefix space. 1808 Consistent operational practices can assure uniqueness for EBG- 1809 aggregated addresses/prefixes, while statistical properties for 1810 pseudo-random address self-generation can assure uniqueness for the 1811 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1812 RLOC delegation authority should be used when available, while a 1813 passive in-service DAD mechanism should be used to detect RLOC 1814 duplications when there is no RLOC delegation authority. 1816 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1818 For each distinct enterprise network that it connects to, an EBR 1819 configures a VET interface over possibly multiple underlying 1820 interfaces that all connect to the same network. The VET interface 1821 therefore represents the EBR's logical point of attachment to the 1822 enterprise network, and provides a logical interface for link-layer 1823 multiplexing over its underlying interfaces as described in Section 1824 3.3.4 of [RFC1122]: 1826 "Finally, we note another possibility that is NOT multihoming: one 1827 logical interface may be bound to multiple physical interfaces, in 1828 order to increase the reliability or throughput between directly 1829 connected machines by providing alternative physical paths between 1830 them. For instance, two systems might be connected by multiple 1831 point-to-point links. We call this "link-layer multiplexing". 1833 With link-layer multiplexing, the protocols above the link layer 1834 are unaware that multiple physical interfaces are present; the 1835 link-layer device driver is responsible for multiplexing and 1836 routing packets across the physical interfaces." 1838 EBRs can support such a link-layer multiplexing capability across the 1839 enterprise network in accordance with the Weak End System Model (see 1840 Section 3.3.4 of [RFC1122]). In particular, when an EBR 1841 autoconfigures an RLOC address, it can associate it with the VET 1842 interface only instead of assigning it to an underlying interface. 1843 The EBR therefore only needs to obtain a single RLOC address even if 1844 there are multiple underlying interfaces, i.e., it does not need to 1845 obtain one for each underlying interface. The EBR can then leave the 1846 underlying interfaces unnumbered, or it can configure a randomly 1847 chosen IP link-local address (e.g., from the prefix 169.254/16 1848 [RFC3927] for IPv4) on underlying interfaces that require a 1849 configuration. The EBR need not check these link-local addresses for 1850 uniqueness within the enterprise network, as they will not normally 1851 be used as the source address for packets. 1853 When the EBR engages in the enterprise-interior routing protocol, it 1854 uses the RLOC address assigned to the VET interface as the source 1855 address for all routing protocol control messages, however it must 1856 also supply an interface identifier (e.g., a small integer) that 1857 uniquely identifies the underlying interface that the control message 1858 is sent over. For example, if the underlying interfaces are known as 1859 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1860 sends a routing protocol control message over the "eth7" interface. 1861 This is necessary to ensure that other routers can determine the 1862 specific interface over which the EBR's routing protocol control 1863 message was sent, but the token need only be unique within the EBR 1864 itself and need not be unique throughout the enterprise network. 1866 When the EBR discovers an RLOC route via the enterprise interior 1867 routing protocol, it configures a preferred route in the IP FIB that 1868 points to the VET interface instead of the underlying interface. At 1869 the same time, the EBR also configures an ancillary route that points 1870 to the underlying interface. If the EBR discovers that the same RLOC 1871 route is reachable via multiple underlying interfaces, it configures 1872 multiple ancillary routes (i.e., one for each interface). If the EBR 1873 discovers that the RLOC route is no longer reachable via any 1874 underlying interface, it removes the route in the IP FIB that points 1875 to the VET interface. 1877 With these arrangements, all locally-generated packets with RLOC 1878 destinations will flow through the VET interface (and thereby use the 1879 VET interface's RLOC address as the source address) instead of 1880 through the underlying interfaces. In the same fashion, all 1881 forwarded packets with RLOC destinations will flow through the VET 1882 interface instead of through the underlying interfaces. 1884 This arrangement has several operational advantages that enable a 1885 number of traffic engineering capabilities when SEAL encapsulation is 1886 also used. First, the VET interface can insert the SEAL header so 1887 that ID-based duplicate packet detection is enabled within the 1888 enterprise network. Secondly, SEAL can dynamically adjust its packet 1889 sizing parameters so that an optimum Maximum Transmission Unit (MTU) 1890 can be determined. This is true even if the VET interface reroutes 1891 traffic between underlying interfaces with different MTUs. 1893 Most importantly, the EBR can configure default and more-specific 1894 routes on the VET interface to direct traffic through a specific 1895 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1896 will ensure that a specific eEBR is chosen, and the best eEBR can be 1897 chosen when multiple are available. Also, local applications see a 1898 stable IP source address even if there are multiple underlying 1899 interfaces. This link-layer multiplexing can therefore provide 1900 continuous operation across failovers between multiple links attached 1901 to the same enterprise network without any need for readdressing. 1902 Finally, the VET interface can forward packets with RLOC-based 1903 destinations over an underlying interface without any encapsulation 1904 if encapsulation avoidance is desired. 1906 It must be specifically noted that the above arrangement constitutes 1907 a case in which the same RLOC may be used as both the inner and outer 1908 IP source address. This will not present a problem as long as both 1909 ends configure a VET interface in the same fashion. 1911 It must also be noted that EID-based communications can use the same 1912 VET interface arrangement, except that the EID-based next hop must be 1913 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1914 within IPvX encapsulation, as well as for IPv4 within IPv6 1915 encapsulation, this requires a VET interface specific address mapping 1916 database. For IPv6 within IPv4 encapsulation, the mapping is 1917 accomplished through simple static extraction of an IPv4 address 1918 embedded within the IPv6 address. 1920 Appendix C. Anycast Services 1922 Some of the IPv4 addresses that appear in the Potential Router List 1923 may be anycast addresses, i.e., they may be configured on the VET 1924 interfaces of multiple EBRs/EBGs. In that case, each VET router 1925 interface that configures the same anycast address must provide 1926 equivalent packet forwarding and neighbor discovery services. 1928 Use of an anycast address as the IP destination address of tunneled 1929 packets can have subtle interactions with tunnel path MTU and 1930 neighbor discovery. For example, if the initial fragments of a 1931 fragmented tunneled packet with an anycast IP destination address are 1932 routed to different egress tunnel endpoints than the remaining 1933 fragments, the multiple endpoints will be left with incomplete 1934 reassembly buffers. This issue can be mitigated by ensuring that 1935 each egress tunnel endpoint implements a proactive reassembly buffer 1936 garbage collection strategy. Additionally, ingress tunnel endpoints 1937 that send packets with an anycast IP destination address must use the 1938 minimum path MTU for all egress tunnel endpoints that configure the 1939 same anycast address as the tunnel MTU. Finally, ingress tunnel 1940 endpoints should treat ICMP unreachable messages from a router within 1941 the tunnel as at most a weak indication of neighbor unreachability, 1942 since the failures may only be transient and a different path to an 1943 alternate anycast router quickly selected through reconvergence of 1944 the underlying routing protocol. 1946 Use of an anycast address as the IP source address of tunneled 1947 packets can lead to more serious issues. For example, when the IP 1948 source address of a tunneled packet is anycast, ICMP messages 1949 produced by routers within the tunnel might be delivered to different 1950 ingress tunnel endpoints than the ones that produced the packets. In 1951 that case, functions such as path MTU discovery and neighbor 1952 unreachability detection may experience non-deterministic behavior 1953 that can lead to communications failures. Additionally, the 1954 fragments of multiple tunneled packets produced by multiple ingress 1955 tunnel endpoints may be delivered to the same reassembly buffer at a 1956 single egress tunnel endpoint. In that case, data corruption may 1957 result due to fragment misassociation during reassembly. 1959 In view of these considerations, EBRs/EBGs that configure an anycast 1960 address should also configure one or more unicast addresses from the 1961 Potential Router List; they should further accept tunneled packets 1962 destined to any of their anycast or unicast addresses, but should 1963 send tunneled packets using a unicast address as the source address. 1964 In order to influence traffic to use an anycast route (and thereby 1965 leverage the natural fault tolerance afforded by anycast), ISATAP 1966 routers should set higher preferences on the default routes they 1967 advertise using an anycast address as the source and set lower 1968 preferences on the default routes they advertise using a unicast 1969 address as the source (see: [RFC4191]). 1971 Appendix D. Change Log 1973 (Note to RFC editor - this section to be removed before publication 1974 as an RFC.) 1975 Changes from -14 to -15: 1977 o new insights into default route configuration and next-hop 1978 determination 1980 Changes from -13 to -14: 1982 o fixed Idnits 1984 Changes from -12 to -13: 1986 o Changed "VGL" *back* to "PRL" 1988 o More changes for multi-protocol support 1990 o Changes to Redirect function 1992 Changes from -11 to -12: 1994 o Major section rearrangement 1996 o Changed "PRL" to "VGL" 1998 o Brought back text that was lost in the -10 to -11 transition 2000 Changes from -10 to -11: 2002 o Major changes with significant simplifications 2004 o Now support stateless PD using 6rd mechanisms 2006 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 2008 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 2010 Changes from -09 to -10: 2012 o Changed "enterprise" to "enterprise network" throughout 2014 o dropped "inner IP", since inner layer may be non-IP 2016 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 2017 messages remain *within* the tunnel interface instead of being 2018 exposed to the inner network layer protocol engine. 2020 Changes from -08 to -09: 2022 o Expanded discussion of encapsulation/decapsulation procedures 2024 o cited IRON 2026 Changes from -07 to -08: 2028 o Specified the approach to global mapping using virtual aggregation 2029 and BGP 2031 Changes from -06 to -07: 2033 o reworked redirect function 2035 o created new section on VET interface encapsulation 2037 o clarifications on nexthop selection 2039 o fixed several bugs 2041 Changed from -05 to -06: 2043 o reworked VET interface ND 2045 o anycast clarifications 2047 Changes from -03 to -04: 2049 o security consideration clarifications 2051 Changes from -02 to -03: 2053 o security consideration clarifications 2055 o new PRLNAME for VET is "isatav2.example.com" 2057 o VET now uses SEAL natively 2059 o EBGs can support both legacy ISATAP and VET over the same 2060 underlying interfaces. 2062 Changes from -01 to -02: 2064 o Defined CGA and privacy address configuration on VET interfaces 2066 o Interface identifiers added to routing protocol control messages 2067 for link-layer multiplexing 2069 Changes from -00 to -01: 2071 o Section 4.1 clarifications on link-local assignment and RLOC 2072 autoconfiguration. 2074 o Appendix B clarifications on Weak End System Model 2076 Changes from RFC5558 to -00: 2078 o New appendix on RLOC configuration on VET interfaces. 2080 Author's Address 2082 Fred L. Templin (editor) 2083 Boeing Research & Technology 2084 P.O. Box 3707 MC 7L-49 2085 Seattle, WA 98124 2086 USA 2088 Email: fltemplin@acm.org