idnits 2.17.1 draft-templin-intarea-vet-20.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 (January 13, 2011) is 4823 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-26 ** 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-13 == 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 -- 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 (~~), 9 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 January 13, 2011 5 Expires: July 17, 2011 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-20.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 July 17, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Enterprise Network Characteristics . . . . . . . . . . . . . . 11 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 61 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 12 62 4.2. VET Border Router (VBR) Autoconfiguration . . . . . . . . 14 63 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 14 64 4.2.2. Provider-Aggregated (PA) EID Prefix 65 Autoconfiguration . . . . . . . . . . . . . . . . . . 15 66 4.2.3. Provider-(In)dependent (PI) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 68 4.3. VET Border Gateway (VBG) Autoconfiguration . . . . . . . . 18 69 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . 22 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 . . . . . . . . . 24 84 5.7. Neighbor Coordination on VET Interfaces using SEAL . . . . 25 85 5.7.1. Router Discovery . . . . . . . . . . . . . . . . . . . 27 86 5.7.2. Neighbor Unreachability Detection . . . . . . . . . . 27 87 5.7.3. Redirect Function . . . . . . . . . . . . . . . . . . 28 88 5.8. Neighbor Coordination on VET Interfaces using IPsec . . . 29 89 5.9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29 90 5.9.1. Multicast over (Non)Multicast Enterprise Networks . . 29 91 5.9.2. Multicast Over Multicast-Capable Enterprise 92 Networks . . . . . . . . . . . . . . . . . . . . . . . 30 93 5.10. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 94 5.11. VET Link Partitioning . . . . . . . . . . . . . . . . . . 31 95 5.12. VBG Prefix State Recovery . . . . . . . . . . . . . . . . 31 96 5.13. Support for Legacy ISATAP Services . . . . . . . . . . . . 31 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 99 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 101 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 105 Appendix A. Duplicate Address Detection (DAD) Considerations . . 40 106 Appendix B. Anycast Services . . . . . . . . . . . . . . . . . . 40 107 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 41 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 110 1. Introduction 112 Enterprise networks [RFC4852] connect hosts and routers over various 113 link types (see [RFC4861], Section 2.2). The term "enterprise 114 network" in this context extends to a wide variety of use cases and 115 deployment scenarios. For example, an "enterprise" can be as small 116 as a Small Office, Home Office (SOHO) network, as complex as a multi- 117 organizational corporation, or as large as the global Internet 118 itself. Internet Service Provider (ISP) networks are another example 119 use case that fits well with the VET enterprise network model. 120 Mobile Ad hoc Networks (MANETs) [RFC2501] can also be considered as a 121 challenging example of an enterprise network, in that their 122 topologies may change dynamically over time and that they may employ 123 little/no active management by a centralized network administrative 124 authority. These specialized characteristics for MANETs require 125 careful consideration, but the same principles apply equally to other 126 enterprise network scenarios. 128 This document specifies a Virtual Enterprise Traversal (VET) 129 abstraction for autoconfiguration and internetworking operation, 130 where addresses of different scopes may be assigned on various types 131 of interfaces with diverse properties. Both IPv4/ICMPv4 132 [RFC0791][RFC0792] and IPv6/ICMPv6 [RFC2460][RFC4443] are discussed 133 within this context (other network layer protocols are also 134 considered). The use of standard DHCP [RFC2131] [RFC3315] is assumed 135 unless otherwise specified. 137 Provider-Edge Interfaces 138 x x x 139 | | | 140 +--------------------+---+--------+----------+ E 141 | | | | | n 142 | I | | .... | | t 143 | n +---+---+--------+---+ | e 144 | t | +--------+ /| | r 145 | e I x----+ | Host | I /*+------+--< p I 146 | r n | |Function| n|**| | r n 147 | n t | +--------+ t|**| | i t 148 | a e x----+ V e|**+------+--< s e 149 | l r . | E r|**| . | e r 150 | f . | T f|**| . | f 151 | V a . | +--------+ a|**| . | I a 152 | i c . | | Router | c|**| . | n c 153 | r e x----+ |Function| e \*+------+--< t e 154 | t s | +--------+ \| | e s 155 | u +---+---+--------+---+ | r 156 | a | | .... | | i 157 | l | | | | o 158 +--------------------+---+--------+----------+ r 159 | | | 160 x x x 161 Enterprise-Edge Interfaces 163 Figure 1: Enterprise Router (ER) Architecture 165 Figure 1 above depicts the architectural model for an Enterprise 166 Router (ER). As shown in the figure, an ER may have a variety of 167 interface types including enterprise-edge, enterprise-interior, 168 provider-edge, internal-virtual, as well as VET interfaces used for 169 encapsulating inner network layer protocol packets for transmission 170 over outer IPv4 or IPv6 networks. The different types of interfaces 171 are defined, and the autoconfiguration mechanisms used for each type 172 are specified. This architecture applies equally for MANET routers, 173 in which enterprise-interior interfaces typically correspond to the 174 wireless multihop radio interfaces associated with MANETs. Out of 175 scope for this document is the autoconfiguration of provider 176 interfaces, which must be coordinated in a manner specific to the 177 service provider's network. 179 Enterprise networks require a means for supporting both Provider- 180 (In)dependent (PI) and Provider-Aggregated (PA) addressing. This is 181 especially true for enterprise network scenarios that involve 182 mobility and multihoming. The VET specification provides adaptable 183 mechanisms that address these and other issues in a wide variety of 184 enterprise network use cases. 186 The VET framework builds on a Non-Broadcast Multiple Access (NBMA) 187 [RFC2491] virtual interface model in a manner similar to other 188 automatic tunneling technologies [RFC2529][RFC5214]. VET interfaces 189 support the encapsulation of inner network layer protocol packets 190 over IP networks (i.e., either IPv4 or IPv6). VET is also compatible 191 with mid-layer encapsulation technologies including IPsec [RFC4301], 192 and supports both stateful and stateless prefix delegation. 194 VET and its associated technologies (including the Subnetwork 195 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal]) 196 are functional building blocks for a new Internetworking architecture 197 based on the Internet Routing Overlay Network (IRON) 198 [I-D.templin-iron] and Routing and Addressing in Networks with Global 199 Enterprise Recursion (RANGER) [RFC5720] [I-D.russert-rangers]. Many 200 of the VET principles can be traced to the deliberations of the ROAD 201 group in January 1992, and also to still earlier initiatives 202 including NIMROD [RFC1753] and the Catenet model for internetworking 203 [CATENET] [IEN48] [RFC2775]. The high-level architectural aspects of 204 the ROAD group deliberations are captured in a "New Scheme for 205 Internet Routing and Addressing (ENCAPS) for IPNG" [RFC1955]. 207 VET is related to the present-day activities of the IETF INTAREA, 208 AUTOCONF, DHC, IPv6, MANET, and V6OPS working groups, as well as the 209 IRTF RRG working group. 211 2. Terminology 213 The mechanisms within this document build upon the fundamental 214 principles of IP encapsulation. The term "inner" refers to the 215 innermost {address, protocol, header, packet, etc.} *before* 216 encapsulation, and the term "outer" refers to the outermost {address, 217 protocol, header, packet, etc.} *after* encapsulation. VET also 218 accommodates "mid-layer" encapsulations including the Subnetwork 219 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal], 220 IPsec [RFC4301], etc. 222 The terminology in the normative references apply; the following 223 terms are defined within the scope of this document: 225 Virtual Enterprise Traversal (VET) 226 an abstraction that uses encapsulation to create virtual overlays 227 for transporting inner network layer packets over outer IPv4 and 228 IPv6 enterprise networks. 230 enterprise network 231 the same as defined in [RFC4852]. An enterprise network is 232 further understood to refer to a cooperative networked collective 233 of devices within a structured IP routing and addressing plan and 234 with a commonality of business, social, political, etc., 235 interests. Minimally, the only commonality of interest in some 236 enterprise network scenarios may be the cooperative provisioning 237 of connectivity itself. 239 subnetwork 240 the same as defined in [RFC3819]. 242 site 243 a logical and/or physical grouping of interfaces that connect a 244 topological area less than or equal to an enterprise network in 245 scope. From a network organizational standpoint, a site within an 246 enterprise network can be considered as an enterprise network unto 247 itself. 249 Mobile Ad hoc Network (MANET) 250 a connected topology of mobile or fixed routers that maintain a 251 routing structure among themselves over links that often have 252 dynamic connectivity properties. The characteristics of MANETs 253 are described in [RFC2501], Section 3, and a wide variety of 254 MANETs share common properties with enterprise networks. 256 enterprise/site/MANET 257 throughout the remainder of this document, the term "enterprise 258 network" is used to collectively refer to any of {enterprise, 259 site, MANET}, i.e., the VET mechanisms and operational principles 260 can be applied to enterprises, sites, and MANETs of any size or 261 shape. 263 VET link 264 a virtual link that uses automatic tunneling to create an overlay 265 network that spans an enterprise network routing region. VET 266 links can be segmented (e.g., by filtering gateways) into multiple 267 distinct segments that can be joined together by bridges or IP 268 routers the same as for any link. Bridging would view the 269 multiple (bridged) segments as a single VET link, whereas IP 270 routing would view the multiple segments as multiple distinct VET 271 links. VET links can further be partitioned into multiple logical 272 areas, where each area is identified by a distinct set of border 273 nodes. 275 VET links configured over non-multicast enterprise networks 276 support only Non-Broadcast, Multiple Access (NBMA) services; VET 277 links configured over enterprise networks that support multicast 278 can support both NBMA and native multicast services. 280 Enterprise Router (ER) 281 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 282 mobile router that comprises a router function, a host function, 283 one or more enterprise-interior interfaces, and zero or more 284 internal virtual, enterprise-edge, provider-edge, and VET 285 interfaces. At a minimum, an ER forwards outer IP packets over 286 one or more sets of enterprise-interior interfaces, where each set 287 connects to a distinct enterprise network. 289 VET Border Router (VBR) 290 an ER that connects edge networks to VET links and/or connects 291 multiple VET links together. A VBR is a tunnel endpoint router, 292 and it configures a separate VET interface for each distinct VET 293 link. All VBRs are also ERs. 295 VET Border Gateway (VBG) 296 a VBR that connects VET links to provider networks. A VBG may 297 alternately act as "half-gateway", and forward the packets it 298 receives from nodes on the VET link to another VBG on the same VET 299 link. a All VBGs are also VBRs. 301 VET host 302 any node (host or router) that configures a VET interface for 303 host-operation only. Note that a node may configure some of its 304 VET interfaces as host interfaces and others as router interfaces. 306 VET node 307 any node (host or router) that configures and uses a VET 308 interface. 310 enterprise-interior interface 311 an ER's attachment to a link within an enterprise network. 312 Packets sent over enterprise-interior interfaces may be forwarded 313 over multiple additional enterprise-interior interfaces within the 314 enterprise network before they reach either their final 315 destination or a border router/gateway. Enterprise-interior 316 interfaces connect laterally within the IP network hierarchy. 318 enterprise-edge interface 319 a VBR's attachment to a link (e.g., an Ethernet, a wireless 320 personal area network, etc.) on an arbitrarily complex edge 321 network that the VBR connects to a VET link and/or a provider 322 network. Enterprise-edge interfaces connect to lower levels 323 within the IP network hierarchy. 325 provider-edge interface 326 a VBR's attachment to the Internet or to a provider network via 327 which the Internet can be reached. Provider-edge interfaces 328 connect to higher levels within the IP network hierarchy. 330 internal-virtual interface 331 an interface that is internal to a VET node and does not in itself 332 directly attach to a tangible link, e.g., a loopback interface. 334 VET interface 335 a VET node's attachment to a VET link. VET nodes configure each 336 VET interface over a set of underlying enterprise-interior 337 interfaces that connect to a routing region spanned by a single 338 VET link. When there are multiple distinct VET links (each with 339 their own distinct set of underlying interfaces), the VET node 340 configures a separate VET interface for each link. 342 The VET interface encapsulates each inner packet in any mid-layer 343 headers followed by an outer IP header, then forwards the packet 344 on an underlying interface such that the Time to Live (TTL) - Hop 345 Limit in the inner header is not decremented as the packet 346 traverses the link. The VET interface therefore presents an 347 automatic tunneling abstraction that represents the VET link as a 348 single hop to the inner network layer. 350 Provider Aggregated (PA) prefix 351 a network layer protocol prefix that is delegated to a VET node by 352 a provider network. 354 Provider-(In)dependent (PI) address/prefix 355 a network layer protocol prefix that is delegated to a VET node by 356 an independent prefix registration authority. 358 Routing Locator (RLOC) 359 a public-scope or enterprise-local-scope IP address that can 360 appear in enterprise-interior and/or interdomain routing tables. 361 Public-scope RLOCs are delegated to specific enterprise networks 362 and routable within both the enterprise-interior and interdomain 363 routing regions. Enterprise-local-scope RLOCs (e.g., IPv6 Unique 364 Local Addresses [RFC4193], IPv4 privacy addresses [RFC1918], etc.) 365 are self-generated by individual enterprise networks and routable 366 only within the enterprise-interior routing region. 368 ERs use RLOCs for operating the enterprise-interior routing 369 protocol and for next-hop determination in forwarding packets 370 addressed to other RLOCs. End systems can use RLOCs as addresses 371 for end-to-end communications between peers within the same 372 enterprise network. VET interfaces treat RLOCs as *outer* IP 373 addresses during encapsulation. 375 Endpoint Interface iDentifier (EID) 376 a public-scope network layer address that is routable within an 377 enterprise-edge or VET overlay network. EID prefixes are separate 378 and distinct from any RLOC prefix space, but are mapped to RLOC 379 addresses to support routing over VET interfaces. 381 VBRs participate in any EID-based routing instances and use EID 382 addresses for next-hop determination. End systems can use EIDs as 383 addresses for end-to-end communications between peers either 384 within the same enterprise network or within different enterprise 385 networks. VET interfaces treat EIDs as *inner* network layer 386 addresses during encapsulation. 388 Note that an EID can also be used as an *outer* network layer 389 address if there are nested encapsulations. In that case, the EID 390 would appear as an RLOC to the innermost encapsulation. 392 The following additional acronyms are used throughout the document: 394 CGA - Cryptographically Generated Address 395 DHCP(v4, v6) - Dynamic Host Configuration Protocol 396 ECMP - Equal Cost Multi Path 397 FIB - Forwarding Information Base 398 ICMP - either ICMPv4 or ICMPv6 399 IP - either IPv4 or IPv6 400 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 401 NBMA - Non-Broadcast, Multiple Access 402 ND - Neighbor Discovery 403 PIO - Prefix Information Option 404 PRL - Potential Router List 405 PRLNAME - Identifying name for the PRL 406 RIB - Routing Information Base 407 RIO - Route Information Option 408 RPF - Reverse Path Forwarding 409 SCMP - SEAL Control Message Protocol 410 SEAL - Subnetwork Encapsulation and Adaptation Layer 411 SLAAC - IPv6 StateLess Address AutoConfiguration 412 SNS/SNA - SEAL Neighbor Solicitation/Advertisement 413 SRS/SRA - SEAL Router Solicitation/Advertisement 415 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 416 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 417 document are to be interpreted as described in [RFC2119]. When used 418 in lower case (e.g., must, must not, etc.), these words MUST NOT be 419 interpreted as described in [RFC2119], but are rather interpreted as 420 they would be in common English. 422 3. Enterprise Network Characteristics 424 Enterprise networks consist of links that are connected by Enterprise 425 Routers (ERs) as depicted in Figure 1. ERs typically participate in 426 a routing protocol over enterprise-interior interfaces to discover 427 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 428 VET Border Routers (VBRs) are ERs that connect edge networks to VET 429 links that span enterprise networks. VET Border Gateways (VBGs) are 430 VBRs that connect VET links to provider networks. 432 Conceptually, an ER embodies both a host function and router 433 function, and supports communications according to the weak end- 434 system model [RFC1122]. The router function engages in the 435 enterprise-interior routing protocol on its enterprise-interior 436 interfaces, connects any of the ER's edge networks to its VET links, 437 and may also connect the VET links to provider networks (see 438 Figure 1). The host function typically supports network management 439 applications, but may also support diverse applications typically 440 associated with general-purpose computing platforms. 442 An enterprise network may be as simple as a small collection of ERs 443 and their attached edge networks; an enterprise network may also 444 contain other enterprise networks and/or be a subnetwork of a larger 445 enterprise network. An enterprise network may further encompass a 446 set of branch offices and/or nomadic hosts connected to a home office 447 over one or several service providers, e.g., through Virtual Private 448 Network (VPN) tunnels. Finally, an enterprise network may contain 449 many internal partitions that are logical or physical groupings of 450 nodes for the purpose of load balancing, organizational separation, 451 etc. In that case, each internal partition resembles an individual 452 segment of a bridged LAN. 454 Enterprise networks that comprise link types with sufficiently 455 similar properties (e.g., Layer 2 (L2) address formats, maximum 456 transmission units (MTUs), etc.) can configure a subnetwork routing 457 service such that the inner network layer sees the underlying network 458 as an ordinary shared link the same as for a (bridged) campus LAN 459 (this is often the case with large cellular operator networks). In 460 that case, a single inner network layer hop is sufficient to traverse 461 the underlying network. Enterprise networks that comprise link types 462 with diverse properties and/or configure multiple IP subnets must 463 also provide an enterprise-interior routing service that operates as 464 an IP layer mechanism. In that case, multiple inner network layer 465 hops may be necessary to traverse the underlying network such that 466 care must be taken to avoid multi-link subnet issues [RFC4903]. 468 In addition to other interface types, VET nodes configure VET 469 interfaces that view all other nodes on the VET link as neighbors on 470 a virtual NBMA link. VET nodes configure a separate VET interface 471 for each distinct VET link to which they connect, and discover other 472 nodes on the link that can be used for forwarding packets to off-link 473 destinations. 475 For each distinct VET link , a trust basis must be established and 476 consistently applied. For example, for VET links configured over 477 enterprise networks in which VBRs establish symmetric security 478 associations, mechanisms such as IPsec [RFC4301] can be used to 479 assure authentication and confidentiality. In other enterprise 480 network scenarios, asymmetric securing mechanisms such as SEcure 481 Neighbor Discovery (SEND) [RFC3971] may be necessary. Still other 482 enterprise networks may find it sufficient to employ additional 483 encapsulations (e.g., SEAL [I-D.templin-intarea-seal]) that include a 484 simple per-packet nonce to detect off-path attacks. 486 Finally, for VET links configured over enterprise networks with a 487 centralized management structure (e.g., a corporate campus network, 488 an ISP network, etc.), a hybrid routing/mapping service can be 489 deployed using a synchronized set of VBGs. In that case, the VBGs 490 can provide a "default mapper" [I-D.jen-apt] service used for short- 491 term packet forwarding until route-optimized paths can be 492 established. For VET links configured over enterprise networks with 493 a distributed management structure (e.g., disconnected MANETs), peer- 494 to-peer coordination between the VET nodes themselves without the 495 assistance of VBGs may be required. Recognizing that various use 496 cases will entail a continuum between a fully centralized and fully 497 distributed approach, the following sections present the mechanisms 498 of Virtual Enterprise Traversal as they apply to a wide variety of 499 scenarios. 501 4. Autoconfiguration 503 ERs, VBRs, VBGs, and VET hosts configure themselves for operation as 504 specified in the following subsections. 506 4.1. Enterprise Router (ER) Autoconfiguration 508 ERs configure enterprise-interior interfaces and engage in any 509 routing protocols over those interfaces. 511 When an ER joins an enterprise network, it first configures an IPv6 512 link-local address on each enterprise-interior interface that 513 requires an IPv6 link-local capability and configures an IPv4 link- 514 local address on each enterprise-interior interface that requires an 515 IPv4 link-local capability. IPv6 link-local address generation 516 mechanisms include Cryptographically Generated Addresses (CGAs) 517 [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 518 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 519 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 520 provide an IPv4 link-local address generation capability. 522 Next, the ER configures one or more RLOCs and engages in any routing 523 protocols on its enterprise-interior interfaces. The ER can 524 configure RLOCs via administrative configuration, DHCP 525 autoconfiguration, pseudo-random self-generation from a suitably 526 large address pool, or through an alternate autoconfiguration 527 mechanism. 529 Alternatively (or in addition), the ER can request RLOC prefix 530 delegations via an automated prefix delegation exchange over an 531 enterprise-interior interface and can assign the prefix(es) on 532 enterprise-edge interfaces. Note that in some cases, the same 533 enterprise-edge interfaces may assign both RLOC and EID addresses if 534 there is a means for source address selection. In other cases (e.g., 535 for separation of security domains), RLOCs and EIDs are assigned on 536 separate sets of enterprise-edge interfaces. 538 Pseudo-random self-generation of IPv6 RLOCs can be from a large 539 public or local-use IPv6 address range (e.g., IPv6 Unique Local 540 Addresses [RFC4193]). Pseudo-random self-generation of IPv4 RLOCs 541 can be from a large public or local-use IPv4 address range (e.g., 542 [RFC1918]). When self-generation is used alone, the ER continuously 543 monitors the RLOCs for uniqueness, e.g., by monitoring the 544 enterprise-interior routing protocol. (Note however that anycast 545 RLOCs MAY be assigned to multiple enterprise-interior interfaces; 546 hence, monitoring for uniqueness applies only to RLOCs that are 547 intended as unicast.) 549 DHCP generation of RLOCs uses standard DHCP procedures but may 550 require support from relays within the enterprise network. For 551 DHCPv6, relays that do not already know the RLOC of a server within 552 the enterprise network forward requests to the 'All_DHCP_Servers' 553 site-scoped IPv6 multicast group [RFC3315]. For DHCPv4, relays that 554 do not already know the RLOC of a server within an enterprise network 555 that supports multicast forward requests to the site-scoped IPv4 556 multicast group address 'All_DHCPv4_Servers', which SHOULD be set to 557 239.255.2.1 unless an alternate multicast group for the site is 558 known. DHCPv4 servers that delegate RLOCs SHOULD therefore join the 559 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 560 received for that group. 562 A combined approach using both DHCP and self-generation is also 563 possible when the ER configures both a DHCP client and relay that are 564 connected, e.g., via a pair of back-to-back connected Ethernet 565 interfaces, a tun/tap interface, a loopback interface, inter-process 566 communication, etc. The ER first self-generates an RLOC taken from a 567 temporary addressing range used only for the bootstrapping purpose of 568 procuring an actual RLOC taken from a delegated addressing range. 569 The ER then engages in the enterprise-interior routing protocol and 570 discovers a list of VBGs that provide DHCP services (see: Section 571 4.2.1). Next, the ER performs a DHCP exchange with a server using 572 the temporary RLOC as the address of its relay function. When the 573 DHCP server delegates an actual RLOC address/prefix, the ER abandons 574 the temporary RLOC and re-engages in the enterprise-interior routing 575 protocol using an RLOC taken from the delegation. 577 In some enterprise network use cases (e.g., MANETs), assignment of 578 RLOCs on enterprise-interior interfaces as singleton addresses (i.e., 579 as addresses with /32 prefix lengths for IPv4, or as addresses with 580 /128 prefix lengths for IPv6) MAY be necessary to avoid multi-link 581 subnet issues. 583 4.2. VET Border Router (VBR) Autoconfiguration 585 VBRs are ERs that configure a VET interface for each VET link that 586 spans a distinct sets of underlying interfaces belonging to the same 587 enterprise network; a VBR can connect to multiple VET links, in which 588 case it would configure multiple VET interfaces. In addition to the 589 ER autoconfiguration procedures specified in Section 4.1, VBRs 590 perform the following autoconfiguration operations. 592 4.2.1. VET Interface Initialization 594 VBRs configure a VET interface for each VET link that spans a set of 595 underlying interfaces belonging to the same enterprise network such 596 that all other nodes on the VET link appear as single-hop neighbors 597 from the standpoint of the inner network layer protocol through the 598 use of encapsulation. 600 After the VBR configures a VET interface, it associates one or more 601 RLOCs with the interface to serve as the source addresses for outer 602 IP packets to be sent over underlying interfaces. The VBR then 603 assigns link-local addresses to the interface if necessary. When 604 IPv6 and IPv4 are used as the inner/outer protocols (respectively), 605 the VBR can autoconfigure an IPv6 link-local address on the VET 606 interface using a modified EUI-64 interface identifier based on an 607 IPv4 RLOC address (see Section 2.2.1 of [RFC5342]). Link-local 608 address configuration for other inner/outer protocol combinations is 609 through administrative configuration, random self-generation (e.g., 610 [RFC4941], etc.) or through an unspecified alternate method. 612 The VBR next discovers a Potential Router List (PRL) for the VET link 613 that includes the RLOC addresses of VBGs. The PRL can be discovered 614 through administrative configuration, information conveyed in the 615 enterprise-interior routing protocol, an anycast VBG discovery 616 message exchange, a DHCP option, etc. In multicast-capable 617 enterprise networks, VBRs can also listen for advertisements on the 618 'rasadv' [RASADV] multicast group address. 620 When no other information is available, the VBR can resolve an 621 identifying name for the PRL ('PRLNAME') formed as 622 'hostname.domainname', where 'hostname' is an enterprise-specific 623 name string and 'domainname' is an enterprise-specific Domain Name 624 System (DNS) suffix [RFC1035]. The VBR discovers 'PRLNAME' through 625 administrative configuration, the DHCP Domain Name option [RFC2132], 626 'rasadv' protocol advertisements, link-layer information (e.g., an 627 IEEE 802.11 Service Set Identifier (SSID)), or through some other 628 means specific to the enterprise network. The VBR can also obtain 629 'PRLNAME' as part of an arrangement with a private-sector PI prefix 630 vendor (see: Section 4.2.3). 632 In the absence of other information, the VBR sets the 'hostname' 633 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 634 component to an enterprise-specific DNS suffix (e.g., "example.com"). 635 Isolated enterprise networks that do not connect to the outside world 636 may have no enterprise-specific DNS suffix, in which case the 637 'PRLNAME' consists only of the 'hostname' component. (Note that the 638 default hostname "isatapv2" is intentionally distinct from the 639 convention specified in [RFC5214].) 641 After discovering 'PRLNAME', the VBR resolves the name into a list of 642 RLOC addresses through a name service lookup. For centrally managed 643 enterprise networks, the VBR resolves 'PRLNAME' using an enterprise- 644 local name service (e.g., the DNS). For enterprises with no 645 centralized management structure, the VBR resolves 'PRLNAME' using 646 Link-Local Multicast Name Resolution (LLMNR) [RFC4795] over the VET 647 interface. In that case, all VBGs in the PRL respond to the LLMNR 648 query, and the VBR accepts the union of all responses. 650 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 652 VBRs that connect their enterprise networks to a provider network 653 obtain Provider-Aggregated (PA) EID prefixes through stateful and/or 654 stateless autoconfiguration mechanisms. The stateful and stateless 655 approaches are discussed in the following subsections. 657 4.2.2.1. Stateful Prefix Delegation 659 For IPv4, VBRs acquire IPv4 PA EID prefixes through administrative 660 configuration, an automated IPv4 prefix delegation exchange, etc. 662 For IPv6, VBRs acquire IPv6 PA EID prefixes through administrative 663 configuration or through DHCPv6 Prefix Delegation exchanges with an 664 VBG acting as a DHCP relay/server. In particular, the VBR (acting as 665 a requesting router) can use DHCPv6 prefix delegation [RFC3633] over 666 the VET interface to obtain prefixes from the VBG (acting as a 667 delegating router). The VBR obtains prefixes using either a 668 2-message or 4-message DHCPv6 exchange [RFC3315]. For example, to 669 perform the 2-message exchange, the VBR's DHCPv6 client forwards a 670 Solicit message with an IA_PD option to its DHCPv6 relay, i.e., the 671 VBR acts as a combined client/relay (see Section 4.1). The relay 672 then forwards the message over the VET interface using VET 673 encapsulation (see: Section 5.4) to a VBG which either services the 674 request or relays it further. The forwarded Solicit message will 675 elicit a reply from the server containing prefix delegations. The 676 VBR can also propose a specific prefix to the DHCPv6 server per 677 Section 7 of [RFC3633]. The server will check the proposed prefix 678 for consistency and uniqueness, then return it in the reply to the 679 VBR if it was able to perform the delegation. 681 After the VBR receives IPv4 and/or IPv6 prefix delegations, it can 682 provision the prefixes on enterprise-edge interfaces as well as on 683 other VET interfaces configured over child enterprise networks for 684 which it acts as an VBG. The VBR can also provision the prefixes on 685 enterprise-interior interfaces to service any hosts attached to the 686 link. 688 The prefix delegations remain active as long as the VBR continues to 689 renew them via the delegating VBG before lease lifetimes expire. The 690 lease lifetime also keeps the delegation state active even if 691 communications between the VBR and delegating VBG are disrupted for a 692 period of time (e.g., due to an enterprise network partition, power 693 failure, etc.). Note however that if the VBR abandons or otherwise 694 loses continuity with the prefixes, it may be obliged to perform 695 network-wide renumbering if it subsequently receives a new and 696 different set of prefixes. 698 Stateful prefix delegation for non-IP protocols is out of scope. 700 4.2.2.2. Stateless Prefix Delegation 702 When IPv6 and IPv4 are used as the inner and outer protocols, 703 respectively, a stateless IPv6 PA prefix delegation capability is 704 available using the mechanisms specified in [RFC5569][RFC5969]. VBRs 705 can use these mechanisms to statelessly configure IPv6 PA prefixes 706 that embed one of the VBR's IPv4 RLOCs. 708 Using this stateless prefix delegation, if the IPv4 RLOC changes the 709 IPv6 prefix also changes and the VBR is obliged to renumber any 710 interfaces on which sub-prefixes from the delegated prefix are 711 assigned. This method may therefore be most suitable for enterprise 712 networks in which IPv4 RLOC assignments rarely change, or in 713 enterprise networks in which only services that do not depend on a 714 long-term stable IPv6 prefix (e.g., client-side web browsing) are 715 used. 717 Stateless prefix delegation for other protocol combinations is out of 718 scope. 720 4.2.3. Provider-(In)dependent (PI) EID Prefix Autoconfiguration 722 VBRs can acquire Provider (In)dependent (PI) prefixes to facilitate 723 multihoming, mobility and traffic engineering without requiring site- 724 wide renumbering events. These PI prefixes are made available to 725 VBRs through a prefix registration authority that may or may not be 726 associated with a specific ISP. 728 VBRs that connect major enterprise networks (e.g., large 729 corporations, academic campuses, ISP networks, etc.) to a parent 730 enterprise network and/or the global Internet can acquire short PI 731 prefixes (e.g., an IPv6 ::/20, an IPv4 /16, etc.) through a 732 registration authority such as the Internet Assigned Numbers 733 Authority (IANA) or a major regional Internet registry. VBRs that 734 connect small enterprise networks (e.g., SOHO networks, MANETs, etc.) 735 to a parent enterprise network can acquire longer PI prefixes through 736 arrangements with a PI prefix commercial vendor organization. 738 After a VBR receives PI prefixes, it can sub-delegate portions of the 739 prefixes on enterprise-edge interfaces, on other VET interfaces for 740 which it is configured as a VBG and on enterprise-interior interfaces 741 to service any hosts attached to the link. The VBR can also sub- 742 delegate portions of its PI prefixes to requesting routers connected 743 to child enterprise networks. These requesting routers consider 744 their sub-delegated portions of the PI prefix as PA, and consider the 745 delegating routers as their points of connection to a provider 746 network. 748 4.3. VET Border Gateway (VBG) Autoconfiguration 750 VBGs are VBRs that connect VET links configured over child enterprise 751 networks to provider networks via provider-edge interfaces and/or via 752 VET links configured over parent enterprise networks. A VBG may also 753 act as a "half-gateway", in that it may need to forward the packets 754 it receives from nodes on the VET link via another VBG connected to 755 the same VET link. This arrangement is seen in the IRON 756 [I-D.templin-iron] client/server/relay architecture, in which a 757 server "half-gateway" is a VBG that forwards packets with off-link 758 destinations via a relay "half-gateway" VBG that connects the VET 759 link to the provider network. 761 VBGs autoconfigure their provider-edge interfaces in a manner that is 762 specific to the provider connections, and they autoconfigure their 763 VET interfaces that were configured over parent VET links using the 764 VBR autoconfiguration procedures specified in Section 4.2. For each 765 of its VET interfaces connected to child VET links, the VBG 766 initializes the interface the same as for an ordinary VBR (see 767 Section 4.2.1). It then arranges to add one or more of its RLOCs 768 associated with the child VET link to the PRL. 770 VBGs configure a DHCP relay/server on VET interfaces connected to 771 child VET links that require DHCP services. VBGs may also engage in 772 an unspecified anycast VBG discovery message exchange if they are 773 configured to do so. Finally, VBGs respond to LLMNR queries for 774 'PRLNAME' on VET interfaces connected to VET links that span child 775 enterprise networks with a distributed management structure. 777 4.4. VET Host Autoconfiguration 779 Nodes that cannot be attached via a VBR's enterprise-edge interface 780 (e.g., nomadic laptops that connect to a home office via a Virtual 781 Private Network (VPN)) can instead be configured for operation as a 782 simple host with a VET interface. Such VET hosts perform the same 783 VET interface initialization and VBG discovery procedures as 784 specified for VBRs in Section 4.2.1, but they configure their VET 785 interfaces as host interfaces (and not router interfaces). Note also 786 that a node may be configured as a host on some VET interfaces and as 787 an VBR/VBG on other VET interfaces. 789 A VET host may receive non-link-local addresses and/or prefixes to 790 assign to the VET interface via DHCP exchanges and/or through 791 information conveyed in Router Advertisements (RAs). If prefixes are 792 provided, however, there must be assurance that either 1) the VET 793 link will not partition, or 2) that each VET host interface connected 794 to the VET link will configure a unique set of prefixes. VET hosts 795 therefore depend on DHCP and/or RA exchanges to provide only 796 addresses/prefixes that are appropriate for assignment to the VET 797 interface according to these specific cases, and depend on the VBGs 798 within the enterprise keeping track of which addresses/prefixes were 799 assigned to which hosts. 801 When the VET host solicits a DHCP-assigned EID address/prefix over a 802 (non-multicast) VET interface, it maps the DHCP relay/server 803 multicast inner destination address to the outer RLOC address of an 804 VBG that it has selected as a default router. The VET host then 805 assigns any resulting DHCP-delegated addresses/prefixes to the VET 806 interface for use as the source address of inner packets. The host 807 will subsequently send all packets destined to EID correspondents via 808 a default router on the VET link, and will discover more-specific 809 routes based on any redirect messages it receives. 811 5. Internetworking Operation 813 Following the autoconfiguration procedures specified in Section 4, 814 ERs, VBRs, VBGs, and VET hosts engage in normal internetworking 815 operations as discussed in the following sections. 817 5.1. Routing Protocol Participation 819 ERs engage in any RLOC-based routing protocols over enterprise- 820 interior interfaces to exchange routing information for forwarding IP 821 packets with RLOC addresses. VBRs and VBGs can additionally engage 822 in any EID-based routing protocols over VET, enterprise-edge and 823 provider-edge interfaces to exchange routing information for 824 forwarding inner network layer packets with EID addresses. Note that 825 any EID-based routing instances are separate and distinct from any 826 RLOC-based routing instances. 828 Routing protocol participation on non-multicast VET interfaces uses 829 the NBMA interface model, e.g., in the same manner as for OSPF over 830 NBMA interfaces [RFC5340], while routing protocol participation on 831 multicast-capable VET interfaces can alternatively use the standard 832 multicast interface model. VBRs can use the list of VBGs in the PRL 833 (see: Section 4.2.1) as an initial list of neighbors for EID-based 834 routing protocol participation. 836 VBRs can alternatively use the list of VBGs as potential default 837 routers instead of engaging in an EID-based routing protocol 838 instance. In that case, when the VBR forwards a packet via a default 839 router it may receive a redirect message indicating a different VBR 840 as a better next hop. 842 5.1.1. PI Prefix Routing Considerations 844 VBRs that connect large enterprise networks to the global Internet 845 advertise their EID PI prefixes directly into the Internet default- 846 free RIB via the Border Gateway Protocol (BGP) [RFC4271] the same as 847 for a major service provider network. VBRs that connect large 848 enterprise networks to provider networks can instead advertise their 849 EID PI prefixes into the providers' routing system(s) if the provider 850 networks are configured to accept them. 852 VBRs that connect small enterprise networks to provider networks 853 obtain one or more PI prefixes and register the prefixes with a 854 serving VBG in the PI prefix vendor's network (e.g., through a 855 vendor-specific short http(s) transaction). The PI prefix vendor 856 network then acts as a virtual "home" enterprise network that 857 connects its customer small enterprise networks to the Internet 858 routing system. The customer small enterprise networks in turn 859 appear as mobile components of the PI prefix vendor's network, i.e., 860 the customer networks are always "away from home". 862 Further details on routing for PI prefixes is discussed in "The 863 Internet Routing Overlay Network (IRON)" [I-D.templin-iron] and "Fib 864 Suppression with Virtual Aggregation" [I-D.ietf-grow-va]. 866 5.2. Default Route Configuration and Selection 868 Configuration of default routes in the presence of VET interfaces 869 must be carefully coordinated according to the inner and outer 870 network protocols. If the inner and outer protocols are different 871 (e.g., IPv6 within IPv4) then default routes of the inner protocol 872 version can be configured with next-hops corresponding to default 873 routers on a VET interface while default routes of the outer protocol 874 version can be configured with next-hops corresponding to default 875 routers on an underlying interface. 877 If the inner and outer protocols are the same (e.g., IPv4 within 878 IPv4), care must be taken in setting the default route to avoid 879 ambiguity. For example, if default routes are configured on the VET 880 interface then more-specific routes could be configured on underlying 881 interfaces to avoid looping. In a preferred method, however, 882 multiple default routes can be configured with some having next-hops 883 corresponding to (EID-based) default routers on VET interfaces and 884 others having next-hops corresponding to (RLOC-based) default routers 885 on underlying interfaces. In that case, special next-hop 886 determination rules must be used (see: Section 5.4). 888 5.3. Address Selection 890 When permitted by policy and supported by enterprise-interior 891 routing, VET nodes can avoid encapsulation through communications 892 that directly invoke the outer IP protocol using RLOC addresses 893 instead of EID addresses for end-to-end communications. For example, 894 an enterprise network that provides native IPv4 intra-enterprise 895 services can provide continued support for native IPv4 communications 896 even when encapsulated IPv6 services are available for inter- 897 enterprise communications. In other enterprise network scenarios, 898 the use of EID-based communications (i.e., instead of RLOC-based 899 communications) may be necessary and/or beneficial to support address 900 scaling, transparent NAT traversal, security domain separation, site 901 multihoming, traffic engineering, etc. . 903 VET nodes can use source address selection rules (e.g., based on name 904 service information) to determine whether to use EID-based or RLOC- 905 based addressing. The remainder of this section discusses 906 internetworking operation for EID-based communications using the VET 907 interface abstraction. 909 5.4. Next Hop Determination 911 VET nodes perform normal next-hop determination via longest prefix 912 match, and send packets according to the most-specific matching entry 913 in the FIB. If the FIB entry has multiple next-hop addresses, the 914 VBR selects the next-hop with the best metric value. If multiple 915 next hops have the same metric value, the VET node can use Equal Cost 916 Multi Path (ECMP) to forward different flows via different next-hop 917 addresses, where flows are determined, e.g., by computing a hash of 918 the inner packet's source address, destination address and flow label 919 fields. 921 If the VET node has multiple default routes of the same inner and 922 outer protocol versions, with some corresponding to EID-based default 923 routers and others corresponding to RLOC-based default routers, it 924 must perform source address based selection of a default route. In 925 particular, if the packet's source address is taken from an EID 926 prefix the VET node selects a default route configured over the VET 927 interface; otherwise, it selects a default route configured over an 928 underlying interface. 930 As a last resort when there is no matching entry in the FIB (i.e., 931 not even default), VET nodes can discover next-hop addresses within 932 the enterprise network through on-demand name service queries for the 933 EID prefix taken from a packet's destination address (or, by some 934 other inner address to outer address mapping mechanism). For 935 example, for the IPv6 destination address '2001:DB8:1:2::1' and 936 'PRLNAME' "isatapv2.example.com" the VET node can perform a name 937 service lookup for the domain name: 938 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 940 Name-service lookups in enterprise networks with a centralized 941 management structure use an infrastructure-based service, e.g., an 942 enterprise-local DNS. Name-service lookups in enterprise networks 943 with a distributed management structure and/or that lack an 944 infrastructure-based name service instead use LLMNR over the VET 945 interface. When LLMNR is used, the VBR that performs the lookup 946 sends an LLMNR query (with the prefix taken from the IP destination 947 address encoded in dotted-nibble format as shown above) and accepts 948 the union of all replies it receives from other VBRs on the VET 949 interface. When a VBR receives an LLMNR query, it responds to the 950 query IFF it aggregates an IP prefix that covers the prefix in the 951 query. If the name-service lookup succeeds, it will return RLOC 952 addresses (e.g., in DNS A records) that correspond to next-hop VBRs 953 to which the VET node can forward packets. 955 5.5. VET Interface Encapsulation/Decapsulation 957 VET interfaces encapsulate inner network layer packets in any 958 necessary mid-layer headers and trailers (e.g., IPsec [RFC4301], 959 etc.) followed by a SEAL header (if necessary) followed by an outer 960 UDP header (if necessary) followed by an outer IP header. Following 961 all encapsulations, the VET interface submits the encapsulated packet 962 to the outer IP forwarding engine for transmission on an underlying 963 interface. The following sections provide further details on 964 encapsulation: 966 5.5.1. Inner Network Layer Protocol 968 The inner network layer protocol sees the VET interface as an 969 ordinary network interface, and views the outer network layer 970 protocol as an L2 transport. The inner- and outer network layer 971 protocol types are mutually independent and can be used in any 972 combination. Inner network layer protocol types include IPv6 973 [RFC2460] and IPv4 [RFC0791], but they may also include non-IP 974 protocols such as OSI/CLNP [RFC0994][RFC1070][RFC4548]. 976 5.5.2. Mid-Layer Encapsulation 978 VET interfaces that use mid-layer encapsulations encapsulate each 979 inner network layer packet in any mid-layer headers and trailers as 980 the first step in a potentially multi-layer encapsulation. 982 5.5.3. SEAL Encapsulation 984 Following any mid-layer encapsulations, VET interfaces that use SEAL 985 add a SEAL header as specified in [I-D.templin-intarea-seal]. 986 Inclusion of a SEAL header MUST be applied uniformly between all 987 nodes on the VET link. Note that when a VET interface sends a SEAL- 988 encapsulated packet to a VET node that does not use SEAL 989 encapsulation, it may receive an ICMP "port unreachable" or "protocol 990 unreachable" depending on whether/not an outer UDP header is 991 included. 993 SEAL encapsulation is used on VET links that require path MTU 994 mitigations due to encapsulation overhead and/or mechanisms for VET 995 interface neighbor coordination. When SEAL encapsulation is used, 996 the VET interface sets the 'Next Header' value in the SEAL header to 997 the IP protocol number associated with either the mid-layer 998 encapsulation or the IP protocol number of the inner network layer 999 (if no mid-layer encapsulation is used). The VET interface sets the 1000 other fields in the SEAL header as specified in 1001 [I-D.templin-intarea-seal]. 1003 5.5.4. Outer UDP Header Encapsulation 1005 Following any mid-layer and/or SEAL encapsulations, VET interfaces 1006 that use UDP encapsulation add an outer UDP header. Inclusion of an 1007 outer UDP header must be applied uniformly between all nodes on the 1008 VET link. Note that when a VET interface sends a UDP-encapsulated 1009 packet to a node that does not recognize the UDP port number, it may 1010 receive an ICMP "port unreachable" message. 1012 VET interfaces use UDP encapsulation on VET links that may traverse 1013 Network Address Translators (NATs) and/or legacy networking gear 1014 (e.g., Equal Cost MultiPath (ECMP) routers, Link Aggregation Gateways 1015 (LAGs), etc.) that only recognize well-known network layer protocols. 1016 When UDP encapsulation is used, the VET interface encapsulates the 1017 mid-layer packet in an outer UDP header then sets the UDP port 1018 numbers as specified for the outermost mid-layer protocol (e.g., 1019 IPsec [RFC3947][RFC3948], etc.) When SEAL [I-D.templin-intarea-seal] 1020 is used as the outermost mid-layer protocol, the VET interface sets 1021 the UDP source port number to a hash calculated over the inner 1022 network layer {destination, source} values or (optionally) over the 1023 inner network layer {dest addr, source addr, protocol, dest port, 1024 source port} values. The VET interface uses a hash function of its 1025 own choosing, but it MUST be consistent in the manner in which the 1026 hash is applied.. 1028 For VET links configured over IPv4 enterprise networks, the VET 1029 interface sets the UDP checksum field to zero. For VET links 1030 configured over IPv6 enterprise networks, considerations for setting 1031 the UDP checksum are discussed in [I-D.ietf-6man-udpzero]. 1033 5.5.5. Outer IP Header Encapsulation 1035 Following any mid-layer, SEAL and/or UDP encapsulations, the VET 1036 interface adds an outer IP header. Outer IP header construction is 1037 the same as specified for ordinary IP encapsulation (e.g., [RFC2003], 1038 [RFC2473], [RFC4213], etc.) except that the "TTL/Hop Limit", "Type of 1039 Service/Traffic Class" and "Congestion Experienced" values in the 1040 inner network layer header are copied into the corresponding fields 1041 in the outer IP header. The VET interface also sets the IP protocol 1042 number to the appropriate value for the first protocol layer within 1043 the encapsulation (e.g., UDP, SEAL, IPsec, etc.). When IPv6 is used 1044 as the outer IP protocol, the VET interface sets the flow label value 1045 in the outer IPv6 header the same as described in 1046 [I-D.carpenter-flow-ecmp]. 1048 5.5.6. Decapsulation 1050 When a VET interface receives an encapsulated packet, it retains the 1051 outer headers and processes the SEAL header as specified in 1052 [I-D.templin-intarea-seal]. 1054 Next, if the packet will be forwarded from the receiving VET 1055 interface into a forwarding VET interface, the VET node copies the 1056 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 1057 Experienced" values in the outer IP header received on the receiving 1058 VET interface into the corresponding fields in the outer IP header to 1059 be sent over the forwarding VET interface (i.e., the values are 1060 transferred between outer headers and *not* copied from the inner 1061 network layer header). This is true even if the packet is forwarded 1062 out the same VET interface that it arrived on, and necessary to 1063 support diagnostic functions (e.g., traceroute) and avoid looping. 1065 During decapsulation, when the next-hop is via a non-VET interface, 1066 the "Congestion Experienced" value in the outer IP header is copied 1067 into the corresponding field in the inner network layer header. 1069 5.6. Mobility and Multihoming Considerations 1071 VBRs that travel between distinct enterprise networks must either 1072 abandon their PA prefixes that are relative to the "old" network and 1073 obtain PA prefixes relative to the "new" network, or somehow 1074 coordinate with a "home" network to retain ownership of the prefixes. 1075 In the first instance, the VBR would be required to coordinate a 1076 network renumbering event using the new PA prefixes 1077 [RFC4192][RFC5887]. In the second instance, an adjunct mobility 1078 management mechanism is required. 1080 VBRs can retain their PI prefixes as they travel between distinct 1081 network points of attachment as long as they continue to refresh 1082 their PI prefix to RLOC address mappings with their serving VBG as 1083 described in [I-D.templin-iron]. (When the VBR moves far from its 1084 serving VBG, it can also select a new VBG in order to maintain 1085 optimal routing.) In this way, VBRs can update their PI prefix to 1086 RLOC mappings in real time and without requiring an adjunct mobility 1087 management mechanism. 1089 The VBGs of a multihomed enterprise network participate in a private 1090 inner network layer routing protocol instance (e.g., via an interior 1091 BGP instance) to accommodate network partitions/merges as well as 1092 intra-enterprise mobility events. 1094 5.7. Neighbor Coordination on VET Interfaces using SEAL 1096 VET interfaces that use SEAL use the SEAL Control Message Protocol 1097 (SCMP) as specified in Section 4.5 of [I-D.templin-intarea-seal] to 1098 coordinate reachability, routing information, and mappings between 1099 the inner and outer network layer protocols. SCMP directly parallels 1100 the IPv6 Neighbor Discovery (ND) [RFC4191][RFC4861] and ICMPv6 1101 [RFC4443] protocols, but operates from within the tunnel and supports 1102 operation for any combinations of inner and outer network layer 1103 protocols. 1105 VET and SEAL are specifically designed for encapsulation of inner 1106 network layer payloads over outer IPv4 and IPv6 networks as a link 1107 layer. VET interfaces that use SCMP therefore require a new Source/ 1108 Target Link-Layer Address Option (S/TLLAO) format that encapsulates 1109 IPv4 addresses as shown in Figure 2 and IPv6 addresses as shown in 1110 Figure 3: 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Type = 2 | Length = 1 | Reserved | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | IPv4 address (bytes 0 thru 3) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 2: SCMP S/TLLAO Option for IPv4 RLOCs 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Type = 2 | Length = 3 | Reserved | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Reserved | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | IPv6 address (bytes 0 thru 3) | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | IPv6 address (bytes 4 thru 7) | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | IPv6 address (bytes 8 thru 11) | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | IPv6 address (bytes 12 thru 15) | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 Figure 3: SCMP S/TLLAO Option for IPv6 RLOCs 1140 In addition, VET interfaces that use SCMP use a modified version of 1141 the Route Information Option (RIO) (see: [RFC4191]) formatted as 1142 shown in Figure 4: 1144 0 1 2 3 1145 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 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Type = 24 | Length | Prefix Length | AF |Prf|Resvd| 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Route Lifetime | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Prefix (Variable Length) | 1152 . . 1153 . . 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 Figure 4: SCMP Route Information Option Format 1158 In this modified format, the VET interface sets the Route Lifetime 1159 and Prefix fields in the RIO option the same as specified in 1160 [RFC4191]. It then sets the fields in the header as follows: 1162 o the 'Type', 'Prf', and 'Resvd' fields are set the same as 1163 specified in [RFC4191]. 1165 o the 'Length' field is set to 1, 2, or 3 as specified in [RFC4191]. 1166 It is instead set to 4 if the 'Prefix Length' is greater than 128 1167 and set to 5 if the 'Prefix Length' is greater than 192 (e.g., in 1168 order to accommodate longer prefixes of non-IP protocols). 1170 o the 'Prefix Length' field ranges from 0 to 255. The 'Prefix' 1171 field is 0, 8, 16, 24 or 32 octets depending on the Length, and 1172 the embedded prefix MAY be up to 255 bits in length. 1174 o bits 24 - 26 are used to contain an 'Address Family (AF)' value 1175 that indicates the embedded prefix protocol type. This document 1176 defines the following values for AF: 1178 * 000 - IPv4 1180 * 001 - IPv6 1182 * 010 - OSI/CLNP NSAP 1184 The following subsections discuss VET interface neighbor coordination 1185 using SCMP: 1187 5.7.1. Router Discovery 1189 VET hosts and VBRs can send SCMP Router Solicitation (SRS) messages 1190 to one or more VBGs in the PRL to receive solicited SCMP Router 1191 Advertisements (SRAs). 1193 When an VBG receives an SRS message on a VET interface, it prepares a 1194 solicited SRA message. The SRA includes Router Lifetimes, Default 1195 Router Preferences, PIOs and any other options/parameters that the 1196 VBG is configured to include. If necessary, the VBG also includes 1197 Route Information Options (RIOs) formatted as specified above. 1199 The VBG finally includes one or more SLLAOs formatted as specified 1200 above that encode the IPv6 and/or IPv4 RLOC unicast addresses of its 1201 own enterprise-interior interfaces or the enterprise-interior 1202 interfaces of other nearby VBGs. 1204 5.7.2. Neighbor Unreachability Detection 1206 VET nodes perform Neighbor Unreachability Detection (NUD) on VET 1207 interface neighbors by monitoring hints of forward progress enabled 1208 by SEAL mechanisms as evidence that a neighbor is reachable. First, 1209 when data packets are flowing, the VET node can periodically set the 1210 A bit in the SEAL header of data packets to elicit SCMP responses 1211 from the neighbor. Secondly, when no data packets are flowing, the 1212 VET node can send periodic probes such as SCMP Neighbor Solicitation 1213 (SNS) messages for the same purpose. 1215 Responsiveness to routing changes is directly related to the delay in 1216 detecting that a neighbor has gone unreachable. In order to provide 1217 responsiveness comparable to dynamic routing protocols, a reasonably 1218 short neighbor reachable time (e.g., 5sec) SHOULD be used. 1220 Additionally, a VET node may receive outer IP ICMP "Destination 1221 Unreachable; net / host unreachable" messages from an ER on the path 1222 indicating that the path to a VET neighbor may be failing. The node 1223 SHOULD first check the packet-in-error to obtain reasonable assurance 1224 that the ICMP message is authentic. If the node receives excessive 1225 ICMP unreachable errors through multiple RLOCs associated with the 1226 same FIB entry, it SHOULD delete the FIB entry and allow subsequent 1227 packets to flow through a different route (e.g., a default route with 1228 a VBG as the next hop). 1230 5.7.3. Redirect Function 1232 A VET node (i.e., the redirectee) may receive a redirect message when 1233 it forwards packets over a VET interface to a neighboring VBR or VBG 1234 (i.e., the redirector). The redirector will forward the packet and 1235 return an SCMP Redirect message if necessary to inform the redirectee 1236 of a better next hop. 1238 The SCMP Redirect message is formatted the same as for ordinary 1239 ICMPv6 redirect messages (see Section 4.5 of [RFC4861]), except that 1240 the Destination and Target Address fields are unnecessary and 1241 therefore omitted. The format of the SCMP Redirect message is shown 1242 in Figure 5 1243 0 1 2 3 1244 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 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Type = 137 | Code = 0 | Checksum | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Reserved | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Options ... 1251 +-+-+-+-+-+-+-+-+-+-+-+- 1253 Figure 5: SCMP Redirect Message Format 1255 The redirector then adds any necessary Options to the Redirect 1256 message. It first includes one or more TLLAOs (see above) that 1257 include RLOCs corresponding to better next hops. The redirector next 1258 includes an RIO that contains a prefix from its FIB that covers the 1259 destination address of the original packet. 1261 Following the RIO option, the redirector includes any other necessary 1262 options (e.g., SEND options) followed by a Redirected Header option 1263 containing the leading portion of the packet that triggered the 1264 redirect as the final option in the message. The redirector then 1265 encapsulates the Redirect message the same as for any other SCMP 1266 message and sends it to the redirectee. 1268 When the redirectee receives the Redirect, it first authenticates the 1269 message then uses the EID prefix in the RIO with its respective 1270 lifetime to update its FIB. The redirectee also caches the IPv4 or 1271 IPv6 addresses in TLLAOs as the layer 2 addresses of potential next- 1272 hops for the prefix. 1274 The redirectee retains the FIB entry created as a result of receipt 1275 of an SCMP Redirect until the route lifetime expires, or until the 1276 redirected target neighbor becomes unreachable. In this way, RLOC 1277 liveness detection parallels IPv6 Neighbor Unreachability Detection. 1279 5.7.3.1. Correspondent Node Redirection 1281 When a mobile VET node moves to a new network point of attachment, it 1282 leaves short-term forwarding information with its former network 1283 point of attachment. Thereafter, any existing correspondents that 1284 attempt to contact the mobile node via the former network point of 1285 attachment will be redirected to the new network point of attachment. 1287 In this way, mobile VET nodes need not inform correspondents of a 1288 mobility event, since the correspondents will soon receive redirects 1289 from the network. 1291 5.8. Neighbor Coordination on VET Interfaces using IPsec 1293 VET interfaces that use IPsec encapsulation use the Internet Key 1294 Exchange protocol, version 2 (IKEv2) [RFC4306] to manage security 1295 association setup and maintenance. IKEv2 provides a logical 1296 equivalent of the SCMP in terms of VET interface neighbor 1297 coordinations; for example, IKEv2 also provides mechanisms for 1298 redirection [RFC5685] and mobility [RFC4555]. 1300 IPsec additionally provides an extended Identification field and 1301 integrity check vector; these features allow IPsec to utilize outer 1302 IP fragmentation and reassembly with less risk of exposure to data 1303 corruption due to reassembly misassociations. On the other hand, 1304 IPsec entails the use of symmetric security associations and hence 1305 may not be appropriate to all enterprise network use cases. 1307 5.9. Multicast 1309 5.9.1. Multicast over (Non)Multicast Enterprise Networks 1311 Whether or not the underlying enterprise network supports a native 1312 multicasting service, the VET node can act as an inner network layer 1313 IGMP/MLD proxy [RFC4605] on behalf of its attached edge networks and 1314 convey its multicast group memberships over the VET interface to a 1315 VBG acting as a multicast router. Its inner network layer multicast 1316 transmissions will therefore be encapsulated in outer headers with 1317 the unicast address of the VBG as the destination. 1319 5.9.2. Multicast Over Multicast-Capable Enterprise Networks 1321 In multicast-capable enterprise networks, ERs provide an enterprise- 1322 wide multicasting service (e.g., Simplified Multicast Forwarding 1323 (SMF) [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) 1324 routing, Distance Vector Multicast Routing Protocol (DVMRP) routing, 1325 etc.) over their enterprise-interior interfaces such that outer IP 1326 multicast messages of site-scope or greater scope will be propagated 1327 across the enterprise network. For such deployments, VET nodes can 1328 optionally provide a native inner multicast/broadcast capability over 1329 their VET interfaces through mapping of the inner multicast address 1330 space to the outer multicast address space. In that case, operation 1331 of link-or greater-scoped inner multicasting services (e.g., a link- 1332 scoped neighbor discovery protocol) over the VET interface is 1333 available, but should be used sparingly to minimize enterprise-wide 1334 flooding. 1336 VET nodes encapsulate inner multicast messages sent over the VET 1337 interface in any mid-layer headers (e.g., UDP, SEAL, IPsec, etc.) 1338 followed by an outer IP header with a site-scoped outer IP multicast 1339 address as the destination. For the case of IPv6 and IPv4 as the 1340 inner/outer protocols (respectively), [RFC2529] provides mappings 1341 from the IPv6 multicast address space to a site-scoped IPv4 multicast 1342 address space (for other encapsulations, mappings are established 1343 through administrative configuration or through an unspecified 1344 alternate static mapping). 1346 Multicast mapping for inner multicast groups over outer IP multicast 1347 groups can be accommodated, e.g., through VET interface snooping of 1348 inner multicast group membership and routing protocol control 1349 messages. To support inner-to-outer multicast address mapping, the 1350 VET interface acts as a virtual outer IP multicast host connected to 1351 its underlying interfaces. When the VET interface detects that an 1352 inner multicast group joins or leaves, it forwards corresponding 1353 outer IP multicast group membership reports on an underlying 1354 interface over which the VET interface is configured. If the VET 1355 node is configured as an outer IP multicast router on the underlying 1356 interfaces, the VET interface forwards locally looped-back group 1357 membership reports to the outer IP multicast routing process. If the 1358 VET node is configured as a simple outer IP multicast host, the VET 1359 interface instead forwards actual group membership reports (e.g., 1360 IGMP messages) directly over an underlying interface. 1362 Since inner multicast groups are mapped to site-scoped outer IP 1363 multicast groups, the VET node MUST ensure that the site-scoped outer 1364 IP multicast messages received on the underlying interfaces for one 1365 VET interface do not "leak out" to the underlying interfaces of 1366 another VET interface. This is accommodated through normal site- 1367 scoped outer IP multicast group filtering at enterprise network 1368 boundaries. 1370 5.10. Service Discovery 1372 VET nodes can perform enterprise-wide service discovery using a 1373 suitable name-to-address resolution service. Examples of flooding- 1374 based services include the use of LLMNR [RFC4795] over the VET 1375 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1376 over an underlying interface. More scalable and efficient service 1377 discovery mechanisms (e.g., anycast) are for further study. 1379 5.11. VET Link Partitioning 1381 A VET link can be partitioned into multiple distinct logical 1382 groupings. In that case, each partition configures its own distinct 1383 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1384 'isatapv2.zone2.example.com', etc.). 1386 VBGs can further create multiple IP subnets within a partition, e.g., 1387 by sending SRAs with PIOs containing different IP prefixes to 1388 different groups of VET hosts. VBGs can identify subnets, e.g., by 1389 examining RLOC prefixes, observing the enterprise-interior interfaces 1390 over which SRSs are received, etc. 1392 In the limiting case, VBGs can advertise a unique set of IP prefixes 1393 to each VET host such that each host belongs to a different subnet 1394 (or set of subnets) on the VET interface. 1396 5.12. VBG Prefix State Recovery 1398 VBGs retain explicit state that tracks the inner network layer 1399 prefixes delegated to VBRs connected to the VET link, e.g., so that 1400 packets are delivered to the correct VBRs. When a VBG loses some or 1401 all of its state (e.g., due to a power failure), client VBRs must 1402 refresh the VBG's state so that packets can be forwarded over correct 1403 routes. 1405 5.13. Support for Legacy ISATAP Services 1407 VBGs can support legacy ISATAP services according to the 1408 specifications in [RFC5214]. In particular, VBGs can configure 1409 legacy ISATAP interfaces and VET interfaces over the same sets of 1410 underlying interfaces as long as the PRLs and IPv6 prefixes 1411 associated with the ISATAP/VET interfaces are distinct. 1413 Legacy ISATAP hosts acquire addresses and/or prefixes in the same 1414 manner and using the same mechanisms as described for VET hosts in 1415 Section 4.4 above. 1417 6. IANA Considerations 1419 There are no IANA considerations for this document. 1421 7. Security Considerations 1423 Security considerations for MANETs are found in [RFC2501]. 1425 The security considerations found in 1426 [RFC2529][RFC5214][I-D.nakibly-v6ops-tunnel-loops] also apply to VET. 1428 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1429 where attacks on the neighbor coordination protocol are possible. 1430 SEAL [I-D.templin-intarea-seal] provides a per-packet identification 1431 that can be used to detect source address spoofing. 1433 Rogue neighbor coordination messages with spoofed RLOC source 1434 addresses can consume network resources and cause VET nodes to 1435 perform extra work. Nonetheless, VET nodes SHOULD NOT "blacklist" 1436 such RLOCs, as that may result in a denial of service to the RLOCs' 1437 legitimate owners. 1439 VBRs and VBGs observe the recommendations for network ingress 1440 filtering [RFC2827]. 1442 8. Related Work 1444 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1445 automatic tunneling in [RFC2529]; this concept was later called: 1446 "Virtual Ethernet" and investigated by Quang Nguyen under the 1447 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1448 their colleagues have motivated a number of foundational concepts on 1449 which this work is based. 1451 Telcordia has proposed DHCP-related solutions for MANETs through the 1452 CECOM MOSAIC program. 1454 The Naval Research Lab (NRL) Information Technology Division uses 1455 DHCP in their MANET research testbeds. 1457 Security concerns pertaining to tunneling mechanisms are discussed in 1458 [I-D.ietf-v6ops-tunnel-security-concerns]. 1460 Default router and prefix information options for DHCPv6 are 1461 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1463 An automated IPv4 prefix delegation mechanism is proposed in 1464 [I-D.ietf-dhc-subnet-alloc]. 1466 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1467 [I-D.clausen-manet-autoconf-recommendations]. 1469 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1471 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1472 decapsulation issues and other aspects of tunneling. 1474 Various proposals within the IETF have suggested similar mechanisms. 1476 9. Acknowledgements 1478 The following individuals gave direct and/or indirect input that was 1479 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Fred 1480 Baker, James Bound, Scott Brim, Brian Carpenter, Thomas Clausen, 1481 Claudiu Danilov, Chris Dearlove, Remi Despres, Gert Doering, Ralph 1482 Droms, Washam Fan, Dino Farinacci, Vince Fuller, Thomas Goff, David 1483 Green, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1484 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1485 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1486 Petrescu, Mark Smith, John Spence, Jinmei Tatuya, Dave Thaler, Mark 1487 Townsley, Ole Troan, Michaela Vanderveen, Robin Whittle, James 1488 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1489 working groups. Many others have provided guidance over the course 1490 of many years. 1492 10. Contributors 1494 The following individuals have contributed to this document: 1496 Eric Fleischman (eric.fleischman@boeing.com) 1497 Thomas Henderson (thomas.r.henderson@boeing.com) 1498 Steven Russert (steven.w.russert@boeing.com) 1499 Seung Yi (seung.yi@boeing.com) 1500 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1501 of the document. 1503 Jim Bound's foundational work on enterprise networks provided 1504 significant guidance for this effort. We mourn his loss and honor 1505 his contributions. 1507 11. References 1509 11.1. Normative References 1511 [I-D.templin-intarea-seal] 1512 Templin, F., "The Subnetwork Encapsulation and Adaptation 1513 Layer (SEAL)", draft-templin-intarea-seal-26 (work in 1514 progress), January 2011. 1516 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1517 September 1981. 1519 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1520 RFC 792, September 1981. 1522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1523 Requirement Levels", BCP 14, RFC 2119, March 1997. 1525 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1526 RFC 2131, March 1997. 1528 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1529 (IPv6) Specification", RFC 2460, December 1998. 1531 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1532 Defeating Denial of Service Attacks which employ IP Source 1533 Address Spoofing", BCP 38, RFC 2827, May 2000. 1535 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1536 and M. Carney, "Dynamic Host Configuration Protocol for 1537 IPv6 (DHCPv6)", RFC 3315, July 2003. 1539 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1540 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1541 December 2003. 1543 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1544 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1546 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1547 RFC 3972, March 2005. 1549 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1550 More-Specific Routes", RFC 4191, November 2005. 1552 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1553 Architecture", RFC 4291, February 2006. 1555 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1556 Message Protocol (ICMPv6) for the Internet Protocol 1557 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1559 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1560 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1561 September 2007. 1563 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1564 Address Autoconfiguration", RFC 4862, September 2007. 1566 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 1567 for IEEE 802 Parameters", BCP 141, RFC 5342, 1568 September 2008. 1570 11.2. Informative References 1572 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1573 Switching Networks", May 1974. 1575 [I-D.carpenter-flow-ecmp] 1576 Carpenter, B. and S. Amante, "Using the IPv6 flow label 1577 for equal cost multipath routing and link aggregation in 1578 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 1579 October 2010. 1581 [I-D.cheshire-dnsext-multicastdns] 1582 Cheshire, S. and M. Krochmal, "Multicast DNS", 1583 draft-cheshire-dnsext-multicastdns-13 (work in progress), 1584 January 2011. 1586 [I-D.clausen-manet-autoconf-recommendations] 1587 Clausen, T. and U. Herberg, "MANET Router Configuration 1588 Recommendations", 1589 draft-clausen-manet-autoconf-recommendations-00 (work in 1590 progress), February 2009. 1592 [I-D.clausen-manet-linktype] 1593 Clausen, T., "The MANET Link Type", 1594 draft-clausen-manet-linktype-00 (work in progress), 1595 October 2008. 1597 [I-D.droms-dhc-dhcpv6-default-router] 1598 Droms, R. and T. Narten, "Default Router and Prefix 1599 Advertisement Options for DHCPv6", 1600 draft-droms-dhc-dhcpv6-default-router-00 (work in 1601 progress), March 2009. 1603 [I-D.ietf-6man-udpzero] 1604 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 1605 Considerations", draft-ietf-6man-udpzero-02 (work in 1606 progress), October 2010. 1608 [I-D.ietf-dhc-subnet-alloc] 1609 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1610 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-11 1611 (work in progress), May 2010. 1613 [I-D.ietf-grow-va] 1614 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1615 L. Zhang, "FIB Suppression with Virtual Aggregation", 1616 draft-ietf-grow-va-03 (work in progress), August 2010. 1618 [I-D.ietf-lisp] 1619 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1620 "Locator/ID Separation Protocol (LISP)", 1621 draft-ietf-lisp-09 (work in progress), October 2010. 1623 [I-D.ietf-manet-smf] 1624 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1625 draft-ietf-manet-smf-10 (work in progress), March 2010. 1627 [I-D.ietf-v6ops-tunnel-security-concerns] 1628 Krishnan, S., Thaler, D., and J. Hoagland, "Security 1629 Concerns With IP Tunneling", 1630 draft-ietf-v6ops-tunnel-security-concerns-04 (work in 1631 progress), October 2010. 1633 [I-D.jen-apt] 1634 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1635 L. Zhang, "APT: A Practical Transit Mapping Service", 1636 draft-jen-apt-01 (work in progress), November 2007. 1638 [I-D.nakibly-v6ops-tunnel-loops] 1639 Nakibly, G. and F. Templin, "Routing Loop Attack using 1640 IPv6 Automatic Tunnels: Problem Statement and Proposed 1641 Mitigations", draft-nakibly-v6ops-tunnel-loops-03 (work in 1642 progress), August 2010. 1644 [I-D.russert-rangers] 1645 Russert, S., Fleischman, E., and F. Templin, "RANGER 1646 Scenarios", draft-russert-rangers-05 (work in progress), 1647 July 2010. 1649 [I-D.templin-iron] 1650 Templin, F., "The Internet Routing Overlay Network 1651 (IRON)", draft-templin-iron-17 (work in progress), 1652 January 2011. 1654 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1655 July 1978. 1657 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1658 Protocol Specification", October 2008. 1660 [RFC0994] International Organization for Standardization (ISO) and 1661 American National Standards Institute (ANSI), "Final text 1662 of DIS 8473, Protocol for Providing the Connectionless- 1663 mode Network Service", RFC 994, March 1986. 1665 [RFC1035] Mockapetris, P., "Domain names - implementation and 1666 specification", STD 13, RFC 1035, November 1987. 1668 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1669 a subnetwork for experimentation with the OSI network 1670 layer", RFC 1070, February 1989. 1672 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1673 Communication Layers", STD 3, RFC 1122, October 1989. 1675 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1676 Routing and Addressing Architecture", RFC 1753, 1677 December 1994. 1679 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1680 E. Lear, "Address Allocation for Private Internets", 1681 BCP 5, RFC 1918, February 1996. 1683 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1684 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1686 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1687 October 1996. 1689 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1690 Extensions", RFC 2132, March 1997. 1692 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1693 IPv6 Specification", RFC 2473, December 1998. 1695 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1696 over Non-Broadcast Multiple Access (NBMA) networks", 1697 RFC 2491, January 1999. 1699 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1700 (MANET): Routing Protocol Performance Issues and 1701 Evaluation Considerations", RFC 2501, January 1999. 1703 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1704 Domains without Explicit Tunnels", RFC 2529, March 1999. 1706 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1707 February 2000. 1709 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1710 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1711 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1712 RFC 3819, July 2004. 1714 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1715 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1716 May 2005. 1718 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1719 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1720 January 2005. 1722 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1723 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1724 RFC 3948, January 2005. 1726 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1727 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1728 September 2005. 1730 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1731 Addresses", RFC 4193, October 2005. 1733 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1734 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1736 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1737 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1739 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1740 Internet Protocol", RFC 4301, December 2005. 1742 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1743 RFC 4306, December 2005. 1745 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1746 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1747 May 2006. 1749 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1750 (MOBIKE)", RFC 4555, June 2006. 1752 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1753 "Internet Group Management Protocol (IGMP) / Multicast 1754 Listener Discovery (MLD)-Based Multicast Forwarding 1755 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1757 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1758 Multicast Name Resolution (LLMNR)", RFC 4795, 1759 January 2007. 1761 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1762 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1763 Focus", RFC 4852, April 2007. 1765 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1766 June 2007. 1768 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1769 Extensions for Stateless Address Autoconfiguration in 1770 IPv6", RFC 4941, September 2007. 1772 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1773 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1774 March 2008. 1776 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1777 for IPv6", RFC 5340, July 2008. 1779 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1780 Infrastructures (6rd)", RFC 5569, January 2010. 1782 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 1783 the Internet Key Exchange Protocol Version 2 (IKEv2)", 1784 RFC 5685, November 2009. 1786 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1787 Global Enterprise Recursion (RANGER)", RFC 5720, 1788 February 2010. 1790 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1791 Still Needs Work", RFC 5887, May 2010. 1793 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1794 Infrastructures (6rd) -- Protocol Specification", 1795 RFC 5969, August 2010. 1797 Appendix A. Duplicate Address Detection (DAD) Considerations 1799 A priori uniqueness determination (also known as "pre-service DAD") 1800 for an RLOC assigned on an enterprise-interior interface would 1801 require either flooding the entire enterprise network or somehow 1802 discovering a link in the network on which a node that configures a 1803 duplicate address is attached and performing a localized DAD exchange 1804 on that link. But, the control message overhead for such an 1805 enterprise-wide DAD would be substantial and prone to false-negatives 1806 due to packet loss and intermittent connectivity. An alternative to 1807 pre-service DAD is to autoconfigure pseudo-random RLOCs on 1808 enterprise-interior interfaces and employ a passive in-service DAD 1809 (e.g., one that monitors routing protocol messages for duplicate 1810 assignments). 1812 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1813 CGAs, IPv6 privacy addresses, etc. with very small probability of 1814 collision. Pseudo-random IPv4 RLOCs can be generated through random 1815 assignment from a suitably large IPv4 prefix space. 1817 Consistent operational practices can assure uniqueness for VBG- 1818 aggregated addresses/prefixes, while statistical properties for 1819 pseudo-random address self-generation can assure uniqueness for the 1820 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1821 RLOC delegation authority should be used when available, while a 1822 passive in-service DAD mechanism should be used to detect RLOC 1823 duplications when there is no RLOC delegation authority. 1825 Appendix B. Anycast Services 1827 Some of the IPv4 addresses that appear in the Potential Router List 1828 may be anycast addresses, i.e., they may be configured on the VET 1829 interfaces of multiple VBRs/VBGs. In that case, each VET router 1830 interface that configures the same anycast address must exhibit 1831 equivalent outward behavior. 1833 Use of an anycast address as the IP destination address of tunneled 1834 packets can have subtle interactions with tunnel path MTU and 1835 neighbor discovery. For example, if the initial fragments of a 1836 fragmented tunneled packet with an anycast IP destination address are 1837 routed to different egress tunnel endpoints than the remaining 1838 fragments, the multiple endpoints will be left with incomplete 1839 reassembly buffers. This issue can be mitigated by ensuring that 1840 each egress tunnel endpoint implements a proactive reassembly buffer 1841 garbage collection strategy. Additionally, ingress tunnel endpoints 1842 that send packets with an anycast IP destination address must use the 1843 minimum path MTU for all egress tunnel endpoints that configure the 1844 same anycast address as the tunnel MTU. Finally, ingress tunnel 1845 endpoints should treat ICMP unreachable messages from a router within 1846 the tunnel as at most a weak indication of neighbor unreachability, 1847 since the failures may only be transient and a different path to an 1848 alternate anycast router quickly selected through reconvergence of 1849 the underlying routing protocol. 1851 Use of an anycast address as the IP source address of tunneled 1852 packets can lead to more serious issues. For example, when the IP 1853 source address of a tunneled packet is anycast, ICMP messages 1854 produced by routers within the tunnel might be delivered to different 1855 ingress tunnel endpoints than the ones that produced the packets. In 1856 that case, functions such as path MTU discovery and neighbor 1857 unreachability detection may experience non-deterministic behavior 1858 that can lead to communications failures. Additionally, the 1859 fragments of multiple tunneled packets produced by multiple ingress 1860 tunnel endpoints may be delivered to the same reassembly buffer at a 1861 single egress tunnel endpoint. In that case, data corruption may 1862 result due to fragment misassociation during reassembly. 1864 In view of these considerations, VBGs that configure an anycast 1865 address should also configure one or more unicast addresses from the 1866 Potential Router List; they should further accept tunneled packets 1867 destined to any of their anycast or unicast addresses, but should 1868 send tunneled packets using a unicast address as the source address. 1870 Appendix C. Change Log 1872 (Note to RFC editor - this section to be removed before publication 1873 as an RFC.) 1875 Changes from -14 to -15: 1877 o new insights into default route configuration and next-hop 1878 determination 1880 Changes from -13 to -14: 1882 o fixed Idnits 1884 Changes from -12 to -13: 1886 o Changed "VGL" *back* to "PRL" 1888 o More changes for multi-protocol support 1890 o Changes to Redirect function 1892 Changes from -11 to -12: 1894 o Major section rearrangement 1896 o Changed "PRL" to "VGL" 1898 o Brought back text that was lost in the -10 to -11 transition 1900 Changes from -10 to -11: 1902 o Major changes with significant simplifications 1904 o Now support stateless PD using 6rd mechanisms 1906 o SEAL Control Message Protocol (SCMP) used instead of ICMPv6 1908 o Multi-protocol support including IPv6, IPv4, OSI/CLNP, etc. 1910 Changes from -09 to -10: 1912 o Changed "enterprise" to "enterprise network" throughout 1914 o dropped "inner IP", since inner layer may be non-IP 1916 o TODO - convert "IPv6 ND" to SEAL SCMP messages so that control 1917 messages remain *within* the tunnel interface instead of being 1918 exposed to the inner network layer protocol engine. 1920 Changes from -08 to -09: 1922 o Expanded discussion of encapsulation/decapsulation procedures 1924 o cited IRON 1926 Changes from -07 to -08: 1928 o Specified the approach to global mapping using virtual aggregation 1929 and BGP 1931 Changes from -06 to -07: 1933 o reworked redirect function 1935 o created new section on VET interface encapsulation 1937 o clarifications on nexthop selection 1939 o fixed several bugs 1941 Changed from -05 to -06: 1943 o reworked VET interface ND 1945 o anycast clarifications 1947 Changes from -03 to -04: 1949 o security consideration clarifications 1951 Changes from -02 to -03: 1953 o security consideration clarifications 1955 o new PRLNAME for VET is "isatav2.example.com" 1957 o VET now uses SEAL natively 1959 o EBGs can support both legacy ISATAP and VET over the same 1960 underlying interfaces. 1962 Changes from -01 to -02: 1964 o Defined CGA and privacy address configuration on VET interfaces 1966 o Interface identifiers added to routing protocol control messages 1967 for link-layer multiplexing 1969 Changes from -00 to -01: 1971 o Section 4.1 clarifications on link-local assignment and RLOC 1972 autoconfiguration. 1974 o Appendix B clarifications on Weak End System Model 1975 Changes from RFC5558 to -00: 1977 o New appendix on RLOC configuration on VET interfaces. 1979 Author's Address 1981 Fred L. Templin (editor) 1982 Boeing Research & Technology 1983 P.O. Box 3707 MC 7L-49 1984 Seattle, WA 98124 1985 USA 1987 Email: fltemplin@acm.org