idnits 2.17.1 draft-templin-intarea-vet-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 976: '...es in each RA, but it MUST NOT include...' RFC 2119 keyword, line 1013: '...rface to 1000. The EBR SHOULD include...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2010) is 5204 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) == Unused Reference: 'RFC1035' is defined on line 1619, but no explicit reference was found in the text == Unused Reference: 'RFC3007' is defined on line 1632, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 1639, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1706, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-dhcpv6-agentopt-delegate' is defined on line 1716, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1817, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1823, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-08 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-08 == Outdated reference: A later version (-02) exists of draft-hain-ipv6-ulac-01 == Outdated reference: A later version (-05) exists of draft-ietf-csi-proxy-send-01 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-04 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-10 == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-01 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-06 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-09 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 == Outdated reference: A later version (-03) exists of draft-nakibly-v6ops-tunnel-loops-00 == Outdated reference: A later version (-05) exists of draft-russert-rangers-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 7 errors (**), 0 flaws (~~), 22 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Standards Track January 26, 2010 5 Expires: July 30, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-08.txt 10 Abstract 12 Enterprise networks connect hosts and routers over various link 13 types, and may also connect to provider networks and/or the global 14 Internet. Enterprise network nodes require a means to automatically 15 provision IP addresses/prefixes and support internetworking operation 16 in 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. VET can also be 22 considered as version 2 of the Intra-Site Automatic Tunnel Addressing 23 Protocol (i.e., "ISATAPv2"). 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on July 30, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 11 67 4. VET Interface Encapsulation . . . . . . . . . . . . . . . . . 12 68 4.1. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 12 69 4.2. Outer IP Header Encapsulation/Decapsulation . . . . . . . 13 70 5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 14 71 5.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 14 72 5.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 15 73 5.2.1. VET Interface Initialization . . . . . . . . . . . . . 16 74 5.2.2. PRL Discovery and Enterprise Identification . . . . . 16 75 5.2.3. Provider-Aggregated (PA) EID Prefix 76 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 77 5.2.4. Provider-Independent (PI) EID Prefix 78 Autoconfiguration . . . . . . . . . . . . . . . . . . 18 79 5.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 19 80 5.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 19 81 6. Internetworking Operation . . . . . . . . . . . . . . . . . . 20 82 6.1. Routing Protocol Participation . . . . . . . . . . . . . . 20 83 6.2. Address Selection . . . . . . . . . . . . . . . . . . . . 21 84 6.3. VET interface Neighbor Discovery . . . . . . . . . . . . . 21 85 6.3.1. Router and Prefix Discovery . . . . . . . . . . . . . 21 86 6.3.2. Next Hop Determination . . . . . . . . . . . . . . . . 25 87 6.3.3. Redirect Function . . . . . . . . . . . . . . . . . . 26 88 6.3.4. Neighbor Unreachability Detection . . . . . . . . . . 28 89 6.3.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 28 90 6.3.6. IPv4 Neighbor Discovery . . . . . . . . . . . . . . . 28 91 6.4. Generating Errors . . . . . . . . . . . . . . . . . . . . 29 92 6.5. Processing Errors . . . . . . . . . . . . . . . . . . . . 29 93 6.6. Mobility and Multihoming Considerations . . . . . . . . . 30 94 6.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 31 95 6.8. Service Discovery . . . . . . . . . . . . . . . . . . . . 32 96 6.9. Enterprise Partitioning . . . . . . . . . . . . . . . . . 32 97 6.10. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 32 98 6.11. Support for Legacy ISATAP Services . . . . . . . . . . . . 32 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 101 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 34 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 103 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 107 Appendix A. Duplicate Address Detection (DAD) Considerations . . 41 108 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 42 109 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 44 110 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 45 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 113 1. Introduction 115 Enterprise networks [RFC4852] connect hosts and routers over various 116 link types (see [RFC4861], Section 2.2). The term "enterprise 117 network" in this context extends to a wide variety of use cases and 118 deployment scenarios. For example, an "enterprise" can be as small 119 as a SOHO network, as complex as a multi-organizational corporation, 120 or as large as the global Internet itself. ISP networks are another 121 example use case that fits well with the VET enterprise network 122 model. Mobile Ad hoc Networks (MANETs) [RFC2501] can also be 123 considered as a challenging example of an enterprise network, in that 124 their topologies may change dynamically over time and that they may 125 employ little/no active management by a centralized network 126 administrative authority. These specialized characteristics for 127 MANETs require careful consideration, but the same principles apply 128 equally to other enterprise network scenarios. 130 This document specifies a Virtual Enterprise Traversal (VET) 131 abstraction for autoconfiguration and internetworking operation, 132 where addresses of different scopes may be assigned on various types 133 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 134 [RFC2460] are discussed within this context. The use of standard 135 DHCP [RFC2131] [RFC3315] and neighbor discovery [RFC0826] [RFC1256] 136 [RFC4861] mechanisms is assumed unless otherwise specified. 138 Provider-Edge Interfaces 139 x x x 140 | | | 141 +--------------------+---+--------+----------+ E 142 | | | | | n 143 | I | | .... | | t 144 | n +---+---+--------+---+ | e 145 | t | +--------+ /| | r 146 | e I x----+ | Host | I /*+------+--< p I 147 | r n | |Function| n|**| | r n 148 | n t | +--------+ t|**| | i t 149 | a e x----+ V e|**+------+--< s e 150 | l r . | E r|**| . | e r 151 | f . | T f|**| . | f 152 | V a . | +--------+ a|**| . | I a 153 | i c . | | Router | c|**| . | n c 154 | r e x----+ |Function| e \*+------+--< t e 155 | t s | +--------+ \| | e s 156 | u +---+---+--------+---+ | r 157 | a | | .... | | i 158 | l | | | | o 159 +--------------------+---+--------+----------+ r 160 | | | 161 x x x 162 Enterprise-Edge Interfaces 164 Figure 1: Enterprise Router (ER) Architecture 166 Figure 1 above depicts the architectural model for an Enterprise 167 Router (ER). As shown in the figure, an ER may have a variety of 168 interface types including enterprise-edge, enterprise-interior, 169 provider-edge, internal-virtual, as well as VET interfaces used for 170 IP within IP encapsulation. The different types of interfaces are 171 defined, and the autoconfiguration mechanisms used for each type are 172 specified. This architecture applies equally for MANET routers, in 173 which enterprise-interior interfaces correspond to the wireless 174 multihop radio interfaces typically associated with MANETs. Out of 175 scope for this document is the autoconfiguration of provider 176 interfaces, which must be coordinated in a manner specific to the 177 service provider's network. 179 Enterprise networks must have a means for supporting both Provider- 180 Independent (PI) and Provider-Aggregated (PA) addressing. This is 181 especially true for enterprise scenarios that involve mobility and 182 multihoming. Also in scope are ingress filtering for multihomed 183 sites, adaptation based on authenticated ICMP feedback from on-path 184 routers, effective tunnel path MTU mitigations, and routing scaling 185 suppression as required in many enterprise network scenarios. The 186 VET specification provides adaptable mechanisms that address these 187 and other issues in a wide variety of enterprise network use cases. 189 VET represents a functional superset of 6over4 [RFC2529] and the 190 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], 191 and can be considered as version 2 of the ISATAP protocol (i.e., 192 "ISATAPv2"). VET works in conjunction with the Subnetwork 193 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal], 194 and is also compatible with additional encapsulations such as IPsec 195 [RFC4301]. VET further defines mechanisms that are very similar in 196 nature to those specified for IPv6 operation over Non-Broadcast 197 Multiple Access (NBMA) networks [RFC2491]. 199 VET and its associated technologies serve as functional building 200 blocks for a new Internetworking architecture known as Routing and 201 Addressing in Next Generation EnteRprises [I-D.templin-ranger] 202 [I-D.russert-rangers]. The VET principles can be either directly or 203 indirectly traced to the deliberations of the ROAD group in January 204 1992, and also to still earlier works including NIMROD [RFC1753] and 205 the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. 206 [RFC1955] captures the high-level architectural aspects of the ROAD 207 group deliberations in a "New Scheme for Internet Routing and 208 Addressing (ENCAPS) for IPNG". 210 VET is related to the present-day activities of the IETF INTAREA, 211 AUTOCONF, DHC, IPv6, MANET, and V6OPS working groups, as well as the 212 IRTF RRG working group. 214 2. Terminology 216 The mechanisms within this document build upon the fundamental 217 principles of IP within IP encapsulation. The terms "inner" and 218 "outer" are used to, respectively, refer to the innermost IP 219 {address, protocol, header, packet, etc.} *before* encapsulation, and 220 the outermost IP {address, protocol, header, packet, etc.} *after* 221 encapsulation. VET also uses the Subnetwork Encapsulation and 222 Adaptation Layer (SEAL) [I-D.templin-intarea-seal] as a "mid-layer" 223 encapsulation between the inner and outer IP headers, and also allows 224 for inclusion of other mid-layer encapsulations including IPSec 225 [RFC4301]. 227 The terminology in the normative references apply; the following 228 terms are defined within the scope of this document: 230 Virtual Enterprise Traversal (VET) 231 an abstraction that uses IP within IP encapsulation to create 232 overlays for traversing enterprise networks. VET can be 233 considered as version 2 of the ISATAP protocol (i.e., "ISATAPv2"). 235 enterprise 236 the same as defined in [RFC4852]. An enterprise is also 237 understood to refer to a cooperative networked collective of 238 devices within a common IP routing and addressing region and with 239 a commonality of business, social, political, etc., interests. 240 Minimally, the only commonality of interest in some enterprise 241 network scenarios may be the cooperative provisioning of 242 connectivity itself. 244 subnetwork 245 the same as defined in [RFC3819]. 247 site 248 a logical and/or physical grouping of interfaces that connect a 249 topological area less than or equal to an enterprise in scope. A 250 site within an enterprise can, in some sense, be considered as an 251 enterprise unto itself. 253 Mobile Ad hoc Network (MANET) 254 a connected topology of mobile or fixed routers that maintain a 255 routing structure among themselves over dynamic links. The 256 characteristics of MANETs are defined in [RFC2501], Section 3, and 257 a wide variety of MANETs share common properties with enterprise 258 networks. 260 enterprise/site/MANET 261 throughout the remainder of this document, the term "enterprise" 262 is used to collectively refer to any of {enterprise, site, MANET}, 263 i.e., the VET mechanisms and operational principles can be applied 264 to enterprises, sites, and MANETs of any size or shape. 266 Enterprise Router (ER) 267 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 268 mobile router that comprises a router function, a host function, 269 one or more enterprise-interior interfaces, and zero or more 270 internal virtual, enterprise-edge, provider-edge, and VET 271 interfaces. At a minimum, an ER forwards outer IP packets over 272 one or more sets of enterprise-interior interfaces, where each set 273 connects to a distinct enterprise. 275 Enterprise Border Router (EBR) 276 an ER that connects edge networks to the enterprise and/or 277 connects multiple enterprises together. An EBR is a tunnel 278 endpoint router, and it configures a separate VET interface over 279 each set of enterprise-interior interfaces that connect the EBR to 280 each distinct enterprise. In particular, an EBR may configure 281 multiple VET interfaces - one for each distinct enterprise. All 282 EBRs are also ERs. 284 Enterprise Border Gateway (EBG) 285 an EBR that connects VET interfaces configured over child 286 enterprises to a provider network - either directly via a 287 provider-edge interface or indirectly via another VET interface 288 configured over a parent enterprise. EBRs may act as EBGs on some 289 VET interfaces and as ordinary EBRs on other VET interfaces. All 290 EBGs are also EBRs. 292 VET host 293 any node (host or router) that configures a VET interface for 294 host-operation only. Note that a node may configure some of its 295 VET interfaces as host interfaces and others as router interfaces. 297 VET node 298 any node (host or router) that configures and uses a VET 299 interface. 301 enterprise-interior interface 302 an ER's attachment to a link within an enterprise. Packets sent 303 over enterprise-interior interfaces may be forwarded over multiple 304 additional enterprise-interior interfaces within the enterprise 305 before they are forwarded via an enterprise-edge interface, 306 provider-edge interface, or a VET interface configured over a 307 different enterprise. Enterprise-interior interfaces connect 308 laterally within the IP network hierarchy. 310 enterprise-edge interface 311 an EBR's attachment to a link (e.g., an Ethernet, a wireless 312 personal area network, etc.) on an arbitrarily complex edge 313 network that the EBR connects to an enterprise and/or provider 314 network. Enterprise-edge interfaces connect to lower levels 315 within the IP network hierarchy. 317 provider-edge interface 318 an EBR's attachment to the Internet or to a provider network 319 outside of the enterprise via which the Internet can be reached. 320 Provider-edge interfaces connect to higher levels within the IP 321 network hierarchy. 323 internal-virtual interface 324 an interface that is internal to an EBR and does not in itself 325 directly attach to a tangible physical link, e.g., an Ethernet 326 cable. Examples include a loopback interface, a virtual private 327 network interface, or some form of tunnel interface. 329 VET link 330 a virtual link that uses automatic tunneling to create an overlay 331 network that spans an enterprise-interior routing region. VET 332 links can be segmented (e.g., by filtering gateways) into multiple 333 distinct segments that can be joined together by bridges or IP 334 routers the same as for any link. Bridging would view the 335 multiple (bridged) segments as a single VET link, whereas IP 336 routing would view the multiple segments as multiple distinct VET 337 links. VET link segments can further be partitioned into multiple 338 logical areas, where each area is identified by a distinct set of 339 EBGs. 341 VET links in non-multicast enterprises are Non-Broadcast, Multiple 342 Access (NBMA); VET links in enterprises that support multicast are 343 multicast capable. 345 VET interface 346 a VET node's attachment to a VET link. VET nodes configure each 347 VET interface over a set of underlying interfaces that connect to 348 an enterprise-interior routing region spanned by a single VET 349 link. When there are multiple distinct VET links (each with their 350 own distinct set of underlying interfaces), the VET node 351 configures separate VET interfaces for each link. 353 The VET interface encapsulates each inner IP packet in any mid- 354 layer headers followed by an outer IP header, then forwards the 355 packet on an underlying interface such that the Time to Live (TTL) 356 - Hop Limit in the inner header is not decremented as the packet 357 traverses the link. The VET interface therefore presents an 358 automatic tunneling abstraction that represents the link as a 359 single IP hop. 361 VET address 362 an IPv6 address assigned to a VET interface that embeds an IPv4 363 address within the IPv6 address interface identifier. VET 364 addresses are formed exactly as specified for ISATAP addresses in 365 Sections 6.1 and 6.2 of [RFC5214]. 367 Provider-Independent (PI) prefix 368 an IPv6 prefix (e.g., 2001:DB8::/48) or IPv4 prefix (e.g., 369 192.0.2/24) that is either self-generated by an EBR or delegated 370 to an EBR by a registry. 372 Provider Aggregated (PA) prefix 373 an IPv6 or IPv4 prefix that is delegated to an EBR by a provider 374 network. 376 Routing Locator (RLOC) 377 a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix 378 that can appear in enterprise-interior and/or interdomain routing 379 tables. Global-scope RLOC prefixes are delegated to specific 380 enterprises and routable within both the enterprise-interior and 381 interdomain routing regions. Enterprise-local-scope RLOC prefixes 382 (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 privacy 383 addresses [RFC1918], etc.) are self-generated by individual 384 enterprises and routable only within the enterprise-interior 385 routing region. 387 ERs use RLOCs for operating the enterprise-interior routing 388 protocol and for next-hop determination in forwarding packets 389 addressed to other RLOCs. End systems use RLOCs as addresses for 390 end-to-end communications between peers within the same 391 enterprise. VET interfaces treat RLOCs as *outer* IP addresses 392 during encapsulation. 394 Endpoint Interface iDentifier (EID) 395 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 396 within an enterprise-edge or VET overlay network scope, and may 397 also appear in enterprise-interior and/or interdomain mapping 398 tables. EID prefixes are separate and distinct from any RLOC 399 prefix space. 401 Edge network routers use EIDs for operating the enterprise-edge or 402 VET overlay network routing protocol and for next-hop 403 determination in forwarding packets addressed to other EIDs. End 404 systems use EIDs as addresses for end-to-end communications 405 between peers either within the same enterprise or within 406 different enterprises. VET interfaces treat EIDs as *inner* IP 407 addresses during encapsulation. 409 The following additional acronyms are used throughout the document: 411 CGA - Cryptographically Generated Address 412 DHCP(v4, v6) - Dynamic Host Configuration Protocol 413 ECMP - Equal Cost Multi Path 414 FIB - Forwarding Information Base 415 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 416 NBMA - Non-Broadcast, Multiple Access 417 ND - Neighbor Discovery 418 PIO - Prefix Information Option 419 PRL - Potential Router List 420 PRLNAME - Identifying name for the PRL (default is "isatapv2") 421 RIO - Route Information Option 422 RPF - Reverse Path Forwarding 423 RS/RA - IPv6 ND Router Solicitation/Advertisement 424 SEAL - Subnetwork Encapsulation and Adaptation Layer 425 SLAAC - IPv6 StateLess Address AutoConfiguation 427 3. Enterprise Characteristics 429 Enterprises consist of links that are connected by Enterprise Routers 430 (ERs) as depicted in Figure 1. ERs typically participate in a 431 routing protocol over enterprise-interior interfaces to discover 432 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 433 Enterprise Border Routers (EBRs) are ERs that connect edge networks 434 to the enterprise and/or join multiple enterprises together. 435 Enterprise Border Gateways (EBGs) are EBRs that connect enterprises 436 to provider networks. 438 Conceptually, an ER embodies both a host function and router 439 function. The host function supports Endpoint Interface iDentifier 440 (EID)-based and/or Routing LOCator (RLOC)-based communications 441 according to the weak end-system model [RFC1122]. The router 442 function engages in the enterprise-interior routing protocol, 443 connects any of the ER's edge networks to the enterprise, and may 444 also connect the enterprise to provider networks (see Figure 1). 446 An enterprise may be as simple as a small collection of ERs and their 447 attached edge networks; an enterprise may also contain other 448 enterprises and/or be a subnetwork of a larger enterprise. An 449 enterprise may further encompass a set of branch offices and/or 450 nomadic hosts connected to a home office over one or several service 451 providers, e.g., through Virtual Private Network (VPN) tunnels. 452 Finally, an enterprise may contain many internal partitions that are 453 logical or physical groupings of nodes for the purpose of load 454 balancing, organizational separation, etc. In that case, each 455 internal partition resembles an individual segment of a bridged LAN. 457 Enterprises that comprise link types with sufficiently similar 458 properties (e.g., Layer 2 (L2) address formats, maximum transmission 459 units (MTUs), etc.) can configure a sub-IP layer routing service such 460 that IP sees the enterprise as an ordinary shared link the same as 461 for a (bridged) campus LAN. In that case, a single IP hop is 462 sufficient to traverse the enterprise without need for encapsulation. 463 Enterprises that comprise link types with diverse properties and/or 464 configure multiple IP subnets must also provide an enterprise- 465 interior routing service that operates as an IP layer mechanism. In 466 that case, multiple IP hops may be necessary to traverse the 467 enterprise such that care must be taken to avoid multi-link subnet 468 issues [RFC4903]. 470 In addition to other interface types, VET nodes configure VET 471 interfaces that view all other nodes on the VET link as single-hop 472 neighbors. VET nodes configure a separate VET interface for each 473 distinct VET link to which they connect, and discover other EBRs on 474 the link that can be used for forwarding packets to off-link 475 destinations. 477 For each distinct enterprise, an enterprise trust basis must be 478 established and consistently applied. For example, in enterprises in 479 which EBRs establish symmetric security associations, mechanisms such 480 as IPsec [RFC4301] can be used to assure authentication and 481 confidentiality. In other enterprise network scenarios, asymmetric 482 securing mechanisms such as SEcure Neighbor Discovery (SEND) 483 [RFC3971] may be necessary to authenticate exchanges based on trust 484 anchors. Still other enterprises may have sufficient infrastructure 485 trust basis (e.g., through proper deployment of filtering gateways at 486 enterprise borders) and may not require nodes to implement such 487 additional mechanisms. 489 Finally, in enterprises with a centralized management structure 490 (e.g., a corporate campus network), an enterprise mapping service and 491 a synchronized set of EBGs can provide sufficient infrastructure 492 support for virtual enterprise traversal. In that case, the EBGs can 493 provide a "default mapper" [I-D.jen-apt] service used for short-term 494 packet forwarding until EBR neighbor relationships can be 495 established. In enterprises with a distributed management structure 496 (e.g., MANETs), peer-to-peer coordination between the EBRs themselves 497 may be required. Recognizing that various use cases will entail a 498 continuum between a fully distributed and fully centralized approach, 499 the following sections present the mechanisms of Virtual Enterprise 500 Traversal as they apply to a wide variety of scenarios. 502 4. VET Interface Encapsulation 504 VET interfaces encapsulate inner IP packets in any mid-layer headers 505 followed by an outer IP header as follows: 507 4.1. SEAL Encapsulation 509 When SEAL is used, the VET interface encapsulates the inner IP packet 510 in any mid-layer headers (e.g., IPsec [RFC4301]) followed a SEAL 511 header [I-D.templin-intarea-seal] followed by an outer IP header; it 512 next submits the encapsulated packet to the outer IP forwarding 513 engine for transmission on an underlying interface. 515 VET interfaces can use SEAL encapsulation to accommodate path MTU 516 diversity, to defeat source address spoofing, and to enable sub-IP 517 layer hints of forward progress that can be piggybacked on ordinary 518 data messages. SEAL encapsulation maintains a unidirectional and 519 monotonically incrementing per-packet identification value known as 520 the 'SEAL_ID'. When a VET node that uses SEAL encapsulation receives 521 an authentic neighbor discovery message from another VET node, it can 522 cache the new SEAL_ID as per-tunnel state used for maintaining a 523 window of unacknowledged SEAL_IDs. 525 In terms of security, when a VET node receives an ICMP message or a 526 SEAL error message, it can confirm that the packet-in-error within 527 the message corresponds to one of its recently sent packets by 528 examining the SEAL_ID along with source and destination addresses, 529 etc. Additionally, a next-hop EBR can track the SEAL_ID in packets 530 received from EBRs for which there is an ingress filter entry and 531 discard packets that have SEAL_ID values outside of the current 532 window. (Note that, for IPv6 within IPv4 encapsulation, packets with 533 a link-local IPv6 destination address are excluded from this check to 534 support operation of the neighbor discovery protocol.) 536 In terms of next-hop reachability, an EBR can set the SEAL 537 "Acknowledgement Requested" bit in messages to receive confirmation 538 that a next-hop EBR is reachable. (Note that this is a mid-layer 539 reachability confirmation, and not an L2 reachability indication.) 540 Setting the "Acknowledgement Requested" bit is also used as the 541 method for maintaining the window of outstanding SEAL_IDs. 543 4.2. Outer IP Header Encapsulation/Decapsulation 545 VET interfaces add an outer IP header during encapsulation and remove 546 the outer IP header during decapsulation. Outer IP header 547 construction during encapsulation is the same as specified for 548 ordinary IP within IP encapsulation (e.g., [RFC2003], [RFC4213], 549 etc.) except that the "TTL/Hop Limit", "Type of Service/Traffic 550 Class" and "Congestion Experienced" values in the inner IP header are 551 copied into the corresponding fields in the outer IP header. 553 If a packet will be forwarded from one VET interface into another VET 554 interface, however, the "TTL/Hop Limit", "Type of Service/Traffic 555 Class" and "Congestion Experienced" values in the outer IP header 556 received over the first VET interface are copied into the 557 corresponding fields in the outer IP header to be sent over the 558 second VET interface (i.e., the values are transferred between outer 559 headers and *not* copied from the inner IP header). This is true 560 even if the packet is forwarded out the same VET interface that it 561 arrived on, and necessary to support diagnostic functions and avoid 562 looping. 564 During decapsulation when the next-hop is via a non-VET interface, 565 the "Congestion Experienced" value in the outer IP header is copied 566 into the corresponding field in the inner IP header. No other values 567 from the outer IP header are copied into the inner IP header. 569 5. Autoconfiguration 571 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 572 specified in the following subsections. 574 5.1. Enterprise Router (ER) Autoconfiguration 576 ERs configure enterprise-interior interfaces and engage in any 577 routing protocols over those interfaces. 579 When an ER joins an enterprise, it first configures an IPv6 link- 580 local address on each enterprise-interior interface and configures an 581 IPv4 link-local address on each enterprise-interior interface that 582 requires an IPv4 link-local capability. IPv6 link-local address 583 generation mechanisms include Cryptographically Generated Addresses 584 (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 585 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 586 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 587 provide an IPv4 link-local address generation capability. 589 Next, the ER configures one or more RLOCs and engages in any routing 590 protocols on its enterprise-interior interfaces. The ER can 591 configure RLOCs via explicit management, DHCP autoconfiguration, 592 pseudo-random self-generation from a suitably large address pool, or 593 through an alternate autoconfiguration mechanism. The ER may 594 optionally configure and assign a separate RLOC for each underlying 595 interface, or it may configure only a single RLOC and assign it to a 596 VET interface configured over the underlying interfaces (see Section 597 5.2.1). In the latter case, the ER can use the VET interface for 598 link layer multiplexing and traffic engineering purposes as specified 599 in Appendix B. 601 Alternatively (or in addition), the ER can request RLOC prefix 602 delegations via an automated prefix delegation exchange over an 603 enterprise-interior interface and can assign the prefix(es) on 604 enterprise-edge interfaces. Note that in some cases, the same 605 enterprise-edge interfaces may assign both RLOC and EID addresses if 606 there is a means for source address selection. In other cases (e.g., 607 for separation of security domains), RLOCs and EIDs must be assigned 608 on separate sets of enterprise-edge interfaces. 610 Self-generation of RLOCs for IPv6 can be from a large public or 611 local-use IPv6 address range (e.g., IPv6 Unique Local Addresses 612 [RFC4193]). Self-generation of RLOCs for IPv4 can be from a large 613 public or local-use IPv4 address range (e.g., [RFC1918]). When self- 614 generation is used alone, the ER must continuously monitor the RLOCs 615 for uniqueness, e.g., by monitoring the enterprise-interior routing 616 protocol. 618 DHCP generation of RLOCs may require support from relays within the 619 enterprise. For DHCPv6, relays that do not already know the RLOC of 620 a server within the enterprise forward requests to the 621 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For 622 DHCPv4, relays that do not already know the RLOC of a server within 623 the enterprise forward requests to the site-scoped IPv4 multicast 624 group address 'All_DHCPv4_Servers', which should be set to 625 239.255.2.1 unless an alternate multicast group for the site is 626 known. DHCPv4 servers that delegate RLOCs should therefore join the 627 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 628 received for that group. 630 A combined approach using both DHCP and self-generation is also 631 possible when the ER configures both a DHCP client and relay that are 632 connected, e.g., via a pair of back-to-back connected Ethernet 633 interfaces, a tun/tap interface, a loopback interface, inter-process 634 communication, etc. The ER first self-generates a temporary RLOC 635 used only for the purpose of procuring an actual RLOC taken from a 636 disjoint addressing range. The ER then engages in the enterprise- 637 interior routing protocol and performs a DHCP client/relay exchange 638 using the temporary RLOC as the address of the relay. When the DHCP 639 server delegates an actual RLOC address/prefix, the ER abandons the 640 temporary RLOC and re-engages in the enterprise-interior routing 641 protocol using an RLOC taken from the delegation. 643 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 644 enterprise-interior interfaces as singleton addresses (i.e., as 645 addresses with /32 prefix lengths for IPv4, or as addresses with /128 646 prefix lengths for IPv6) may be necessary to avoid multi-link subnet 647 issues. In other use cases, assignment of an RLOC on a VET interface 648 as specified in Appendix B can provide link layer multiplexing and 649 traffic engineering over multiple underlying interfaces using only a 650 single IP address. 652 5.2. Enterprise Border Router (EBR) Autoconfiguration 654 EBRs are ERs that configure VET interfaces over distinct sets of 655 underlying interfaces belonging to the same enterprise; an EBR can 656 connect to multiple enterprises, in which case it would configure 657 multiple VET interfaces. In addition to the ER autoconfiguration 658 procedures specified in Section 5.1, EBRs perform the following 659 autoconfiguration operations. 661 5.2.1. VET Interface Initialization 663 EBRs configure a VET interface over a set of underlying interfaces 664 belonging to the same enterprise such that all other VET nodes in the 665 enterprise appear as single-hop neighbors through the use of IP 666 within IP encapsulation. After the EBR configures a VET interface, 667 it initializes the interface and assigns an IPv6 link-local address 668 and an IPv4 link-local address if necessary. The EBR also associates 669 an RLOC obtained as specified in Section 5.1 with the VET interface 670 to serve as the source address for outer IP packets. 672 When IPv6 and IPv4 are used as the inner/outer protocols 673 (respectively), the EBR autoconfigures an IPv6 link-local VET address 674 on the VET interface to support packet forwarding and operation of 675 the IPv6 neighbor discovery protocol. The link-local VET address is 676 formed exactly as specified in Sections 6.1 and 6.2 of [RFC5214]. 677 The link-local address need not be checked for uniqueness since the 678 IPv4 RLOC embedded in the address itself is managed for uniqueness 679 (see Section 5.1). 681 Link-local address configuration for other inner/outer IP protocol 682 combinations is through administrative configuration or through an 683 unspecified alternate method. However, link-local address 684 configuration for other inner/outer IP protocol combinations may not 685 be necessary if a non-link-local address can be configured through 686 other means (e.g., administrative configuration, DHCP, etc.). 688 After the EBR initializes a VET interface, it can communicate with 689 other VET nodes as single-hop neighbors on the VET link from the 690 viewpoint of the inner IP protocol. The EBR can also configure the 691 VET interface for link-layer multiplexing and traffic engineering 692 purposes as specified in Appendix B. 694 5.2.2. PRL Discovery and Enterprise Identification 696 Following VET interface initialization, the EBR next discovers a 697 Potential Router List (PRL) used to track the RLOC addresses of EBGs. 698 The PRL can be discovered through information conveyed in the 699 enterprise-interior routing protocol, through the mechanisms outlined 700 in Section 8.3.2 of [RFC5214], through a DHCP option 701 [I-D.templin-isatap-dhcp], etc. In multicast-capable enterprises, 702 EBRs can also listen for advertisements on the 'rasadv' [RASADV] 703 multicast group address. 705 Whether or not routing information is available, the EBR can discover 706 the list of EBGs by resolving an identifying name for the PRL 707 ('PRLNAME') formed as 'hostname.domainname', where 'hostname' is an 708 enterprise-specific name string and 'domainname' is an enterprise- 709 specific DNS suffix. The EBR discovers 'PRLNAME' through manual 710 configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 711 protocol advertisements, link-layer information (e.g., an IEEE 802.11 712 Service Set Identifier (SSID)), or through some other means specific 713 to the enterprise. 715 In the absence of other information, the EBR sets the 'hostname' 716 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 717 component to the enterprise-specific DNS suffix "example.com" (e.g., 718 as "isatapv2.example.com"). Note that this naming convention is 719 intentionally distinct from the convention specified in [RFC5214], 720 and is used by the EBR to distinguish between ISATAP and VET virtual 721 interfaces. 723 The global Internet interdomain routing core represents a specific 724 example of an enterprise network scenario, albeit on an enormous 725 scale. The 'PRLNAME' assigned to the global Internet interdomain 726 routing core is "isatapv2.net". Isolated enterprise networks that do 727 not connect to the outside world may have no enterprise-specific DNS 728 suffix. In that case, the 'PRLNAME' consists only of the 'hostname' 729 component (e.g., "isatapv2"). 731 After discovering 'PRLNAME', the EBR resolves the name into a list of 732 RLOC addresses through a name service lookup. For centrally managed 733 enterprises, the EBR resolves 'PRLNAME' using an enterprise-local 734 name service (e.g., the DNS). For enterprises with a distributed 735 management structure, the EBR resolves 'PRLNAME' using Link-Local 736 Multicast Name Resolution (LLMNR) [RFC4795] over the VET interface. 737 In that case, all EBGs in the PRL respond to the LLMNR query, and the 738 EBR accepts the union of all responses. 740 Each distinct enterprise must have a unique identity that EBRs can 741 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 742 well as the RLOCs of EBGs in the PRL serve as an identifier for the 743 enterprise. 745 5.2.3. Provider-Aggregated (PA) EID Prefix Autoconfiguration 747 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 748 autoconfiguration exchanges with EBGs over VET interfaces, where each 749 EBG may be configured as either a DHCP relay or DHCP server. 751 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 752 delegation exchange, explicit management, etc. 754 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 755 exchanges. In particular, the EBR (acting as a requesting router) 756 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 757 obtain IPv6 EID prefixes from the server (acting as a delegating 758 router). 760 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 761 exchange [RFC3315]. For example, to perform the 2-message exchange, 762 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 763 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 764 relay (see Section 5.1). The relay then forwards the message over 765 the VET interface to an EBG, which either services the request or 766 relays it further. The forwarded Solicit message will elicit a reply 767 from the server containing PA IPv6 prefix delegations. 769 The EBR can also propose a specific prefix to the DHCPv6 server per 770 Section 7 of [RFC3633]. The server will check the proposed prefix 771 for consistency and uniqueness, then return it in the reply to the 772 EBR if it was able to perform the delegation. 774 After the EBR receives PA prefix delegations, it can provision the 775 prefixes on enterprise-edge interfaces as well as on other VET 776 interfaces for which it is configured as an EBG. It can also 777 provision the prefixes on enterprise-interior interfaces to service 778 any hosts attached to the link. 780 The PA prefix delegations remain active as long as the EBR continues 781 to issue DHCP renewals over the VET interface before lease lifetimes 782 expire. The lease lifetime also keeps the delegation state active 783 even if communications between the EBR and DHCP server are disrupted 784 for a period of time (e.g., due to an enterprise network partition, 785 power failure, etc.). 787 5.2.4. Provider-Independent (PI) EID Prefix Autoconfiguration 789 Independent of any PA prefixes, EBRs can acquire and use Provider- 790 Independent (PI) EID prefixes that are self-configured (e.g., using 791 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 792 through a regional Internet registry, through a different provider, 793 through a centrally-assigned unique local address delegation 794 authority [I-D.hain-ipv6-ulac], etc.). When an EBR acquires a PI 795 prefix, it must also obtain credentials that it can use to prove 796 ownership when it registers the prefixes (see Section 6.3 and 797 Section 6.3.6). 799 After the EBR receives PI prefix delegations, it can provision the 800 prefixes on enterprise-edge interfaces as well as on other VET 801 interfaces for which it is configured as an EBG. It can also 802 provision the prefixes on enterprise-interior interfaces to service 803 any hosts attached to the link. 805 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 807 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 809 5.3. Enterprise Border Gateway (EBG) Autoconfiguration 811 EBGs are EBRs that connect child enterprises to provider networks via 812 provider-edge interfaces and/or via VET interfaces configured over 813 parent enterprises. EBGs autoconfigure their provider-edge 814 interfaces in a manner that is specific to the provider connections, 815 and they autoconfigure their VET interfaces that were configured over 816 parent enterprises using the EBR autoconfiguration procedures 817 specified in Section 5.2. 819 For each of its VET interfaces configured over a child enterprise, 820 the EBG initializes the interface the same as for an ordinary EBR 821 (see Section 5.2.1). It must then arrange to add one or more of its 822 RLOCs associated with the child enterprise to the PRL as specified in 823 [RFC5214], Section 9. In particular, for each VET interface 824 configured over a child enterprise the EBG adds the RLOCs to name 825 service resource records for 'PRLNAME' ("isatapv2.example.com", by 826 default). 828 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 829 configured over child enterprises with a distributed management 830 structure. 832 EBGs configure a DHCP relay/server on VET interfaces configured over 833 child enterprises that require DHCP services. 835 To avoid looping, EBGs must not configure a default route on a VET 836 interface configured over a child interface. 838 5.4. VET Host Autoconfiguration 840 Nodes that cannot be attached via an EBR's enterprise-edge interface 841 (e.g., nomadic laptops that connect to a home office via a Virtual 842 Private Network (VPN)) can instead be configured for operation as a 843 simple host connected to the VET interface. Such VET hosts perform 844 the same VET interface initialization and border gateway discovery 845 procedures as specified for EBRs in Section 5.2.1, but they configure 846 their VET interfaces as host interfaces (and not router interfaces). 847 Note also that a node may be configured as a host on some VET 848 interfaces and as an EBR/EBG on other VET interfaces. 850 6. Internetworking Operation 852 Following the autoconfiguration procedures specified in Section 5, 853 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 854 operations as discussed in the following sections. 856 6.1. Routing Protocol Participation 858 ERs engage in any intra-enterprise routing protocols over enterprise- 859 interior interfaces to discover routing information for forwarding IP 860 packets with RLOC addresses. EBRs can additionally engage in any 861 inter-enterprise routing protocols over VET, enterprise-edge and 862 provider-edge interfaces to discover routing information for 863 forwarding IP packets with EID addresses. Note that the EID-based 864 inter-enterprise IP routing domains are separate and distinct from 865 any RLOC-based enterprise interior IP routing domains. 867 Routing protocol participation on non-multicast VET interfaces uses 868 the NBMA interface model, e.g., in the same manner as for OSPF over 869 NBMA interfaces [RFC5340], while routing protocol participation on 870 multicast-capable VET interfaces uses the standard multicast 871 interface model. EBRs on VET interfaces use the list of EBGs in the 872 PRL (see: Section 5.2.2) as an initial list of neighbors for inter- 873 enterprise routing protocol participation. 875 EBRs that connect enterprises to the global Internet DFZ configure 876 EID-based inter-enterprise routing using the BGP [RFC4271] over a VET 877 interface that spans the entire DFZ. Each such EBR peers with a set 878 of neighboring routers on the VET interface, where the set is 879 determined through peering arrangements the same as for the current 880 global BGP. Note however that this EID-based overlay BGP instance is 881 seperate and distinct from the current RLOC-based BGP instance; 882 therefore, the set of peers used for the EID-based and RLOC-based 883 instances need not be the same. 885 Each EBR connected to the VET interface spanning the gobal Internet 886 DFZ maintains a full routing information base (RIB) of EID-based 887 prefixes. In order to limit scaling, only highly-aggregated EID 888 prefixes allocated according to the Virtual Prefix (VP) principles of 889 Virtual Aggregation (VA) [I-D.ietf-grow-va] are included in the RIB. 890 Specifically, only VP prefixes (e.g., PA prefixes delegated to the 891 top-level of an ISP or enterprise network) are maintained in the RIB 892 while more-specific prefixes (e.g., PI prefixes delegated to small 893 sites) are not. More-specific prefixes will instead be inserted into 894 selective forwarding information bases (FIBs) on-demand of traffic 895 flow such that only those routers that require the prefixes will 896 insert them into their FIBs. 898 6.2. Address Selection 900 When permitted by policy and supported by enterprise interior 901 routing, end systems can avoid VET interface encapsulation through 902 communications that directly invoke the outer IP protocol using RLOC 903 addresses instead of EID addresses for end-to-end communications. 904 For example, an enterprise that provides native IPv4 intra-network 905 services can provide continued support for native IPv4 communications 906 even when encapsulated IPv6 services are available for inter- 907 enterprise communications. In other enterprise scenarios, the use of 908 EID-based communications (i.e., instead of RLOC-based communications) 909 may be necessary and/or beneficial to support address scaling, NAT 910 traversal avoidance, security domain separation, site multihoming, 911 traffic engineering, etc. . 913 End systems can use source address selection rules (e.g., based on 914 name service information) to determine whether to use EID-based or 915 RLOC-based addressing. The remainder of this section discusses 916 internetworking operation for EID-based communications using the VET 917 interface abstraction. 919 6.3. VET interface Neighbor Discovery 921 The following sections discuss IPv6 Neighbor Discovery (ND) 922 considerations for VET interfaces for the case of IPv6 as the inner 923 IP protocol and IPv4 as the outer IP protocol (ND considerations for 924 other protocol combinations are out of scope). Depending on the 925 enterprise network trust basis, VET nodes may be required to use 926 mechanisms such as SEND to secure their ND exchanges. 928 6.3.1. Router and Prefix Discovery 930 6.3.1.1. EBR Specification 932 EBRs discover the PRL for each VET interface as specified in 933 Section 5.2.2, and participate in a dynamic routing protocol over the 934 VET interface using the EBG addresses in the PRL as addresses of 935 potential neighboring routers. When a dynamic routing protocol 936 cannot be used, EBRs instead send RS messages on their VET interfaces 937 to receive solicited RAs from each EBG in the PRL. Note that this 938 would ordinarily cause the EBG to set the 'IsRouter' flag in the 939 neighbor cache entry for this EBR to FALSE (see: [RFC4861], Appendix 940 D). 942 The EBR sends RS messages the same as described for hosts in Section 943 6.3.7 of [RFC4861], except that it includes a new 2-bit "More- 944 Specific Routes (MSR)" field taken from the most significant bits of 945 the "Reserved" field in the RS message (see Section 4.1 of [RFC4861]) 946 as shown in Figure 2 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Type | Code | Checksum | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |MSR| Reserved | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Figure 2: Router Solicitation "MSR" Field 958 In this format, the values MSR=0, 1 and 2 correspond to the host 959 types A, B, and C (respectively) as defined in Section 3 of 960 [RFC4191]. The value MSR=3 is Reserved for future use. For the 961 purpose of this specification, EBRs set MSR=2 in each RS message they 962 send. 964 When the EBR receives a solicited RA from an EBG (see Section 965 6.3.1.2), it authenticates the message then processes any 966 autoconfiguration information. (Note however that the EBR should not 967 configure prefixes received in Prefix Information Options (PIOs) on 968 its VET interfaces if it will have EID addresses and prefixes 969 configured on any of its other interfaces. This prevents the EBR 970 from sending packets directly to VET hosts without first going 971 through a default router, since VET hosts will initially only accept 972 packets that come through a PRL router.) 974 Next, the EBR creates RA messages to send to each EBG in the PRL. 975 The EBR includes a Route Information Option (RIO) [RFC4191] that 976 contains one of its EID prefixes in each RA, but it MUST NOT include 977 any other autoconfiguration parameters (e.g., non-zero Router 978 Lifetime, Prefix Information Options (PIOs), etc.) The EBR also 979 unconditionally sets the 'M' bit to 0 and the 'O' bit to 1 in order 980 to avoid conflicting with the information included in RA messages 981 from EBGs (see: Section 6.3.1.2). The EBR also includes an RLOC for 982 the EBG as the outer IP destination address and includes the IPv6 983 link-local "all nodes multicast" address as the inner IP destination 984 address [RFC4291] of the RA. 986 The EBR next creates a CGA or IPv6 privacy link-local address and 987 includes it as the inner IP source address of the RA. When CGAs are 988 used, the EBR additionally includes SEND credentials plus any router 989 certificates needed to prove its ownership of the prefixes in its 990 Route Information Options (RIOs). Note that the CGA/privacy link- 991 local address is used only as the inner source address of unsolicited 992 RA messages, and therefore need not be checked for uniqueness on the 993 link. The EBR finally includes the RLOC assigned to an underlying 994 interface as the outer source address of the RA. 996 For each of its EID prefixes, the EBR sends a separate RA message to 997 each EBG that includes multiple Source Link Layer Address Options 998 (SLLAOs) formatted using a modified version of the form specified in 999 Section 5 of [RFC2529] as shown in Figure 3: 1001 +-------+-------+-------+-------+-------+-------+-------+-------+ 1002 | Type |Length | Metric | IPv4 RLOC Address | 1003 +-------+-------+-------+-------+-------+-------+-------+-------+ 1005 Figure 3: VET Link-Layer Address Option Format 1007 Each SLLAO contains the IPv4 RLOC of an underlying interface plus a 1008 metric value that specifies a weighted preference for this particular 1009 RLOC based on link bandwidth, stability, etc., where the value 0 1010 denotes the highest preference and 65535 denotes the lowest 1011 preference. For example, the EBR may set the metric for an RLOC 1012 corresponding to a 1Gbps interface to 10 and the metric for an RLOC 1013 corresponding to a WiFi interface to 1000. The EBR SHOULD include 1014 the highest preference RLOC as the final RLOC in the list of SLLAOs. 1016 The EBR then sends the RA message to the EBG and must thereafter 1017 periodically send new RA messages to refresh prefix lifetimes, where 1018 a minimum RA interface of 5 minutes is recommended. Each EBG that 1019 receives an EBR's RA will in turn relay a proxied version of the RA 1020 to EBGs on their parent enterprises. This procedure has a direct 1021 analogy in the Teredo method of maintaining state in network 1022 middleboxes through the periodic transmission of "bubbles" [RFC4380]. 1024 6.3.1.2. EBG Specification 1026 EBGs follow the router and prefix discovery procedures specified in 1027 Section 8.2 of [RFC5214]. When an EBG receives an RS message on a 1028 VET interface, it first authenticates the message. If the VET 1029 interface maintains a neighbor cache, the EBG next creates or updates 1030 a neighbor cache entry for the VET link-local source address 1031 corresponding to the outer IP source address of the RS according to 1032 Section 6.2.6 of [RFC4861] and caches the value in the MSR field 1033 (see: Section 6.3.1.1). As a modification to the IsRouter processing 1034 rules of Appendix D of [RFC4861], the EBG sets the IsRouter flag to 1035 TRUE instead of FALSE if the value in the MSR field is 2. 1037 If the neighbor cache entry cannot be created or updated (e.g., due 1038 to insufficient resources), the EBG silently discards the RS and does 1039 not send an RA. Otherwise, the EBG creates/updates the neighbor 1040 cache entry, sets a "Time To Live (TTL)" on the entry that is no 1041 shorter than any of its advertised router or prefix lifetimes, and 1042 sends an RA response to the RS. If the neighbor cache entry TTL 1043 subsequently expires before a new RS arrives, the EBG deletes the 1044 neighbor cache entry. Note that the EBG can omit these neighbor 1045 cache manipulations if no neighbor cache is required; in that case, 1046 however, no value for MSR will be cached and a default value of 0 is 1047 assumed. 1049 The EBG then prepares an RA response to the RS that includes Router 1050 Lifetimes, PIOs, and any other options/parameters that the EBG is 1051 configured to include. The EBG unconditionally sets the 'M' bit to 0 1052 and the 'O' bit to 1. Next, the EBG includes SEND parameters if 1053 necessary and sets the inner and outer IP source and destination 1054 addresses. The EBG sets the inner IP source address to a CGA or IPv6 1055 privacy link-local address, then sets the outer IP source address to 1056 one of its RLOC addresses. The EBG next sets the inner IP 1057 destination address to the source address in the RS message, then 1058 sets the outer IP destination address to the EBR's RLOC address. 1059 Finally, the EBG sends the solicited RA to the VET node that sent the 1060 solicitation. 1062 In addition to RS messages, the EBG may receive RA messages sent by 1063 EBRs on VET interfaces as specified in Section 6.3.1.1. When an EBG 1064 receives the RA, it first authenticates the message; if the 1065 authentication fails, the EBG discards the RA. Otherwise, it uses 1066 the EID prefix in the RIO with its respective lifetime to updates its 1067 Forwarding Information Base (FIB). The EBG also caches each RLOC and 1068 associated metric value received in SLLAO options in the RA message 1069 as the address of a neighbor associated with the FIB entry, i.e., 1070 each FIB entry may include multiple potential next-hops. Finally, 1071 the EBG caches the RA message as ancillary data attached to the FIB 1072 entries so that the message can be replayed in the future to support 1073 router-to-router redirects (see: Section 6.3.3). 1075 After the EBG authenticates the RA and updates its FIB, it next acts 1076 as an EBR on each of its VET interfaces configured over parent 1077 enterprises and uses the Neighbor Discovery Proxy (NDProxy) [RFC4389] 1078 approach to relay a proxied RA to each of the EBGs configured on 1079 those interfaces. (For enterprises that use SEND, the proxying node 1080 additionally acts as a SEcure Neighbor Discovery Proxy (SENDProxy) 1081 [I-D.ietf-csi-proxy-send].) During this process, the proxying node 1082 replaces the SLLAO options received in the original RA message with 1083 SLLAO options that encode its own RLOC addresses and metrics. EBGs 1084 in parent enterprises that receive the proxied RAs in turn act as 1085 NDProxys/SENDProxys to relay the RAs to EBGs on their parent 1086 enterprises, etc. in a recursive fashion. 1088 In addition to forwarding proxied RA messages to EBGs on VET 1089 interfaces configured over parent enterprises, if the proxying node 1090 has FIB entries that properly cover the RIO prefix and that point to 1091 neighbors on VET intefaces other than the one the packet arrived on, 1092 it sends a proxied version of the RA to each RLOC associated with 1093 each such FIB entry. As an example, this covers the case of a DFZ 1094 router sending a proxied RA to another DFZ router that uses BGP to 1095 advertise a Virtual Prefix (VP) covering the RIO prefix 1097 6.3.1.3. VET Host Specification 1099 VET hosts follow the router and prefix discovery procedures specified 1100 in Section 8.3 of [RFC5214]. They discover the addresses of EBGs for 1101 each VET interface as specified in Section 5.2.2, and send RS 1102 messages to each EBG in order to receive RAs with autoconfiguration 1103 information. When the VET host sends an RS message on a VET 1104 interface, it sets the MSR field based on whether the host will act 1105 as an [RFC4191] type A, B or C host; if the host is willing to 1106 process RIO options and receive prefix redirects, it sets the value 1107 MSR=2 (see: Section 6.3.1.1). 1109 When the VET host receives a solicited RA from an EBG on a VET 1110 interface, it authenticates the message then performs 1111 autoconfiguration the same as for any link. In particular, if the RA 1112 message contains any PIO options the VET host performs address 1113 autoconfiguration on the VET interface according to [RFC4862]. When 1114 the host generates a VET address, it first creates an interface 1115 identifier that embeds its IPv4 RLOC address as specified in Section 1116 6.1 of [RFC5214]. The host then configures IPv6 unicast VET 1117 addresses from advertised on-link prefixes received in RA messages 1118 and assigns them to the VET interface, i.e., it does not perform 1119 Duplicate Address Detection (DAD) on the addresses since the embedded 1120 IPv4 RLOC address already provides uniqueness. 1122 6.3.2. Next Hop Determination 1124 VET nodes perform next-hop determination on VET interfaces via 1125 longest prefix match the same as for any IPv6 interface, and send 1126 packets according to the most-specific matching entry in the FIB. If 1127 the FIB entry has multiple next-hop addresses, the EBR selects the 1128 next-hop with the best metric value. If there are multiple next hops 1129 with the best metric value, the VET node can use Equal Cost Multi 1130 Path (ECMP) to forward different flows via different next-hop 1131 addresses (where flows are determined, e.g., by computing a hash of 1132 the inner packet's IPv6 source address, destination address and flow 1133 label fields). 1135 When there is no matching entry in the FIB (i.e., not even 1136 "default"), VET nodes can discover next-hop addresses within the 1137 enterprise by querying the name service for the /56 IPv6 EID prefix 1138 taken from a packet's destination address (or, by some other inner-IP 1139 to outer-IP address mapping mechanism). For example, for the IPv6 1140 destination address '2001:DB8:1:2::1' and 'PRLNAME' 1141 "isatapv2.example.com" the VET node can perform a name service lookup 1142 for the domain name: 1143 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 1145 Name-service lookups in enterprises with a centralized management 1146 structure use an infrastructure-based service, e.g., an enterprise- 1147 local DNS. Name-service lookups in enterprises with a distributed 1148 management structure and/or that lack an infrastructure-based name 1149 service instead use LLMNR over the VET interface. When LLMNR is 1150 used, the EBR that performs the lookup sends an LLMNR query (with the 1151 /56 prefix taken from the IP destination address encoded in dotted- 1152 nibble format as shown above) and accepts the union of all replies it 1153 receives from other EBRs on the VET interface. When an EBR receives 1154 an LLMNR query, it responds to the query IFF it aggregates an IP 1155 prefix that covers the prefix in the query. 1157 If the name-service lookup succeeds, it will return RLOC addresses 1158 (e.g., in DNS A records) that correspond to next-hop EBRs to which 1159 the VET node can forward packets. 1161 6.3.3. Redirect Function 1163 In enterprises with a stable and highly-available set of EBGs, VET 1164 nodes can simply forward initial packets via a default route to an 1165 EBG on a VET interface when more-specific routing information is not 1166 available. The EBG will forward the packet and return a standard 1167 ICMPv6 Redirect if necessary as specified in Section 8 of [RFC4861]. 1168 VET interfaces additionally implement an "MSR Redirect" mechanism 1169 that provides both "router-to-router" and "prefix" redirection 1170 functions as specified within this section. These additional 1171 functions are complimentary (i.e., both functions can be carried 1172 within the same redirect message) but can only be used when both the 1173 destination of the redirect and the redirected target set MSR=2 in 1174 the RS messages they send to the EBG (see: Section 6.3.1.1). 1176 When both parties to the potential redirect set MSR=2, the EBG sends 1177 an MSR Redirect (subject to rate limiting) whenever it forwards a 1178 packet out the same VET interface that it arrived on if the packet's 1179 source address is not on-link on the VET interface and/or if there is 1180 a prefix in the EBG's FIB that covers the packet's destination 1181 address. If the source address of the packet was not on-link on the 1182 VET interface, the EBG sets the destination address of the redirect 1183 to the VET link-local address of the VET node that forwarded the 1184 packet. If the EBG has a prefix in its FIB that covers the 1185 destination address of the packet, it also includes in the redirect 1186 an RIO that contains the prefix, i.e., the same as described for RA 1187 messages in [RFC4191]. 1189 The EBG next sets the source address of the MSR Redirect to a CGA or 1190 IPv6 privacy link-local address; when SEND is used, the EBG uses a 1191 CGA link-local address and includes SEND parameters. The EBG then 1192 sets the redirected target/destination fields the same as for 1193 ordinary redirects, then includes one or more IPv6 Target Link Layer 1194 Address Options (TLLAOs) formatted using the form shown in Figure 3. 1195 Each TLLAO contains an IPv4 RLOC and metric taken from neighbor cache 1196 entries corresponding to the EBG's FIB entry. Finally, the EBG 1197 includes the header of the redirected packet the same as for an 1198 ordinary redirect and returns the redirect to the VET node that sent 1199 the packet. 1201 When a VET node receives an MSR Redirect, it first authenticates the 1202 message then uses any EID prefixes in RIOs with their respective 1203 lifetimes to update its FIB. The node also caches each RLOC and 1204 associated metric value received in TLLAO options in the redirect as 1205 the address of a neighbor associated with the FIB entry. 1207 If the MSR redirect was a "router-to-router" redirect, the VET node 1208 next sends an RA to the redirected target in order to prove its 1209 authorization to source packets from the source address of the 1210 redirected packet. If the VET node owns the prefix that covers the 1211 source address, it creates a fresh RA and sends it to the redirected 1212 target. If the VET node is instead an upstream router on the path 1213 from the source, it "replays" the cached RA message associated with a 1214 FIB entry corresponding to the packet's source address using an RLOC 1215 address from the redirected target as the outer IP destination 1216 address and with SLLAO options that encode the VET node's RLOCs and 1217 metrics of underlying interfaces. This replaying process is the same 1218 as for the RA proxying function specified for EBGs i n Section 1219 6.3.1.2. 1221 When the redirected target VET node receives the RA, it authenticates 1222 the message (e.g., using SEND credentials) then uses any EID prefixes 1223 in RIOs with their respective lifetimes to update its FIB. The node 1224 also caches each RLOC and associated metric value received in TLLAO 1225 options in the RA message as the address of a neighbor associated 1226 with the FIB entry. This RA processing is same as specified for EBGs 1227 in Section 6.3.1.2, however the node does not proxy the RA message 1228 further. 1230 VET nodes retain the FIB entries created as a result of receipt of an 1231 ICMP redirect until the route lifetimes expire, or until no hints of 1232 forward progress through any of the FIB entry's associated RLOCs are 1233 received. In this way, RLOC liveness detection exactly parallels 1234 IPv6 Neighbor Unreachability Detection ([RFC4861], Section 7). 1236 6.3.4. Neighbor Unreachability Detection 1238 VET nodes use their neighbor cache for Neighbor Unreachability 1239 Detection (NUD) the same as for any IPv6 link as described in Section 1240 7 of [RFC4861]. When a neighbor fails (or appears to be failing), 1241 FIB entries are updated to select a different next-hop when there are 1242 multiple next-hops available. 1244 The NUD mechanism uses hints of forward progress (i.e., evidence that 1245 the tunnel neighbor is receiving packets) coupled with the Neighbor 1246 Solicitation/Advertisement (NS/NA) process. When hints of forward 1247 progress are available, NS/NA messaging is suppressed; when no hints 1248 are available, NS/NA messages are used in the normal fashion the same 1249 as for any IPv6 link. The SEAL mechanism includes an explicit data 1250 packet acknowledgement mechanism that can provide hints of forward 1251 progress. 1253 Responsiveness to routing changes is directly related to the 1254 "REACHABLE_TIME" constant used for NUD as specified in [RFC4861]. In 1255 order to provide responsiveness comparable to dynamic routing 1256 protocols, a reasonably short "REACHABLE_TIME" value (e.g., 5sec) 1257 should be used. 1259 6.3.5. Reverse Path Forwarding Checks 1261 VET nodes determine whether a packet received on a VET interface can 1262 be accepted based on an ingress filtering check [RFC3704]. The VET 1263 node determines the previous hop router for a received packet by 1264 constructing a VET link-local address that embeds the outer IPv4 1265 source address. It then examines its FIB to determine whether there 1266 is an entry that matches the inner IPv6 source address and that has 1267 the VET link-local address as the next hop. If such a FIB entry 1268 exists, the VET host accepts the packet; otherwise, it discards the 1269 packet. 1271 6.3.6. IPv4 Neighbor Discovery 1273 When IPv4 is used as the inner IP protocol, router discovery and 1274 prefix registration exactly parallel the mechanisms specified for 1275 IPv6 in Section 6.3. To support this, modifications to the ICMPv4 1276 Router Advertisement [RFC1256] function to include SEND constructs 1277 and modifications to the ICMPv4 Redirect [RFC0792] function to 1278 support router-to-router redirects will be specified in a future 1279 document. Additionally, publications for IPv4 prefixes will be in 1280 dotted-nibble format in the 'ip4.isatapv2.example.com' domain. For 1281 example, the IPv4 prefix 192.0.2/24 would be represented as: 1283 '2.0.0.0.0.c.ip4.isatapv2.example.com' 1285 6.4. Generating Errors 1287 When an EBR receives an IPv6 packet over a VET interface and there is 1288 no matching ingress filter entry, it drops the packet and returns an 1289 ICMPv6 [RFC4443] "Destination Unreachable; Reject route to 1290 destination" message to the previous-hop EBR subject to rate 1291 limiting. 1293 When an EBR receives an IPv6 packet over a VET interface, and there 1294 is no longest-prefix-match FIB entry for the destination, it returns 1295 an ICMPv6 "Destination Unreachable; No route to destination" message 1296 to the previous hop EBR subject to rate limiting. 1298 When an EBR receives an IPv6 packet over a VET interface and the 1299 longest-prefix-match FIB entry for the destination is via a next-hop 1300 configured over the same VET interface the packet arrived on, the EBR 1301 forwards the packet. If the FIB prefix is longer than ::/0, the EBR 1302 then sends a router-to-router ICMPv6 Redirect message (using SEND, if 1303 necessary) to the previous-hop EBR as specified in Section 6.3.3. 1305 Generation of other ICMP messages [RFC0792] [RFC4443] is the same as 1306 for any IP interface. 1308 6.5. Processing Errors 1310 When a VET node receives an ICMPv6 "Destination Unreachable; Reject 1311 route to destination" message, and there is a longest-prefix-match 1312 FIB entry for the original packet's destination that is more specific 1313 than ::/0, the node discards the message and marks the FIB entry for 1314 the destination as "forwarding suspended" for the RLOC taken from the 1315 source address of the ICMPv6 message. The node should then allow 1316 subsequent packets to flow through different RLOCs associated with 1317 the FIB entry. If the node receives excessive ICMPv6 reject route to 1318 destination messages through multiple RLOCs associated with the same 1319 FIB entry, it should delete the FIB entry and allow subsequent 1320 packets to flow through an EBG if supported in the specific 1321 enterprise scenario. 1323 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1324 to destination" message, it forwards the ICMPv6 message to the source 1325 of the original packet as normal. If the node has a longest-prefix- 1326 match FIB entry for the original packet's destination that is more 1327 specific than ::/0, the node also deletes the FIB entry. 1329 When a VET node receives an authentic ICMPv6 Redirect, it processes 1330 the packet as specified in Section 6.3.3. 1332 Additionally, a VET node may receive outer IP ICMP "Destination 1333 Unreachable; net / host unreachable" messages from an ER on the path 1334 indicating that the path to a VET neighbor may be failing. The node 1335 should first check authenticating information (e.g., the SEAL_ID, 1336 IPsec sequence number, source address of the original packet if 1337 available, etc.) to obtain reasonable assurance that the ICMP message 1338 is authentic, then should mark the longest-prefix-match FIB entry for 1339 the destination as "forwarding suspended" for the RLOC destination 1340 address of the ICMP packet-in-error. If the node receives excessive 1341 ICMP unreachable errors through multiple RLOCs associated with the 1342 same FIB entry, it should delete the FIB entry and allow subsequent 1343 packets to flow through a different route. 1345 6.6. Mobility and Multihoming Considerations 1347 EBRs that travel between distinct enterprise networks must either 1348 abandon their PA prefixes that are relative to the "old" enterprise 1349 and obtain new ones relative to the "new" enterprise or somehow 1350 coordinate with a "home" enterprise to retain ownership of the 1351 prefixes. In the first instance, the EBR would be required to 1352 coordinate a network renumbering event using the new PA prefixes 1353 [RFC4192]. In the second instance, an ancillary mobility management 1354 mechanism must be used. 1356 EBRs can retain their PI prefixes as they travel between distinct 1357 enterprise networks as long as they register the prefixes with new 1358 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1359 departure. Prefix registration with new EBGs is coordinated exactly 1360 as specified in Section 5.2.4; prefix withdrawal from old EBGs is 1361 simply through re-announcing the PI prefixes with zero lifetimes. 1363 Since EBRs can move about independently of one another, stale FIB 1364 entry state may be left in VET nodes when a neighboring EBR departs. 1365 Additionally, EBRs can lose state for various reasons, e.g., power 1366 failure, machine reboot, etc. For this reason, EBRs are advised to 1367 set relatively short PI prefix lifetimes in RIO options, and to send 1368 additional RAs to refresh lifetimes before they expire. (EBRs should 1369 place conservative limits on the RAs they send to reduce congestion, 1370 however.) 1372 EBRs may register their PI prefixes with multiple EBGs for 1373 multihoming purposes. EBRs should only forward packets via EBGs with 1374 which it has registered its PI prefixes, since other EBGs may drop 1375 the packets and return ICMPv6 "Destination Unreachable" messages. 1377 EBRs can also act as delegating routers to sub-delegate portions of 1378 their PI prefixes to requesting routers on their enterprise-edge 1379 interfaces and on VET interfaces for which they are configured as 1380 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1381 become the PA prefixes for downstream-dependent nodes. 1383 The EBGs of a multihomed enterprise should participate in a private 1384 inner IP routing protocol instance between themselves (possibly over 1385 an alternate topology) to accommodate enterprise partitions/merges as 1386 well as intra-enterprise mobility events. These peer EBGs should 1387 accept packets from one another without respect to the destination 1388 (i.e., ingress filtering is based on the peering relationship rather 1389 than a prefix-specific ingress filter entry). 1391 6.7. Multicast 1393 In multicast-capable deployments, ERs provide an enterprise-wide 1394 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1395 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1396 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1397 over their enterprise-interior interfaces such that outer IP 1398 multicast messages of site-scope or greater scope will be propagated 1399 across the enterprise. For such deployments, VET nodes can also 1400 provide an inner IP multicast/broadcast capability over their VET 1401 interfaces through mapping of the inner IP multicast address space to 1402 the outer IP multicast address space. In that case, operation of 1403 link-scoped (or greater scoped) inner IP multicasting services (e.g., 1404 a link-scoped neighbor discovery protocol) over the VET interface is 1405 available, but link-scoped services should be used sparingly to 1406 minimize enterprise-wide flooding. 1408 VET nodes encapsulate inner IP multicast messages sent over the VET 1409 interface in any mid-layer headers (e.g., SEAL, IPsec, etc.) followed 1410 by an outer IP header with a site-scoped outer IP multicast address 1411 as the destination. For the case of IPv6 and IPv4 as the inner/outer 1412 protocols (respectively), [RFC2529] provides mappings from the IPv6 1413 multicast address space to a site-scoped IPv4 multicast address space 1414 (for other encapsulations, mappings are established through 1415 administrative configuration or through an unspecified alternate 1416 static mapping). 1418 Multicast mapping for inner IP multicast groups over outer IP 1419 multicast groups can be accommodated, e.g., through VET interface 1420 snooping of inner multicast group membership and routing protocol 1421 control messages. To support inner-to-outer IP multicast mapping, 1422 the VET interface acts as a virtual outer IP multicast host connected 1423 to its underlying interfaces. When the VET interface detects that an 1424 inner IP multicast group joins or leaves, it forwards corresponding 1425 outer IP multicast group membership reports on an underlying 1426 interface over which the VET interface is configured. If the VET 1427 node is configured as an outer IP multicast router on the underlying 1428 interfaces, the VET interface forwards locally looped-back group 1429 membership reports to the outer IP multicast routing process. If the 1430 VET node is configured as a simple outer IP multicast host, the VET 1431 interface instead forwards actual group membership reports (e.g., 1432 IGMP messages) directly over an underlying interface. 1434 Since inner IP multicast groups are mapped to site-scoped outer IP 1435 multicast groups, the VET node must ensure that the site-scope outer 1436 IP multicast messages received on the underlying interfaces for one 1437 VET interface do not "leak out" to the underlying interfaces of 1438 another VET interface. This is accommodated through normal site- 1439 scoped outer IP multicast group filtering at enterprise boundaries. 1441 6.8. Service Discovery 1443 VET nodes can perform enterprise-wide service discovery using a 1444 suitable name-to-address resolution service. Examples of flooding- 1445 based services include the use of LLMNR [RFC4795] over the VET 1446 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1447 over an underlying interface. More scalable and efficient service 1448 discovery mechanisms are for further study. 1450 6.9. Enterprise Partitioning 1452 An enterprise can be partitioned into multiple distinct logical 1453 groupings. In that case, each partition must configure its own 1454 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1455 'isatapv2.zone2.example.com', etc.). 1457 EBGs can further create multiple IP subnets within a partition by 1458 sending RAs with PIOs containing different IPv6 prefixes to different 1459 groups of nodes. EBGs can identify subnets, e.g., by examining RLOC 1460 prefixes, observing the enterprise interior interfaces over which RSs 1461 are received, etc. 1463 6.10. EBG Prefix State Recovery 1465 EBGs must retain explicit state that tracks the inner IP PA prefixes 1466 delegated to EBRs within the enterprise, e.g., so that packets are 1467 delivered to the correct EBRs. When an EBG loses some or all of its 1468 state (e.g., due to a power failure), it must recover the state so 1469 that packets can be forwarded over correct routes. 1471 6.11. Support for Legacy ISATAP Services 1473 EBGs support legacy ISATAP services according to the specifications 1474 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1475 interfaces and VET interfaces over the same sets of underlying 1476 interface as long as the PRLs and IPv6 prefixes associated with the 1477 ISATAP/VET interfaces are distinct. 1479 7. IANA Considerations 1481 There are no IANA considerations for this document. 1483 8. Security Considerations 1485 Security considerations for MANETs are found in [RFC2501]. 1487 The security considerations found in [RFC2529] [RFC5214] 1488 [I-D.nakibly-v6ops-tunnel-loops] also apply to VET. In particular: 1490 o VET nodes must ensure that a VET interface does not span multiple 1491 sites as specified in Section 6.2 of [RFC5214]. 1493 o VET nodes must verify that the outer IP source address of a packet 1494 received on a VET interface is correct for the inner IP source 1495 address; for the case of IPv6 within IPv4 encapsulation, this is 1496 accommodated using the procedures specified in Section 7.3 of 1497 [RFC5214]. 1499 o EBRs must implement both inner and outer IP ingress filtering in a 1500 manner that is consistent with [RFC2827] as well as ip-proto-41 1501 filtering. When the node at the physical boundary of the 1502 enterprise is an ordinary ER (i.e., and not an EBR), the ER itself 1503 should implement filtering. 1505 Additionally, VET interfaces that use IPv6 within IPv4 encapsulation 1506 and that maintain a coherent neighbor cache drop all outbound packet 1507 for which the IPv6 next hop is not a neighbor and the IPv6 source 1508 address is not link-local; they also drop all incoming packets for 1509 which the IPv6 previous hop is not a neighbor and the IPv6 1510 destination address is not link-local. (Here, the previous hop is 1511 determined by examining the IPv4 source address.) 1513 Finally, VET interfaces that use IPv6 within IPv4 encapsulation drop 1514 all outbound packets for which the IPv6 source address is "foreign- 1515 prefix::0200:5efe:V4ADDR" and drop all incoming packets for which the 1516 IPv6 destination address is "foreign-prefix::0200:5efe:V4ADDR" . 1517 (Here, "foreign-prefix" is an IPv6 prefix that is not assigned to the 1518 VET interface, and "V4ADDR" is a public IPv4 address over which the 1519 VET interface is configured.) Note that these checks are only 1520 required for VET interfaces that cannot maintain a coherent neighbor 1521 cache. 1523 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1524 where attacks on the neighbor discovery protocol are possible. SEAL 1525 [I-D.templin-intarea-seal] provides a per-packet identification that 1526 can be used to detect source address spoofing. 1528 Rogue neighbor discovery messages with spoofed RLOC source addresses 1529 can consume network resources and cause VET nodes to perform extra 1530 work. Nonetheless, VET nodes should not "blacklist" such RLOCs, as 1531 that may result in a denial of service to the RLOCs' legitimate 1532 owners. 1534 9. Related Work 1536 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1537 automatic tunneling in [RFC2529]; this concept was later called: 1538 "Virtual Ethernet" and investigated by Quang Nguyen under the 1539 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1540 their colleagues have motivated a number of foundational concepts on 1541 which this work is based. 1543 Telcordia has proposed DHCP-related solutions for MANETs through the 1544 CECOM MOSAIC program. 1546 The Naval Research Lab (NRL) Information Technology Division uses 1547 DHCP in their MANET research testbeds. 1549 Security concerns pertaining to tunneling mechanisms are discussed in 1550 [I-D.ietf-v6ops-tunnel-security-concerns]. 1552 Default router and prefix information options for DHCPv6 are 1553 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1555 An automated IPv4 prefix delegation mechanism is proposed in 1556 [I-D.ietf-dhc-subnet-alloc]. 1558 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1559 [I-D.clausen-manet-autoconf-recommendations]. 1561 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1563 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1564 decapsulation issues and other aspects of tunneling. 1566 Various proposals within the IETF have suggested similar mechanisms. 1568 10. Acknowledgements 1570 The following individuals gave direct and/or indirect input that was 1571 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1572 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1573 Chris Dearlove, Gert Doering, Ralph Droms, Washam Fan, Dino 1574 Farinacci, Vince Fuller, Thomas Goff, David Green, Joel Halpern, Bob 1575 Hinden, Sascha Hlusiak, Sapumal Jayatissa, Dan Jen, Darrel Lewis, 1576 Tony Li, Joe Macker, David Meyer, Gabi Nakibly, Thomas Narten, Pekka 1577 Nikander, Dave Oran, Alexandru Petrescu, Mark Smith, John Spence, 1578 Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela Vanderveen, James 1579 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1580 working groups. Many others have provided guidance over the course 1581 of many years. 1583 11. Contributors 1585 The following individuals have contributed to this document: 1587 Eric Fleischman (eric.fleischman@boeing.com) 1588 Thomas Henderson (thomas.r.henderson@boeing.com) 1589 Steven Russert (steven.w.russert@boeing.com) 1590 Seung Yi (seung.yi@boeing.com) 1592 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1593 of the document. 1595 Jim Bound's foundational work on enterprise networks provided 1596 significant guidance for this effort. We mourn his loss and honor 1597 his contributions. 1599 12. References 1601 12.1. Normative References 1603 [I-D.templin-intarea-seal] 1604 Templin, F., "The Subnetwork Encapsulation and Adaptation 1605 Layer (SEAL)", draft-templin-intarea-seal-08 (work in 1606 progress), January 2010. 1608 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1609 September 1981. 1611 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1612 RFC 792, September 1981. 1614 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1615 converting network protocol addresses to 48.bit Ethernet 1616 address for transmission on Ethernet hardware", STD 37, 1617 RFC 826, November 1982. 1619 [RFC1035] Mockapetris, P., "Domain names - implementation and 1620 specification", STD 13, RFC 1035, November 1987. 1622 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1623 RFC 2131, March 1997. 1625 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1626 (IPv6) Specification", RFC 2460, December 1998. 1628 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1629 Defeating Denial of Service Attacks which employ IP Source 1630 Address Spoofing", BCP 38, RFC 2827, May 2000. 1632 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1633 Update", RFC 3007, November 2000. 1635 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1636 and M. Carney, "Dynamic Host Configuration Protocol for 1637 IPv6 (DHCPv6)", RFC 3315, July 2003. 1639 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1640 "DNS Extensions to Support IP Version 6", RFC 3596, 1641 October 2003. 1643 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1644 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1645 December 2003. 1647 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1648 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1650 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1651 RFC 3972, March 2005. 1653 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1654 More-Specific Routes", RFC 4191, November 2005. 1656 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1657 Architecture", RFC 4291, February 2006. 1659 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1660 Message Protocol (ICMPv6) for the Internet Protocol 1661 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1663 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1664 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1665 September 2007. 1667 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1668 Address Autoconfiguration", RFC 4862, September 2007. 1670 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1671 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1672 March 2008. 1674 12.2. Informative References 1676 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1677 Switching Networks", May 1974. 1679 [I-D.cheshire-dnsext-multicastdns] 1680 Cheshire, S. and M. Krochmal, "Multicast DNS", 1681 draft-cheshire-dnsext-multicastdns-08 (work in progress), 1682 September 2009. 1684 [I-D.clausen-manet-autoconf-recommendations] 1685 Clausen, T. and U. Herberg, "MANET Router Configuration 1686 Recommendations", 1687 draft-clausen-manet-autoconf-recommendations-00 (work in 1688 progress), February 2009. 1690 [I-D.clausen-manet-linktype] 1691 Clausen, T., "The MANET Link Type", 1692 draft-clausen-manet-linktype-00 (work in progress), 1693 October 2008. 1695 [I-D.droms-dhc-dhcpv6-default-router] 1696 Droms, R. and T. Narten, "Default Router and Prefix 1697 Advertisement Options for DHCPv6", 1698 draft-droms-dhc-dhcpv6-default-router-00 (work in 1699 progress), March 2009. 1701 [I-D.hain-ipv6-ulac] 1702 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1703 IPv6 Unicast Unique Local Address Prefixes", 1704 draft-hain-ipv6-ulac-01 (work in progress), October 2009. 1706 [I-D.ietf-autoconf-manetarch] 1707 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1708 Network Architecture", draft-ietf-autoconf-manetarch-07 1709 (work in progress), November 2007. 1711 [I-D.ietf-csi-proxy-send] 1712 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1713 ND Support for SEND", draft-ietf-csi-proxy-send-01 (work 1714 in progress), July 2009. 1716 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 1717 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 1718 Assignment Notification (RAAN) Option", 1719 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 1720 progress), July 2009. 1722 [I-D.ietf-dhc-subnet-alloc] 1723 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1724 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-10 1725 (work in progress), November 2009. 1727 [I-D.ietf-grow-va] 1728 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1729 L. Zhang, "FIB Suppression with Virtual Aggregation", 1730 draft-ietf-grow-va-01 (work in progress), October 2009. 1732 [I-D.ietf-lisp] 1733 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1734 "Locator/ID Separation Protocol (LISP)", 1735 draft-ietf-lisp-06 (work in progress), January 2010. 1737 [I-D.ietf-manet-smf] 1738 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1739 draft-ietf-manet-smf-09 (work in progress), July 2009. 1741 [I-D.ietf-v6ops-tunnel-security-concerns] 1742 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1743 Concerns With IP Tunneling", 1744 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1745 progress), October 2008. 1747 [I-D.jen-apt] 1748 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1749 L. Zhang, "APT: A Practical Transit Mapping Service", 1750 draft-jen-apt-01 (work in progress), November 2007. 1752 [I-D.nakibly-v6ops-tunnel-loops] 1753 Nakibly, G., "Routing Loops using ISATAP and 6to4: Problem 1754 Statement and Proposed Solutions", 1755 draft-nakibly-v6ops-tunnel-loops-00 (work in progress), 1756 October 2009. 1758 [I-D.russert-rangers] 1759 Russert, S., Fleischman, E., and F. Templin, "RANGER 1760 Scenarios", draft-russert-rangers-01 (work in progress), 1761 September 2009. 1763 [I-D.templin-isatap-dhcp] 1764 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1765 Option for the Intra-Site Automatic Tunnel Addressing 1766 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1767 progress), December 2009. 1769 [I-D.templin-ranger] 1770 Templin, F., "Routing and Addressing in Next-Generation 1771 EnteRprises (RANGER)", draft-templin-ranger-09 (work in 1772 progress), October 2009. 1774 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1775 July 1978. 1777 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1778 Protocol Specification", October 2008. 1780 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1781 Communication Layers", STD 3, RFC 1122, October 1989. 1783 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1784 September 1991. 1786 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1787 Routing and Addressing Architecture", RFC 1753, 1788 December 1994. 1790 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1791 E. Lear, "Address Allocation for Private Internets", 1792 BCP 5, RFC 1918, February 1996. 1794 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1795 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1797 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1798 October 1996. 1800 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1801 Extensions", RFC 2132, March 1997. 1803 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1804 over Non-Broadcast Multiple Access (NBMA) networks", 1805 RFC 2491, January 1999. 1807 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1808 (MANET): Routing Protocol Performance Issues and 1809 Evaluation Considerations", RFC 2501, January 1999. 1811 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1812 Domains without Explicit Tunnels", RFC 2529, March 1999. 1814 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1815 February 2000. 1817 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1818 via IPv4 Clouds", RFC 3056, February 2001. 1820 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1821 Networks", BCP 84, RFC 3704, March 2004. 1823 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1824 RFC 3753, June 2004. 1826 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1827 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1828 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1829 RFC 3819, July 2004. 1831 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1832 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1833 May 2005. 1835 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1836 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1837 September 2005. 1839 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1840 Addresses", RFC 4193, October 2005. 1842 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1843 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1845 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1846 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1848 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1849 Internet Protocol", RFC 4301, December 2005. 1851 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1852 Network Address Translations (NATs)", RFC 4380, 1853 February 2006. 1855 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1856 Proxies (ND Proxy)", RFC 4389, April 2006. 1858 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1859 Multicast Name Resolution (LLMNR)", RFC 4795, 1860 January 2007. 1862 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1863 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1864 Focus", RFC 4852, April 2007. 1866 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1867 June 2007. 1869 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1870 Extensions for Stateless Address Autoconfiguration in 1871 IPv6", RFC 4941, September 2007. 1873 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1874 for IPv6", RFC 5340, July 2008. 1876 Appendix A. Duplicate Address Detection (DAD) Considerations 1878 A priori uniqueness determination (also known as "pre-service DAD") 1879 for an RLOC assigned on an enterprise-interior interface would 1880 require either flooding the entire enterprise or somehow discovering 1881 a link in the enterprise on which a node that configures a duplicate 1882 address is attached and performing a localized DAD exchange on that 1883 link. But, the control message overhead for such an enterprise-wide 1884 DAD would be substantial and prone to false-negatives due to packet 1885 loss and intermittent connectivity. An alternative to pre-service 1886 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1887 interfaces and employ a passive in-service DAD (e.g., one that 1888 monitors routing protocol messages for duplicate assignments). 1890 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1891 CGAs, IPv6 privacy addresses, etc. with very small probability of 1892 collision. Pseudo-random IPv4 RLOCs can be generated through random 1893 assignment from a suitably large IPv4 prefix space. 1895 Consistent operational practices can assure uniqueness for EBG- 1896 aggregated addresses/prefixes, while statistical properties for 1897 pseudo-random address self-generation can assure uniqueness for the 1898 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1899 RLOC delegation authority should be used when available, while a 1900 passive in-service DAD mechanism should be used to detect RLOC 1901 duplications when there is no RLOC delegation authority. 1903 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1905 For each distinct enterprise that it connects to, an EBR configures a 1906 VET interface over possibly multiple underlying interfaces that all 1907 connect to the same enterprise. The VET interface therefore 1908 represents the EBR's logical point of attachment to the enterprise, 1909 and provides a logical interface for link-layer multiplexing over its 1910 underlying interfaces as described in Section 3.3.4.1 of [RFC1122]: 1912 "Finally, we note another possibility that is NOT multihoming: one 1913 logical interface may be bound to multiple physical interfaces, in 1914 order to increase the reliability or throughput between directly 1915 connected machines by providing alternative physical paths between 1916 them. For instance, two systems might be connected by multiple 1917 point-to-point links. We call this "link-layer multiplexing". 1918 With link-layer multiplexing, the protocols above the link layer 1919 are unaware that multiple physical interfaces are present; the 1920 link-layer device driver is responsible for multiplexing and 1921 routing packets across the physical interfaces." 1923 EBRs can support such a link-layer multiplexing capability across the 1924 enterprise in accordance with the Weak End System Model (see Section 1925 3.3.4.2 of [RFC1122]). In particular, when an EBR autoconfigures an 1926 RLOC address (see Section 5.1), it can associate it with the VET 1927 interface only instead of assigning it to an underlying interface. 1928 The EBR therefore only needs to obtain a single RLOC address even if 1929 there are multiple underlying interfaces, i.e., it does not need to 1930 obtain one for each underlying interface. The EBR can then leave the 1931 underlying interfaces unnumbered, or it can configure a randomly 1932 chosen IP link-local address (e.g., from the prefix 169.254/16 1933 [RFC3927] for IPv4) on underlying interfaces that require a 1934 configuration. The EBR need not check these link-local addresses for 1935 uniqueness within the enterprise, as they will not normally be used 1936 as the source address for packets. 1938 When the EBR engages in the enterprise-interior routing protocol, it 1939 uses the RLOC address assigned to the VET interface as the source 1940 address for all routing protocol control messages, however it must 1941 also supply an interface identifier (e.g., a small integer) that 1942 uniquely identifies the underlying interface that the control message 1943 is sent over. For example, if the underlying interfaces are known as 1944 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1945 sends a routing protocol control message over the "eth7" interface. 1946 This is necessary to ensure that other routers can determine the 1947 specific interface over which the EBR's routing protocol control 1948 message was sent, but the token need only be unique within the EBR 1949 itself and need not be unique throughout the enterprise. 1951 When the EBR discovers an RLOC route via the enterprise interior 1952 routing protocol, it configures a preferred route in the IP FIB that 1953 points to the VET interface instead of the underlying interface. At 1954 the same time, the EBR also configures an ancillary route that points 1955 to the underlying interface. If the EBR discovers that the same RLOC 1956 route is reachable via multiple underlying interfaces, it configures 1957 multiple ancillary routes (i.e., one for each interface). If the EBR 1958 discovers that the RLOC route is no longer reachable via any 1959 underlying interface, it removes the route in the IP FIB that points 1960 to the VET interface. 1962 With these arrangements, all locally-generated packets with RLOC 1963 destinations will flow through the VET interface (and thereby use the 1964 VET interface's RLOC address as the source address) instead of 1965 through the underlying interfaces. In the same fashion, all 1966 forwarded packets with RLOC destinations will flow through the VET 1967 interface instead of through the underlying interfaces. 1969 This arrangement has several operational advantages that enable a 1970 number of traffic engineering capabilities. First, the VET interface 1971 can insert the SEAL header so that ID-based duplicate packet 1972 detection is enabled within the enterprise. Secondly, SEAL can 1973 dynamically adjust its packet sizing parameters so that an optimum 1974 Maximum Transmission Unit (MTU) can be determined. This is true even 1975 if the VET interface reroutes traffic between underlying interfaces 1976 with different MTUs. 1978 Most importantly, the EBR can configure default and more-specific 1979 routes on the VET interface to direct traffic through a specific 1980 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1981 will ensure that a specific eEBR is chosen, and the best eEBR can be 1982 chosen when multiple are available. Also, local applications see a 1983 stable IP source address even if there are multiple underlying 1984 interfaces. This link-layer multiplexing can therefore provide 1985 continuous operation across failovers between multiple links attached 1986 to the same enterprise without any need for readdressing. Finally, 1987 the VET interface can forward packets with RLOC-based destinations 1988 over an underlying interface without any encapsulation if 1989 encapsulation avoidance is desired. 1991 It must be specifically noted that the above arrangement constitutes 1992 a case in which the same RLOC may be used as both the inner and outer 1993 IP source address. This will not present a problem as long as both 1994 ends configure a VET interface in the same fashion. 1996 It must also be noted that EID-based communications can use the same 1997 VET interface arrangement, except that the EID-based next hop must be 1998 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1999 within IPvX encapsulation, as well as for IPv4 within IPv6 2000 encapsulation, this requires a VET interface specific address mapping 2001 database. For IPv6 within IPv4 encapsulation, the mapping is 2002 accomplished through simple static extraction of an IPv4 address 2003 embedded in a VET address. 2005 Appendix C. Anycast Services 2007 Some of the IPv4 addresses that appear in the Potential Router List 2008 may be anycast addresses, i.e., they may be configured on the VET 2009 interfaces of multiple EGBRs/EBGs. In that case, each VET router 2010 interface that configures the same anycast address must provide 2011 equivalent packet forwarding and IPv6 Neighbor Discovery services. 2013 Use of an anycast address as the IP destination address of tunneled 2014 packets can have subtle interactions with tunnel path MTU and 2015 neighbor discovery. For example, if the initial fragments of a 2016 fragmented tunneled packet with an anycast IP destination address are 2017 routed to different egress tunnel endpoints than the remaining 2018 fragments, the multiple endpoints will be left with incomplete 2019 reassembly buffers. This issue can be mitigated by ensuring that 2020 each egress tunnel endpoint implements a proactive reassembly buffer 2021 garbage collection strategy. Additionally, ingress tunnel endpoints 2022 that send packets with an anycast IP destination address must use the 2023 minimum path MTU for all egress tunnel endpoints that configure the 2024 same anycast address as the tunnel MTU. Finally, ingress tunnel 2025 endpoints should treat ICMP unreachable messages from a router within 2026 the tunnel as at most a weak indication of neighbor unreachability, 2027 since the failures may only be transient and a different path to an 2028 alternate anycast router quickly selected through reconvergence of 2029 the underlying routing protocol. 2031 Use of an anycast address as the IP source address of tunneled 2032 packets can lead to more serious issues. For example, when the IP 2033 source address of a tunneled packet is anycast, ICMP messages 2034 produced by routers within the tunnel might be delivered to different 2035 ingress tunnel endpoints than the ones that produced the packets. In 2036 that case, functions such as path MTU discovery and neighbor 2037 unreachability detection may experience non-deterministic behavior 2038 that can lead to communications failures. Additionally, the 2039 fragments of multiple tunneled packets produced by multiple ingress 2040 tunnel endpoints may be delivered to the same reassembly buffer at a 2041 single egress tunnel endpoint. In that case, data corruption may 2042 result due to fragment misassociation during reassembly. 2044 In view of these considerations, EBRs/EBGs that configure an anycast 2045 address should also configure one or more unicast addresses from the 2046 Potential Router List; they should further accept tunneled packets 2047 destined to any of their anycast or unicast addresses, but should 2048 send tunneled packets using a unicast address as the source address. 2049 In order to influence traffic to use an anycast route (and thereby 2050 leverage the natural fault tolerance afforded by anycast), ISATAP 2051 routers should set higher preferences on the default routes they 2052 advertise using an anycast address as the source and set lower 2053 preferences on the default routes they advertise using a unicast 2054 address as the source (see: [RFC4191]). 2056 Appendix D. Change Log 2058 (Note to RFC editor - this section to be removed before publication 2059 as an RFC.) 2061 Changes from -07 to -08: 2063 o Specified the approach to global mapping using virtual aggregation 2064 and BGP 2066 Changes from -06 to -07: 2068 o reworked redirect function 2070 o created new section on VET interface encapsulation 2072 o clarifications on nexthop selection 2074 o fixed several bugs 2076 Changed from -05 to -06: 2078 o reworked VET interface ND 2080 o anycast clarifications 2082 Changes from -03 to -04: 2084 o security consideration clarifications 2086 Changes from -02 to -03: 2088 o security consideration clarifications 2090 o new PRLNAME for VET is "isatav2.example.com" 2091 o VET now uses SEAL natively 2093 o EBGs can support both legacy ISATAP and VET over the same 2094 underlying interfaces. 2096 Changes from -01 to -02: 2098 o Defined CGA and privacy address configuration on VET interfaces 2100 o Interface identifiers added to routing protocol control messages 2101 for link-layer multiplexing 2103 Changes from -00 to -01: 2105 o Section 4.1 clarifications on link-local assignment and RLOC 2106 autoconfiguration. 2108 o Appendix B clarifications on Weak End System Model 2110 Changes from RFC5558 to -00: 2112 o New appendix on RLOC configuration on VET interfaces. 2114 Author's Address 2116 Fred L. Templin (editor) 2117 Boeing Research & Technology 2118 P.O. Box 3707 MC 7L-49 2119 Seattle, WA 98124 2120 USA 2122 Email: fltemplin@acm.org