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