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