idnits 2.17.1 draft-templin-intarea-vet-07.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 2 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 950: '...n each RA, but it MUST NOT include any...' RFC 2119 keyword, line 972: '...r possible, however , it SHOULD send a...' RFC 2119 keyword, line 989: '...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 21, 2010) is 5181 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 1577, but no explicit reference was found in the text == Unused Reference: 'RFC3007' is defined on line 1590, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 1597, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1664, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-dhcpv6-agentopt-delegate' is defined on line 1674, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1770, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1776, 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 (-24) exists of draft-ietf-lisp-05 == 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 (~~), 21 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 21, 2010 5 Expires: July 25, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-07.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 25, 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 . . . . . . . . . . . . . . . . . . . . 20 84 6.3. VET interface Neighbor Discovery . . . . . . . . . . . . . 20 85 6.3.1. Router and Prefix Discovery . . . . . . . . . . . . . 21 86 6.3.2. Next Hop Determination . . . . . . . . . . . . . . . . 25 87 6.3.3. Redirect Function . . . . . . . . . . . . . . . . . . 25 88 6.3.4. Neighbor Unreachability Detection . . . . . . . . . . 27 89 6.3.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 27 90 6.3.6. IPv4 Neighbor Discovery . . . . . . . . . . . . . . . 28 91 6.4. Generating Errors . . . . . . . . . . . . . . . . . . . . 28 92 6.5. Processing Errors . . . . . . . . . . . . . . . . . . . . 28 93 6.6. Mobility and Multihoming Considerations . . . . . . . . . 29 94 6.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 30 95 6.8. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 96 6.9. Enterprise Partitioning . . . . . . . . . . . . . . . . . 31 97 6.10. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 32 98 6.11. Support for Legacy ISATAP Services . . . . . . . . . . . . 32 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 101 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 33 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 103 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 107 Appendix A. Duplicate Address Detection (DAD) Considerations . . 40 108 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 41 109 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 43 110 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 44 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 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 EBRs use the list of EBGs in the PRL (see: Section 5.2.2) as an 868 initial list of neighbors for inter-enterprise routing protocol 869 participation. Routing protocol participation on non-multicast VET 870 interfaces uses the NBMA model, e.g., in the same manner as for OSPF 871 over NBMA interfaces [RFC5340]. 873 6.2. Address Selection 875 When permitted by policy and supported by enterprise interior 876 routing, end systems can avoid VET interface encapsulation through 877 communications that directly invoke the outer IP protocol using RLOC 878 addresses instead of EID addresses for end-to-end communications. 879 For example, an enterprise that provides native IPv4 internal network 880 services can provide continued support for native IPv4 communications 881 even when encapsulated IPv6 services are available for inter- 882 enterprise communications. In other enterprise scenarios, the use of 883 EID-based communications (i.e., instead of RLOC-based communications) 884 may be necessary and/or beneficial to support address scaling, NAT 885 avoidance, security domain separation, site multihoming, traffic 886 engineering, etc. . 888 End systems can use source address selection rules to determine 889 whether to use EID-based or RLOC-based addressing based on, e.g., 890 name service information. The remainder of this section discusses 891 internetworking operation for EID-based communications using the VET 892 interface abstraction. 894 6.3. VET interface Neighbor Discovery 896 The following sections discuss IPv6 Neighbor Discovery (ND) 897 considerations for VET interfaces for the case of IPv6 as the inner 898 IP protocol and IPv4 as the outer IP protocol (ND considerations for 899 other protocol combinations are out of scope). Depending on the 900 enterprise network trust basis, VET nodes may be required to use 901 mechanisms such as SEND to secure their ND exchanges. 903 6.3.1. Router and Prefix Discovery 905 6.3.1.1. EBR Specification 907 EBRs discover the PRL for each VET interface as specified in 908 Section 5.2.2, and participate in a dynamic routing protocol over the 909 VET interface using the EBG addresses in the PRL as addresses of 910 potential neighboring routers. When a dynamic routing protocol 911 cannot be used, EBRs instead send RS messages on their VET interfaces 912 to receive solicited RAs from each EBG in the PRL. (Note that this 913 will cause the EBG to set the 'IsRouter' flag in the neighbor cache 914 entry for this EBR to FALSE - see: [RFC4861], Appendix D.) 916 The EBR sends RS messages the same as described for hosts in Section 917 6.3.7 of [RFC4861], except that it includes a new 2-bit "More- 918 Specific Routes (MSR)" field taken from the most significant bits of 919 the "Reserved" field in the RS message (see Section 4.1 of [RFC4861]) 920 as shown in Figure 2 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Code | Checksum | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 |MSR| Reserved | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Figure 2: Router Solicitation "MSR" Field 932 In this format, the values MSR=0, 1 and 2 correspond to the host 933 types A, B, and C (respectively) as defined in Section 3 of 934 [RFC4191]. The value MSR=3 is Reserved for future use. For the 935 purpose of this specification, EBRs set MSR=2 in each RS message they 936 send. 938 When the EBR receives a solicited RA from an EBG (see Section 939 6.3.1.2), it authenticates the message then processes any 940 autoconfiguration information. (Note however that the EBR should not 941 configure prefixes received in Prefix Information Options (PIOs) on 942 its VET interfaces if it will have EID addresses and prefixes 943 configured on any of its other interfaces. This prevents the EBR 944 from sending packets directly to VET hosts without first going 945 through a default router, since VET hosts will initially only accept 946 routed packets that come through a PRL router.) 948 Next, the EBR creates RA messages to send to each EBG in the PRL. 949 The EBR includes Route Information Options (RIOs) [RFC4191] that 950 contain its EID prefixes in each RA, but it MUST NOT include any 951 other autoconfiguration parameters (e.g., non-zero Router Lifetime, 952 Prefix Information Options (PIOs), etc.) The EBR also 953 unconditionally sets the 'M' bit to 0 and the 'O' bit to 1 in order 954 to avoid conflicting with the information included in RA messages 955 from EBGs (see: Section 6.3.1.2). The EBR also includes an RLOC for 956 the EBG as the outer IP destination address and includes the IPv6 957 link-local "all nodes multicast" address as the inner IP destination 958 address [RFC4291] of the RA. 960 The EBR next creates a CGA or IPv6 privacy link-local address and 961 includes it as the inner IP source address of the RA. When CGAs are 962 used, the EBR additionally includes SEND credentials plus any router 963 certificates needed to prove its ownership of the prefixes in its 964 Route Information Options (RIOs). Note that the CGA/privacy link- 965 local address is used only as the inner source address of unsolicited 966 RA messages, and therefore need not be checked for uniqueness on the 967 link. The EBR finally includes the RLOC assigned to an underlying 968 interface as the outer source address of the RA. 970 If the EBR has multiple RLOC addresses assigned to underlying 971 interfaces, it can send multiple RA messages to each EBG (each with a 972 different RLOC). Whenever possible, however , it SHOULD send a 973 single RA message to each EBG that includes multiple Source Link 974 Layer Address Options (SLLAOs) formatted using a modified version of 975 the form specified in Section 5 of [RFC2529] as shown in Figure 3: 977 +-------+-------+-------+-------+-------+-------+-------+-------+ 978 | Type |Length | Metric | IPv4 RLOC Address | 979 +-------+-------+-------+-------+-------+-------+-------+-------+ 981 Figure 3: VET Link-Layer Address Option Format 983 Each SLLAO contains the IPv4 RLOC of an underlying interface plus a 984 metric value that specifies a weighted preference for this particular 985 RLOC based on link bandwidth, stability, etc., where the value 0 986 denotes the highest preference and 65535 denotes the lowest 987 preference. For example, the EBR may set the metric for an RLOC 988 corresponding to a 1Gbps interface to 10 and the metric for an RLOC 989 corresponding to a WiFi interface to 1000. The EBR SHOULD include 990 the highest preference RLOC as the final RLOC in the list of SLLAOs. 992 The EBR then sends the RA message(s) to the EBG and must thereafter 993 periodically send new RA messages to refresh prefix lifetimes, where 994 an RA interval of 120 seconds is recommended. Each EBG that receives 995 an EBR's RA will in turn relay a proxied version of the RA to EBGs on 996 their parent enterprises. This procedure has a direct analogy in the 997 Teredo method of maintaining state in network middleboxes through the 998 periodic transmission of "bubbles" [RFC4380]. 1000 6.3.1.2. EBG Specification 1002 EBGs follow the router and prefix discovery procedures specified in 1003 Section 8.2 of [RFC5214]. When an EBG receives an RS message on a 1004 VET interface, it first authenticates the message. If the VET 1005 interface maintains a neighbor cache, the EBG next creates or updates 1006 a neighbor cache entry for the VET link-local source address 1007 corresponding to the outer IP source address of the RS according to 1008 Section 6.2.6 of [RFC4861] and caches the value in the MSR field 1009 (see: Section 6.3.1.1). 1011 If the neighbor cache entry cannot be created or updated (e.g., due 1012 to insufficient resources), the EBG silently discards the RS and does 1013 not send an RA. Otherwise, the EBG creates/updates the neighbor 1014 cache entry, sets a "Time To Live (TTL)" on the entry that is no 1015 shorter than any of its advertised router or prefix lifetimes, and 1016 sends an RA response to the RS. If the neighbor cache entry TTL 1017 subsequently expires before a new RS arrives, the EBG deletes the 1018 neighbor cache entry. Note that the EBG can omit these neighbor 1019 cache manipulations if no neighbor cache is required; in that case, 1020 however, no value for MSR will be cached and a default value of 0 is 1021 assumed. 1023 The EBG then prepares an RA response to the RS that includes Router 1024 Lifetimes, PIOs, and any other options/parameters that the EBG is 1025 configured to include. The EBG unconditionally sets the 'M' bit to 0 1026 and the 'O' bit to 1. Next, the EBG includes SEND parameters if 1027 necessary and sets the inner and outer IP source and destination 1028 addresses. The EBG sets the inner IP source address to a CGA or IPv6 1029 privacy link-local address, then sets the outer IP source address to 1030 one of its RLOC addresses. The EBG next sets the inner IP 1031 destination address to the source address in the RS message, then 1032 sets the outer IP destination address to the EBR's RLOC address. 1033 Finally, the EBG sends the solicited RA to the VET node that sent the 1034 solicitation. 1036 In addition to RS messages, the EBG will receive RA messages sent by 1037 EBRs on VET interfaces as specified in Section 6.3.1.1. When an EBG 1038 receives the RA, it first authenticates the message; if the 1039 authentication fails, the EBG discards the RA. Otherwise, the EBG 1040 uses any EID prefixes in RIOs with their respective lifetimes to 1041 updates its Forwarding Information Base (FIB). The EBG also caches 1042 each RLOC and associated metric value received in SLLAO options in 1043 the RA message as the address of a neighbor associated with the FIB 1044 entry, i.e., each FIB entry may include multiple potential next-hops. 1045 Finally, the EBG caches the RA message as ancillary data attached to 1046 the FIB entries so that the message can be replayed in the future to 1047 support router-to-router redirects (see: Section 6.3.3). 1049 After the EBG authenticates the RA and updates its FIB, it next acts 1050 as a Neighbor Discovery Proxy (NDProxy) [RFC4389] on the VET 1051 interfaces configured over any of its parent enterprises, and relays 1052 a proxied RA to the EBGs on those interfaces. (For enterprises that 1053 use SEND, the EBG additionally acts as a SEcure Neighbor Discovery 1054 Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) During this process, 1055 the EBG replaces the SLLAO options received in the original RA 1056 message with SLLAO options that encode its own RLOC addresses and 1057 metrics. EBGs in parent enterprises that receive the proxied RAs in 1058 turn act as NDProxys/SENDProxys to relay the RAs to EBGs on their 1059 parent enterprises, etc. The RA proxying recurses in this fashion 1060 and ends when an EBR attached to an interdomain routing core is 1061 reached. 1063 6.3.1.3. VET Host Specification 1065 VET hosts follow the router and prefix discovery procedures specified 1066 in Section 8.3 of [RFC5214]. They discover the addresses of EBGs for 1067 each VET interface as specified in Section 5.2.2, and send RS 1068 messages to each EBG in order to receive RAs with autoconfiguration 1069 information. When the VET host sends an RS message on a VET 1070 interface, it sets the MSR field based on whether the host will act 1071 as an [RFC4191] type A, B or C host; if the host is willing to 1072 process RIO options and receive prefix redirects, it sets the value 1073 MSR=2 (see: Section 6.3.1.1). 1075 When the VET host receives a solicited RA from an EBG on a VET 1076 interface, it authenticates the message then performs 1077 autoconfiguration the same as for any link. In particular, if the RA 1078 message contains any PIO options the VET host performs address 1079 autoconfiguration on the VET interface according to [RFC4862]. When 1080 the host generates a VET address, it first creates an interface 1081 identifier that embeds its IPv4 RLOC address as specified in Section 1082 6.1 of [RFC5214]. The host then configures IPv6 unicast VET 1083 addresses from advertised on-link prefixes received in RA messages 1084 and assigns them to the VET interface, i.e., it does not perform 1085 Duplicate Address Detection (DAD) on the addresses since the embedded 1086 IPv4 RLOC address already provides uniqueness. 1088 6.3.2. Next Hop Determination 1090 VET nodes perform next-hop determination on VET interfaces via 1091 longest prefix match the same as for any IPv6 interface, and send 1092 packets according to the most-specific matching entry in the FIB. If 1093 the FIB entry has multiple next-hop addresses, the EBR selects the 1094 next-hop with the best metric value. If there are multiple next hops 1095 with the best metric value, the VET node can use Equal Cost Multi 1096 Path (ECMP) to forward different flows via different next-hop 1097 addresses (where flows are determined, e.g., by computing a hash of 1098 the inner packet's IPv6 source address, destination address and flow 1099 label fields). 1101 When there is no matching entry in the FIB (i.e., not even 1102 "default"), VET nodes can discover next-hop addresses within the 1103 enterprise by querying the name service for the /56 IPv6 EID prefix 1104 taken from a packet's destination address (or, by some other inner-IP 1105 to outer-IP address mapping mechanism). For example, for the IPv6 1106 destination address '2001:DB8:1:2::1' and 'PRLNAME' 1107 "isatapv2.example.com" the VET node can perform a name service lookup 1108 for the domain name: 1109 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 1111 Name-service lookups in enterprises with a centralized management 1112 structure use an infrastructure-based service, e.g., an enterprise- 1113 local DNS. Name-service lookups in enterprises with a distributed 1114 management structure and/or that lack an infrastructure-based name 1115 service instead use LLMNR over the VET interface. When LLMNR is 1116 used, the EBR that performs the lookup sends an LLMNR query (with the 1117 /56 prefix taken from the IP destination address encoded in dotted- 1118 nibble format as shown above) and accepts the union of all replies it 1119 receives from other EBRs on the VET interface. When an EBR receives 1120 an LLMNR query, it responds to the query IFF it aggregates an IP 1121 prefix that covers the prefix in the query. 1123 If the name-service lookup succeeds, it will return RLOC addresses 1124 (e.g., in DNS A records) that correspond to next-hop EBRs to which 1125 the VET node can forward packets. 1127 6.3.3. Redirect Function 1129 In enterprises with a stable and highly-available set of EBGs, VET 1130 nodes can simply forward initial packets via a default route to an 1131 EBG on a VET interface when more-specific routing information is not 1132 available. The EBG will forward the packet and return a standard 1133 ICMPv6 Redirect if necessary as specified in Section 8 of [RFC4861]. 1134 VET interfaces additionally implement an "MSR Redirect" mechanism 1135 that provides both "router-to-router" and "prefix" redirection 1136 functions as specified within this section. These additional 1137 functions are complimentary (i.e., both functions can be carried 1138 within the same redirect message) but can only be used when both the 1139 destination of the redirect and the redirected target set MSR=2 in 1140 the RS messages they send to the EBG (see: Section 6.3.1.1). 1142 When both parties to the potential redirect set MSR=2, the EBG sends 1143 an MSR Redirect (subject to rate limiting) whenever it forwards a 1144 packet out the same VET interface that the packet arrived on if the 1145 packet's source address is not on-link on the VET interface and/or if 1146 there is a prefix in the EBG's FIB that covers the packet's 1147 destination address. If the source address of the packet was not on- 1148 link on the VET interface, the EBG sets the destination address of 1149 the redirect to the VET link-local address of the VET node that 1150 forwarded the packet. If the EBG has a prefix in its FIB that covers 1151 the destination address of the packet, it also includes in the 1152 redirect an RIO that contains the prefix, i.e., the same as described 1153 for RA messages in [RFC4191]. 1155 The EBG next sets the source address of the MSR Redirect to a CGA or 1156 IPv6 privacy link-local addresses; when SEND is used, the EBG uses a 1157 CGA link-local address and includes SEND parameters. The EBG then 1158 sets the redirected target/destination fields the same as for 1159 ordinary redirects, then includes one or more IPv6 Target Link Layer 1160 Address Options (TLLAOs) formatted using the form shown in Figure 3. 1161 Each TLLAO contains an IPv4 RLOC and metric taken from neighbor cache 1162 entries corresponding to the EBG's FIB entry. Finally, the EBG 1163 includes the header of the redirected packet the same as for an 1164 ordinary redirect and returns the redirect to the VET node that sent 1165 the packet. 1167 When a VET node receives an MSR Redirect, it first authenticates the 1168 message then uses any EID prefixes in RIOs with their respective 1169 lifetimes to updates its FIB. The node also caches each RLOC and 1170 associated metric value received in TLLAO options in redirect as the 1171 address of a neighbor associated with the FIB entry. If the redirect 1172 was a "router-to-router" redirect, the VET node next "replays" the 1173 cached RA message associated with the FIB entry corresponding to the 1174 packet's source address by proxying the message with the RLOC address 1175 from the redirected target as its outer IP destination address and 1176 with SLLAO options that encode the RLOCs and metrics of its 1177 underlying interfaces. This proxying process is otherwise the same 1178 as specified for EBGs in Section 6.3.1.2. 1180 When the redirected target VET node receives the replayed RA, it 1181 authenticates the message (e.g., using SEND credentials) then uses 1182 any EID prefixes in RIOs with their respective lifetimes to updates 1183 its FIB. The node also caches each RLOC and associated metric value 1184 received in TLLAO options in the RA message as the address of a 1185 neighbor associated with the FIB entry. This RA processing is same 1186 as specified for EBGs in Section 6.3.1.2, however the node does not 1187 proxy the RA message further. 1189 VET nodes retain the FIB entries created as a result of receipt of an 1190 ICMP redirect until the route lifetimes expire, or until no hints of 1191 forward progress through any of the FIB entry's associated RLOCs are 1192 received. In this way, RLOC liveness detection exactly parallels 1193 IPv6 Neighbor Unreachability Detection ([RFC4861], Section 7). 1195 6.3.4. Neighbor Unreachability Detection 1197 VET nodes use their neighbor cache for Neighbor Unreachability 1198 Detection (NUD) the same as for any IPv6 link as described in Section 1199 7 of [RFC4861]. When a neighbor fails (or appears to be failing), 1200 FIB entries are updated to select a different next-hop when there are 1201 multiple next-hops available. 1203 The NUD mechanism uses hints of forward progress (i.e., evidence that 1204 the tunnel neighbor is receiving packets) coupled with the Neighbor 1205 Solicitation/Advertisement (NS/NA) process. When hints of forward 1206 progress are available, NS/NA messaging is suppressed; when no hints 1207 are available, NS/NA messages are used in the normal fashion the same 1208 as for any IPv6 link. The SEAL mechanism includes an explicit data 1209 packet acknowledgement mechanism that can provide hints of forward 1210 progress. 1212 Responsiveness to routing changes is directly related to the 1213 "REACHABLE_TIME" constant used for NUD as specified in [RFC4861]. In 1214 order to provide responsiveness comparable to dynamic routing 1215 protocols, a reasonably short "REACHABLE_TIME" value (e.g., 5sec) 1216 should be used. 1218 6.3.5. Reverse Path Forwarding Checks 1220 VET nodes determine whether a packet received on a VET interface can 1221 be accepted based on an ingress filtering check [RFC3704]. The VET 1222 node determines the previous hop router for a received packet by 1223 constructing a VET link-local address that embeds the outer IPv4 1224 source address. It then examines its FIB to determine whether there 1225 is an entry that matches the inner IPv6 source address and that has 1226 the VET link-local address as the next hop. If such a FIB entry 1227 exists, the VET host accepts the packet; otherwise, it discards the 1228 packet. 1230 6.3.6. IPv4 Neighbor Discovery 1232 When IPv4 is used as the inner IP protocol, router discovery and 1233 prefix registration exactly parallel the mechanisms specified for 1234 IPv6 in Section 6.3. To support this, modifications to the ICMPv4 1235 Router Advertisement [RFC1256] function to include SEND constructs 1236 and modifications to the ICMPv4 Redirect [RFC0792] function to 1237 support router-to-router redirects will be specified in a future 1238 document. Additionally, publications for IPv4 prefixes will be in 1239 dotted-nibble format in the 'ip4.isatapv2.example.com' domain. For 1240 example, the IPv4 prefix 192.0.2/24 would be represented as: 1241 '2.0.0.0.0.c.ip4.isatapv2.example.com' 1243 6.4. Generating Errors 1245 When an EBR receives an IPv6 packet over a VET interface and there is 1246 no matching ingress filter entry, it drops the packet and returns an 1247 ICMPv6 [RFC4443] "Destination Unreachable; Reject route to 1248 destination" message to the previous-hop EBR subject to rate 1249 limiting. 1251 When an EBR receives an IPv6 packet over a VET interface, and there 1252 is no longest-prefix-match FIB entry for the destination, it returns 1253 an ICMPv6 "Destination Unreachable; No route to destination" message 1254 to the previous hop EBR subject to rate limiting. 1256 When an EBR receives an IPv6 packet over a VET interface and the 1257 longest-prefix-match FIB entry for the destination is via a next-hop 1258 configured over the same VET interface the packet arrived on, the EBR 1259 forwards the packet. If the FIB prefix is longer than ::/0, the EBR 1260 then sends a router-to-router ICMPv6 Redirect message (using SEND, if 1261 necessary) to the previous-hop EBR as specified in Section 6.3.3. 1263 Generation of other ICMP messages [RFC0792] [RFC4443] is the same as 1264 for any IP interface. 1266 6.5. Processing Errors 1268 When a VET node receives an ICMPv6 "Destination Unreachable; Reject 1269 route to destination" message, and there is a longest-prefix-match 1270 FIB entry for the original packet's destination that is more specific 1271 than ::/0, the node discards the message and marks the FIB entry for 1272 the destination as "forwarding suspended" for the RLOC taken from the 1273 source address of the ICMPv6 message. The node should then allow 1274 subsequent packets to flow through different RLOCs associated with 1275 the FIB entry. If the node receives excessive ICMPv6 reject route to 1276 destination messages through multiple RLOCs associated with the same 1277 FIB entry, it should delete the FIB entry and allow subsequent 1278 packets to flow through an EBG if supported in the specific 1279 enterprise scenario. 1281 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1282 to destination" message, it forwards the ICMPv6 message to the source 1283 of the original packet as normal. If the node has a longest-prefix- 1284 match FIB entry for the original packet's destination that is more 1285 specific than ::/0, the node also deletes the FIB entry. 1287 When a VET node receives an authentic ICMPv6 Redirect, it processes 1288 the packet as specified in Section 6.3.3. 1290 Additionally, a VET node may receive outer IP ICMP "Destination 1291 Unreachable; net / host unreachable" messages from an ER on the path 1292 indicating that the path to a VET neighbor may be failing. The node 1293 should first check authenticating information (e.g., the SEAL_ID, 1294 IPsec sequence number, source address of the original packet if 1295 available, etc.) to obtain reasonable assurance that the ICMP message 1296 is authentic, then should mark the longest-prefix-match FIB entry for 1297 the destination as "forwarding suspended" for the RLOC destination 1298 address of the ICMP packet-in-error. If the node receives excessive 1299 ICMP unreachable errors through multiple RLOCs associated with the 1300 same FIB entry, it should delete the FIB entry and allow subsequent 1301 packets to flow through a different route. 1303 6.6. Mobility and Multihoming Considerations 1305 EBRs that travel between distinct enterprise networks must either 1306 abandon their PA prefixes that are relative to the "old" enterprise 1307 and obtain new ones relative to the "new" enterprise or somehow 1308 coordinate with a "home" enterprise to retain ownership of the 1309 prefixes. In the first instance, the EBR would be required to 1310 coordinate a network renumbering event using the new PA prefixes 1311 [RFC4192]. In the second instance, an ancillary mobility management 1312 mechanism must be used. 1314 EBRs can retain their PI prefixes as they travel between distinct 1315 enterprise networks as long as they register the prefixes with new 1316 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1317 departure. Prefix registration with new EBGs is coordinated exactly 1318 as specified in Section 5.2.4; prefix withdrawal from old EBGs is 1319 simply through re-announcing the PI prefixes with zero lifetimes. 1321 Since EBRs can move about independently of one another, stale FIB 1322 entry state may be left in VET nodes when a neighboring EBR departs. 1323 Additionally, EBRs can lose state for various reasons, e.g., power 1324 failure, machine reboot, etc. For this reason, EBRs are advised to 1325 set relatively short PI prefix lifetimes in RIO options, and to send 1326 additional RAs to refresh lifetimes before they expire. (EBRs should 1327 place conservative limits on the RAs they send to reduce congestion, 1328 however.) 1330 EBRs may register their PI prefixes with multiple EBGs for 1331 multihoming purposes. EBRs should only forward packets via EBGs with 1332 which it has registered its PI prefixes, since other EBGs may drop 1333 the packets and return ICMPv6 "Destination Unreachable" messages. 1335 EBRs can also act as delegating routers to sub-delegate portions of 1336 their PI prefixes to requesting routers on their enterprise-edge 1337 interfaces and on VET interfaces for which they are configured as 1338 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1339 become the PA prefixes for downstream-dependent nodes. 1341 The EBGs of a multihomed enterprise should participate in a private 1342 inner IP routing protocol instance between themselves (possibly over 1343 an alternate topology) to accommodate enterprise partitions/merges as 1344 well as intra-enterprise mobility events. These peer EBGs should 1345 accept packets from one another without respect to the destination 1346 (i.e., ingress filtering is based on the peering relationship rather 1347 than a prefix-specific ingress filter entry). 1349 6.7. Multicast 1351 In multicast-capable deployments, ERs provide an enterprise-wide 1352 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1353 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1354 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1355 over their enterprise-interior interfaces such that outer IP 1356 multicast messages of site-scope or greater scope will be propagated 1357 across the enterprise. For such deployments, VET nodes can also 1358 provide an inner IP multicast/broadcast capability over their VET 1359 interfaces through mapping of the inner IP multicast address space to 1360 the outer IP multicast address space. In that case, operation of 1361 link-scoped (or greater scoped) inner IP multicasting services (e.g., 1362 a link-scoped neighbor discovery protocol) over the VET interface is 1363 available, but link-scoped services should be used sparingly to 1364 minimize enterprise-wide flooding. 1366 VET nodes encapsulate inner IP multicast messages sent over the VET 1367 interface in any mid-layer headers (e.g., SEAL, IPsec, etc.) followed 1368 by an outer IP header with a site-scoped outer IP multicast address 1369 as the destination. For the case of IPv6 and IPv4 as the inner/outer 1370 protocols (respectively), [RFC2529] provides mappings from the IPv6 1371 multicast address space to a site-scoped IPv4 multicast address space 1372 (for other encapsulations, mappings are established through 1373 administrative configuration or through an unspecified alternate 1374 static mapping). 1376 Multicast mapping for inner IP multicast groups over outer IP 1377 multicast groups can be accommodated, e.g., through VET interface 1378 snooping of inner multicast group membership and routing protocol 1379 control messages. To support inner-to-outer IP multicast mapping, 1380 the VET interface acts as a virtual outer IP multicast host connected 1381 to its underlying interfaces. When the VET interface detects that an 1382 inner IP multicast group joins or leaves, it forwards corresponding 1383 outer IP multicast group membership reports on an underlying 1384 interface over which the VET interface is configured. If the VET 1385 node is configured as an outer IP multicast router on the underlying 1386 interfaces, the VET interface forwards locally looped-back group 1387 membership reports to the outer IP multicast routing process. If the 1388 VET node is configured as a simple outer IP multicast host, the VET 1389 interface instead forwards actual group membership reports (e.g., 1390 IGMP messages) directly over an underlying interface. 1392 Since inner IP multicast groups are mapped to site-scoped outer IP 1393 multicast groups, the VET node must ensure that the site-scope outer 1394 IP multicast messages received on the underlying interfaces for one 1395 VET interface do not "leak out" to the underlying interfaces of 1396 another VET interface. This is accommodated through normal site- 1397 scoped outer IP multicast group filtering at enterprise boundaries. 1399 6.8. Service Discovery 1401 VET nodes can perform enterprise-wide service discovery using a 1402 suitable name-to-address resolution service. Examples of flooding- 1403 based services include the use of LLMNR [RFC4795] over the VET 1404 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1405 over an underlying interface. More scalable and efficient service 1406 discovery mechanisms are for further study. 1408 6.9. Enterprise Partitioning 1410 An enterprise can be partitioned into multiple distinct logical 1411 groupings. In that case, each partition must configure its own 1412 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1413 'isatapv2.zone2.example.com', etc.). 1415 EBGs can further create multiple IP subnets within a partition by 1416 sending RAs with PIOs containing different IPv6 prefixes to different 1417 groups of nodes. EBGs can identify subnets, e.g., by examining RLOC 1418 prefixes, observing the enterprise interior interfaces over which RSs 1419 are received, etc. 1421 6.10. EBG Prefix State Recovery 1423 EBGs must retain explicit state that tracks the inner IP PA prefixes 1424 delegated to EBRs within the enterprise, e.g., so that packets are 1425 delivered to the correct EBRs. When an EBG loses some or all of its 1426 state (e.g., due to a power failure), it must recover the state so 1427 that packets can be forwarded over correct routes. 1429 6.11. Support for Legacy ISATAP Services 1431 EBGs support legacy ISATAP services according to the specifications 1432 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1433 interfaces and VET interfaces over the same sets of underlying 1434 interface as long as the PRLs and IPv6 prefixes associated with the 1435 ISATAP/VET interfaces are distinct. 1437 7. IANA Considerations 1439 There are no IANA considerations for this document. 1441 8. Security Considerations 1443 Security considerations for MANETs are found in [RFC2501]. 1445 The security considerations found in [RFC2529] [RFC5214] 1446 [I-D.nakibly-v6ops-tunnel-loops] also apply to VET. In particular: 1448 o VET nodes must ensure that a VET interface does not span multiple 1449 sites as specified in Section 6.2 of [RFC5214]. 1451 o VET nodes must verify that the outer IP source address of a packet 1452 received on a VET interface is correct for the inner IP source 1453 address; for the case of IPv6 within IPv4 encapsulation, this is 1454 accommodated using the procedures specified in Section 7.3 of 1455 [RFC5214]. 1457 o EBRs must implement both inner and outer IP ingress filtering in a 1458 manner that is consistent with [RFC2827] as well as ip-proto-41 1459 filtering. When the node at the physical boundary of the 1460 enterprise is an ordinary ER (i.e., and not an EBR), the ER itself 1461 should implement filtering. 1463 Additionally, VET interfaces that use IPv6 within IPv4 encapsulation 1464 and that maintain a coherent neighbor cache drop all outbound packet 1465 for which the IPv6 next hop is not a neighbor and the IPv6 source 1466 address is not link-local; they also drop all incoming packets for 1467 which the IPv6 previous hop is not a neighbor and the IPv6 1468 destination address is not link-local. (Here, the previous hop is 1469 determined by examining the IPv4 source address.) 1471 Finally, VET interfaces that use IPv6 within IPv4 encapsulation drop 1472 all outbound packets for which the IPv6 source address is "foreign- 1473 prefix::0200:5efe:V4ADDR" and drop all incoming packets for which the 1474 IPv6 destination address is "foreign-prefix::0200:5efe:V4ADDR" . 1475 (Here, "foreign-prefix" is an IPv6 prefix that is not assigned to the 1476 VET interface, and "V4ADDR" is a public IPv4 address over which the 1477 VET interface is configured.) Note that these checks are only 1478 required for VET interfaces that cannot maintain a coherent neighbor 1479 cache. 1481 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1482 where attacks on the neighbor discovery protocol are possible. SEAL 1483 [I-D.templin-intarea-seal] provides a per-packet identification that 1484 can be used to detect source address spoofing. 1486 Rogue neighbor discovery messages with spoofed RLOC source addresses 1487 can consume network resources and cause VET nodes to perform extra 1488 work. Nonetheless, VET nodes should not "blacklist" such RLOCs, as 1489 that may result in a denial of service to the RLOCs' legitimate 1490 owners. 1492 9. Related Work 1494 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1495 automatic tunneling in [RFC2529]; this concept was later called: 1496 "Virtual Ethernet" and investigated by Quang Nguyen under the 1497 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1498 their colleagues have motivated a number of foundational concepts on 1499 which this work is based. 1501 Telcordia has proposed DHCP-related solutions for MANETs through the 1502 CECOM MOSAIC program. 1504 The Naval Research Lab (NRL) Information Technology Division uses 1505 DHCP in their MANET research testbeds. 1507 Security concerns pertaining to tunneling mechanisms are discussed in 1508 [I-D.ietf-v6ops-tunnel-security-concerns]. 1510 Default router and prefix information options for DHCPv6 are 1511 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1513 An automated IPv4 prefix delegation mechanism is proposed in 1515 [I-D.ietf-dhc-subnet-alloc]. 1517 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1518 [I-D.clausen-manet-autoconf-recommendations]. 1520 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1522 The LISP proposal [I-D.ietf-lisp] examines encapsulation/ 1523 decapsulation issues and other aspects of tunneling. 1525 Various proposals within the IETF have suggested similar mechanisms. 1527 10. Acknowledgements 1529 The following individuals gave direct and/or indirect input that was 1530 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1531 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1532 Chris Dearlove, Gert Doering, Ralph Droms, Washam Fan, Dino 1533 Farinacci, Vince Fuller, Thomas Goff, David Green, Joel Halpern, Bob 1534 Hinden, Sascha Hlusiak, Sapumal Jayatissa, Dan Jen, Darrel Lewis, 1535 Tony Li, Joe Macker, David Meyer, Gabi Nakibly, Thomas Narten, Pekka 1536 Nikander, Dave Oran, Alexandru Petrescu, Mark Smith, John Spence, 1537 Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela Vanderveen, James 1538 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1539 working groups. Many others have provided guidance over the course 1540 of many years. 1542 11. Contributors 1544 The following individuals have contributed to this document: 1546 Eric Fleischman (eric.fleischman@boeing.com) 1547 Thomas Henderson (thomas.r.henderson@boeing.com) 1548 Steven Russert (steven.w.russert@boeing.com) 1549 Seung Yi (seung.yi@boeing.com) 1551 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1552 of the document. 1554 Jim Bound's foundational work on enterprise networks provided 1555 significant guidance for this effort. We mourn his loss and honor 1556 his contributions. 1558 12. References 1559 12.1. Normative References 1561 [I-D.templin-intarea-seal] 1562 Templin, F., "The Subnetwork Encapsulation and Adaptation 1563 Layer (SEAL)", draft-templin-intarea-seal-08 (work in 1564 progress), January 2010. 1566 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1567 September 1981. 1569 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1570 RFC 792, September 1981. 1572 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1573 converting network protocol addresses to 48.bit Ethernet 1574 address for transmission on Ethernet hardware", STD 37, 1575 RFC 826, November 1982. 1577 [RFC1035] Mockapetris, P., "Domain names - implementation and 1578 specification", STD 13, RFC 1035, November 1987. 1580 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1581 RFC 2131, March 1997. 1583 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1584 (IPv6) Specification", RFC 2460, December 1998. 1586 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1587 Defeating Denial of Service Attacks which employ IP Source 1588 Address Spoofing", BCP 38, RFC 2827, May 2000. 1590 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1591 Update", RFC 3007, November 2000. 1593 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1594 and M. Carney, "Dynamic Host Configuration Protocol for 1595 IPv6 (DHCPv6)", RFC 3315, July 2003. 1597 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1598 "DNS Extensions to Support IP Version 6", RFC 3596, 1599 October 2003. 1601 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1602 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1603 December 2003. 1605 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1606 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1608 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1609 RFC 3972, March 2005. 1611 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1612 More-Specific Routes", RFC 4191, November 2005. 1614 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1615 Architecture", RFC 4291, February 2006. 1617 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1618 Message Protocol (ICMPv6) for the Internet Protocol 1619 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1621 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1622 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1623 September 2007. 1625 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1626 Address Autoconfiguration", RFC 4862, September 2007. 1628 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1629 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1630 March 2008. 1632 12.2. Informative References 1634 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1635 Switching Networks", May 1974. 1637 [I-D.cheshire-dnsext-multicastdns] 1638 Cheshire, S. and M. Krochmal, "Multicast DNS", 1639 draft-cheshire-dnsext-multicastdns-08 (work in progress), 1640 September 2009. 1642 [I-D.clausen-manet-autoconf-recommendations] 1643 Clausen, T. and U. Herberg, "MANET Router Configuration 1644 Recommendations", 1645 draft-clausen-manet-autoconf-recommendations-00 (work in 1646 progress), February 2009. 1648 [I-D.clausen-manet-linktype] 1649 Clausen, T., "The MANET Link Type", 1650 draft-clausen-manet-linktype-00 (work in progress), 1651 October 2008. 1653 [I-D.droms-dhc-dhcpv6-default-router] 1654 Droms, R. and T. Narten, "Default Router and Prefix 1655 Advertisement Options for DHCPv6", 1656 draft-droms-dhc-dhcpv6-default-router-00 (work in 1657 progress), March 2009. 1659 [I-D.hain-ipv6-ulac] 1660 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1661 IPv6 Unicast Unique Local Address Prefixes", 1662 draft-hain-ipv6-ulac-01 (work in progress), October 2009. 1664 [I-D.ietf-autoconf-manetarch] 1665 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1666 Network Architecture", draft-ietf-autoconf-manetarch-07 1667 (work in progress), November 2007. 1669 [I-D.ietf-csi-proxy-send] 1670 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1671 ND Support for SEND", draft-ietf-csi-proxy-send-01 (work 1672 in progress), July 2009. 1674 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 1675 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 1676 Assignment Notification (RAAN) Option", 1677 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 1678 progress), July 2009. 1680 [I-D.ietf-dhc-subnet-alloc] 1681 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1682 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-10 1683 (work in progress), November 2009. 1685 [I-D.ietf-lisp] 1686 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1687 "Locator/ID Separation Protocol (LISP)", 1688 draft-ietf-lisp-05 (work in progress), September 2009. 1690 [I-D.ietf-manet-smf] 1691 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1692 draft-ietf-manet-smf-09 (work in progress), July 2009. 1694 [I-D.ietf-v6ops-tunnel-security-concerns] 1695 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1696 Concerns With IP Tunneling", 1697 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1698 progress), October 2008. 1700 [I-D.jen-apt] 1701 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1702 L. Zhang, "APT: A Practical Transit Mapping Service", 1703 draft-jen-apt-01 (work in progress), November 2007. 1705 [I-D.nakibly-v6ops-tunnel-loops] 1706 Nakibly, G., "Routing Loops using ISATAP and 6to4: Problem 1707 Statement and Proposed Solutions", 1708 draft-nakibly-v6ops-tunnel-loops-00 (work in progress), 1709 October 2009. 1711 [I-D.russert-rangers] 1712 Russert, S., Fleischman, E., and F. Templin, "RANGER 1713 Scenarios", draft-russert-rangers-01 (work in progress), 1714 September 2009. 1716 [I-D.templin-isatap-dhcp] 1717 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1718 Option for the Intra-Site Automatic Tunnel Addressing 1719 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1720 progress), December 2009. 1722 [I-D.templin-ranger] 1723 Templin, F., "Routing and Addressing in Next-Generation 1724 EnteRprises (RANGER)", draft-templin-ranger-09 (work in 1725 progress), October 2009. 1727 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1728 July 1978. 1730 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1731 Protocol Specification", October 2008. 1733 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1734 Communication Layers", STD 3, RFC 1122, October 1989. 1736 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1737 September 1991. 1739 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1740 Routing and Addressing Architecture", RFC 1753, 1741 December 1994. 1743 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1744 E. Lear, "Address Allocation for Private Internets", 1745 BCP 5, RFC 1918, February 1996. 1747 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1748 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1750 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1751 October 1996. 1753 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1754 Extensions", RFC 2132, March 1997. 1756 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1757 over Non-Broadcast Multiple Access (NBMA) networks", 1758 RFC 2491, January 1999. 1760 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1761 (MANET): Routing Protocol Performance Issues and 1762 Evaluation Considerations", RFC 2501, January 1999. 1764 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1765 Domains without Explicit Tunnels", RFC 2529, March 1999. 1767 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1768 February 2000. 1770 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1771 via IPv4 Clouds", RFC 3056, February 2001. 1773 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1774 Networks", BCP 84, RFC 3704, March 2004. 1776 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1777 RFC 3753, June 2004. 1779 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1780 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1781 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1782 RFC 3819, July 2004. 1784 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1785 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1786 May 2005. 1788 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1789 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1790 September 2005. 1792 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1793 Addresses", RFC 4193, October 2005. 1795 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1796 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1798 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1799 Internet Protocol", RFC 4301, December 2005. 1801 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1802 Network Address Translations (NATs)", RFC 4380, 1803 February 2006. 1805 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1806 Proxies (ND Proxy)", RFC 4389, April 2006. 1808 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1809 Multicast Name Resolution (LLMNR)", RFC 4795, 1810 January 2007. 1812 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1813 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1814 Focus", RFC 4852, April 2007. 1816 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1817 June 2007. 1819 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1820 Extensions for Stateless Address Autoconfiguration in 1821 IPv6", RFC 4941, September 2007. 1823 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1824 for IPv6", RFC 5340, July 2008. 1826 Appendix A. Duplicate Address Detection (DAD) Considerations 1828 A priori uniqueness determination (also known as "pre-service DAD") 1829 for an RLOC assigned on an enterprise-interior interface would 1830 require either flooding the entire enterprise or somehow discovering 1831 a link in the enterprise on which a node that configures a duplicate 1832 address is attached and performing a localized DAD exchange on that 1833 link. But, the control message overhead for such an enterprise-wide 1834 DAD would be substantial and prone to false-negatives due to packet 1835 loss and intermittent connectivity. An alternative to pre-service 1836 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1837 interfaces and employ a passive in-service DAD (e.g., one that 1838 monitors routing protocol messages for duplicate assignments). 1840 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1841 CGAs, IPv6 privacy addresses, etc. with very small probability of 1842 collision. Pseudo-random IPv4 RLOCs can be generated through random 1843 assignment from a suitably large IPv4 prefix space. 1845 Consistent operational practices can assure uniqueness for EBG- 1846 aggregated addresses/prefixes, while statistical properties for 1847 pseudo-random address self-generation can assure uniqueness for the 1848 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1849 RLOC delegation authority should be used when available, while a 1850 passive in-service DAD mechanism should be used to detect RLOC 1851 duplications when there is no RLOC delegation authority. 1853 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1855 For each distinct enterprise that it connects to, an EBR configures a 1856 VET interface over possibly multiple underlying interfaces that all 1857 connect to the same enterprise. The VET interface therefore 1858 represents the EBR's logical point of attachment to the enterprise, 1859 and provides a logical interface for link-layer multiplexing over its 1860 underlying interfaces as described in Section 3.3.4.1 of [RFC1122]: 1862 "Finally, we note another possibility that is NOT multihoming: one 1863 logical interface may be bound to multiple physical interfaces, in 1864 order to increase the reliability or throughput between directly 1865 connected machines by providing alternative physical paths between 1866 them. For instance, two systems might be connected by multiple 1867 point-to-point links. We call this "link-layer multiplexing". 1868 With link-layer multiplexing, the protocols above the link layer 1869 are unaware that multiple physical interfaces are present; the 1870 link-layer device driver is responsible for multiplexing and 1871 routing packets across the physical interfaces." 1873 EBRs can support such a link-layer multiplexing capability across the 1874 enterprise in accordance with the Weak End System Model (see Section 1875 3.3.4.2 of [RFC1122]). In particular, when an EBR autoconfigures an 1876 RLOC address (see Section 5.1), it can associate it with the VET 1877 interface only instead of assigning it to an underlying interface. 1878 The EBR therefore only needs to obtain a single RLOC address even if 1879 there are multiple underlying interfaces, i.e., it does not need to 1880 obtain one for each underlying interface. The EBR can then leave the 1881 underlying interfaces unnumbered, or it can configure a randomly 1882 chosen IP link-local address (e.g., from the prefix 169.254/16 1883 [RFC3927] for IPv4) on underlying interfaces that require a 1884 configuration. The EBR need not check these link-local addresses for 1885 uniqueness within the enterprise, as they will not normally be used 1886 as the source address for packets. 1888 When the EBR engages in the enterprise-interior routing protocol, it 1889 uses the RLOC address assigned to the VET interface as the source 1890 address for all routing protocol control messages, however it must 1891 also supply an interface identifier (e.g., a small integer) that 1892 uniquely identifies the underlying interface that the control message 1893 is sent over. For example, if the underlying interfaces are known as 1894 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1895 sends a routing protocol control message over the "eth7" interface. 1896 This is necessary to ensure that other routers can determine the 1897 specific interface over which the EBR's routing protocol control 1898 message was sent, but the token need only be unique within the EBR 1899 itself and need not be unique throughout the enterprise. 1901 When the EBR discovers an RLOC route via the enterprise interior 1902 routing protocol, it configures a preferred route in the IP FIB that 1903 points to the VET interface instead of the underlying interface. At 1904 the same time, the EBR also configures an ancillary route that points 1905 to the underlying interface. If the EBR discovers that the same RLOC 1906 route is reachable via multiple underlying interfaces, it configures 1907 multiple ancillary routes (i.e., one for each interface). If the EBR 1908 discovers that the RLOC route is no longer reachable via any 1909 underlying interface, it removes the route in the IP FIB that points 1910 to the VET interface. 1912 With these arrangements, all locally-generated packets with RLOC 1913 destinations will flow through the VET interface (and thereby use the 1914 VET interface's RLOC address as the source address) instead of 1915 through the underlying interfaces. In the same fashion, all 1916 forwarded packets with RLOC destinations will flow through the VET 1917 interface instead of through the underlying interfaces. 1919 This arrangement has several operational advantages that enable a 1920 number of traffic engineering capabilities. First, the VET interface 1921 can insert the SEAL header so that ID-based duplicate packet 1922 detection is enabled within the enterprise. Secondly, SEAL can 1923 dynamically adjust its packet sizing parameters so that an optimum 1924 Maximum Transmission Unit (MTU) can be determined. This is true even 1925 if the VET interface reroutes traffic between underlying interfaces 1926 with different MTUs. 1928 Most importantly, the EBR can configure default and more-specific 1929 routes on the VET interface to direct traffic through a specific 1930 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1931 will ensure that a specific eEBR is chosen, and the best eEBR can be 1932 chosen when multiple are available. Also, local applications see a 1933 stable IP source address even if there are multiple underlying 1934 interfaces. This link-layer multiplexing can therefore provide 1935 continuous operation across failovers between multiple links attached 1936 to the same enterprise without any need for readdressing. Finally, 1937 the VET interface can forward packets with RLOC-based destinations 1938 over an underlying interface without any encapsulation if 1939 encapsulation avoidance is desired. 1941 It must be specifically noted that the above arrangement constitutes 1942 a case in which the same RLOC may be used as both the inner and outer 1943 IP source address. This will not present a problem as long as both 1944 ends configure a VET interface in the same fashion. 1946 It must also be noted that EID-based communications can use the same 1947 VET interface arrangement, except that the EID-based next hop must be 1948 mapped to an RLOC-based next-hop within the VET interface. For IPvX 1949 within IPvX encapsulation, as well as for IPv4 within IPv6 1950 encapsulation, this requires a VET interface specific address mapping 1951 database. For IPv6 within IPv4 encapsulation, the mapping is 1952 accomplished through simple static extraction of an IPv4 address 1953 embedded in a VET address. 1955 Appendix C. Anycast Services 1957 Some of the IPv4 addresses that appear in the Potential Router List 1958 may be anycast addresses, i.e., they may be configured on the VET 1959 interfaces of multiple EGBRs/EBGs. In that case, each VET router 1960 interface that configures the same anycast address must provide 1961 equivalent packet forwarding and IPv6 Neighbor Discovery services. 1963 Use of an anycast address as the IP destination address of tunneled 1964 packets can have subtle interactions with tunnel path MTU and 1965 neighbor discovery. For example, if the initial fragments of a 1966 fragmented tunneled packet with an anycast IP destination address are 1967 routed to different egress tunnel endpoints than the remaining 1968 fragments, the multiple endpoints will be left with incomplete 1969 reassembly buffers. This issue can be mitigated by ensuring that 1970 each egress tunnel endpoint implements a proactive reassembly buffer 1971 garbage collection strategy. Additionally, ingress tunnel endpoints 1972 that send packets with an anycast IP destination address must use the 1973 minimum path MTU for all egress tunnel endpoints that configure the 1974 same anycast address as the tunnel MTU. Finally, ingress tunnel 1975 endpoints should treat ICMP unreachable messages from a router within 1976 the tunnel as at most a weak indication of neighbor unreachability, 1977 since the failures may only be transient and a different path to an 1978 alternate anycast router quickly selected through reconvergence of 1979 the underlying routing protocol. 1981 Use of an anycast address as the IP source address of tunneled 1982 packets can lead to more serious issues. For example, when the IP 1983 source address of a tunneled packet is anycast, ICMP messages 1984 produced by routers within the tunnel might be delivered to different 1985 ingress tunnel endpoints than the ones that produced the packets. In 1986 that case, functions such as path MTU discovery and neighbor 1987 unreachability detection may experience non-deterministic behavior 1988 that can lead to communications failures. Additionally, the 1989 fragments of multiple tunneled packets produced by multiple ingress 1990 tunnel endpoints may be delivered to the same reassembly buffer at a 1991 single egress tunnel endpoint. In that case, data corruption may 1992 result due to fragment misassociation during reassembly. 1994 In view of these considerations, EBRs/EBGs that configure an anycast 1995 address should also configure one or more unicast addresses from the 1996 Potential Router List; they should further accept tunneled packets 1997 destined to any of their anycast or unicast addresses, but should 1998 send tunneled packets using a unicast address as the source address. 1999 In order to influence traffic to use an anycast route (and thereby 2000 leverage the natural fault tolerance afforded by anycast), ISATAP 2001 routers should set higher preferences on the default routes they 2002 advertise using an anycast address as the source and set lower 2003 preferences on the default routes they advertise using a unicast 2004 address as the source (see: [RFC4191]). 2006 Appendix D. Change Log 2008 (Note to RFC editor - this section to be removed before publication 2009 as an RFC.) 2011 Changes from -06 to -07: 2013 o reworked redirect function 2015 o created new section on VET interface encapsulation 2017 o clarifications on nexthop selection 2019 o fixed several bugs 2021 Changed from -05 to -06: 2023 o reworked VET interface ND 2025 o anycast clarifications 2027 Changes from -03 to -04: 2029 o security consideration clarifications 2031 Changes from -02 to -03: 2033 o security consideration clarifications 2035 o new PRLNAME for VET is "isatav2.example.com" 2036 o VET now uses SEAL natively 2038 o EBGs can support both legacy ISATAP and VET over the same 2039 underlying interfaces. 2041 Changes from -01 to -02: 2043 o Defined CGA and privacy address configuration on VET interfaces 2045 o Interface identifiers added to routing protocol control messages 2046 for link-layer multiplexing 2048 Changes from -00 to -01: 2050 o Section 4.1 clarifications on link-local assignment and RLOC 2051 autoconfiguration. 2053 o Appendix B clarifications on Weak End System Model 2055 Changes from RFC5558 to -00: 2057 o New appendix on RLOC configuration on VET interfaces. 2059 Author's Address 2061 Fred L. Templin (editor) 2062 Boeing Research & Technology 2063 P.O. Box 3707 MC 7L-49 2064 Seattle, WA 98124 2065 USA 2067 Email: fltemplin@acm.org