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