idnits 2.17.1 draft-templin-intarea-vet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2009) is 5406 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: 'I-D.ietf-autoconf-manetarch' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1567, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1573, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 == Outdated reference: A later version (-05) exists of draft-ietf-csi-proxy-send-00 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-09 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-08 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 == Outdated reference: A later version (-05) exists of draft-russert-rangers-00 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-04 == Outdated reference: A later version (-09) exists of draft-templin-ranger-07 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 5 errors (**), 0 flaws (~~), 13 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 June 30, 2009 5 Expires: January 1, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 1, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Enterprise networks connect routers over various link types, and may 47 also connect to provider networks and/or the global Internet. 48 Enterprise network nodes require a means to automatically provision 49 IP addresses/prefixes and support internetworking operation in a wide 50 variety of use cases including Small Office, Home Office (SOHO) 51 networks, Mobile Ad hoc Networks (MANETs), multi-organizational 52 corporate networks and the interdomain core of the global Internet 53 itself. This document specifies a Virtual Enterprise Traversal (VET) 54 abstraction for autoconfiguration and operation of nodes in 55 enterprise networks. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 10 62 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 63 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 12 64 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 13 65 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 14 66 4.2.2. Provider-Aggregated (PA) EID Prefix 67 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 68 4.2.3. Provider-Independent (PI) EID Prefix 69 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 70 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 17 71 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 17 72 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 18 73 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 18 74 5.2. RLOC-Based Communications . . . . . . . . . . . . . . . . 18 75 5.3. EID-Based Communications . . . . . . . . . . . . . . . . . 18 76 5.4. IPv6 Router Discovery and Prefix Registration . . . . . . 18 77 5.4.1. IPv6 Router and Prefix Discovery . . . . . . . . . . . 19 78 5.4.2. IPv6 PA Prefix Registration . . . . . . . . . . . . . 19 79 5.4.3. IPv6 PI Prefix Registration . . . . . . . . . . . . . 20 80 5.4.4. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . 21 81 5.5. IPv4 Router Discovery and Prefix Registration . . . . . . 23 82 5.6. VET Encapsulation . . . . . . . . . . . . . . . . . . . . 24 83 5.7. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 24 84 5.8. Generating Errors . . . . . . . . . . . . . . . . . . . . 25 85 5.9. Processing Errors . . . . . . . . . . . . . . . . . . . . 25 86 5.10. Mobility and Multihoming Considerations . . . . . . . . . 26 87 5.11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 27 88 5.12. Service Discovery . . . . . . . . . . . . . . . . . . . . 28 89 5.13. Enterprise Partitioning . . . . . . . . . . . . . . . . . 29 90 5.14. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 29 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 33 99 Appendix A. Duplicate Address Detection (DAD) Considerations . . 36 100 Appendix B. Link Layer Multiplexing and Traffic Engineering . . . 37 101 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 1. Introduction 106 Enterprise networks [RFC4852] connect routers over various link types 107 (see [RFC4861], Section 2.2). The term "enterprise network" in this 108 context extends to a wide variety of use cases and deployment 109 scenarios. For example, an "enterprise" can be as small as a SOHO 110 network, as complex as a multi-organizational corporation, or as 111 large as the global Internet itself. Mobile Ad hoc Networks (MANETs) 112 [RFC2501] can also be considered as a challenging example of an 113 enterprise network, in that their topologies may change dynamically 114 over time and that they may employ little/no active management by a 115 centralized network administrative authority. These specialized 116 characteristics for MANETs require careful consideration, but the 117 same principles apply equally to other enterprise network scenarios. 119 This document specifies a Virtual Enterprise Traversal (VET) 120 abstraction for autoconfiguration and internetworking operation, 121 where addresses of different scopes may be assigned on various types 122 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 123 [RFC2460] are discussed within this context. The use of standard 124 DHCP [RFC2131] [RFC3315] and neighbor discovery [RFC0826] [RFC1256] 125 [RFC4861] mechanisms is assumed unless otherwise specified. 127 Provider-Edge Interfaces 128 x x x 129 | | | 130 +--------------------+---+--------+----------+ E 131 | | | | | n 132 | I | | .... | | t 133 | n +---+---+--------+---+ | e 134 | t | +--------+ /| | r 135 | e I x----+ | Host | I /*+------+--< p I 136 | r n | |Function| n|**| | r n 137 | n t | +--------+ t|**| | i t 138 | a e x----+ V e|**+------+--< s e 139 | l r . | E r|**| . | e r 140 | f . | T f|**| . | f 141 | V a . | +--------+ a|**| . | I a 142 | i c . | | Router | c|**| . | n c 143 | r e x----+ |Function| e \*+------+--< t e 144 | t s | +--------+ \| | e s 145 | u +---+---+--------+---+ | r 146 | a | | .... | | i 147 | l | | | | o 148 +--------------------+---+--------+----------+ r 149 | | | 150 x x x 151 Enterprise-Edge Interfaces 153 Figure 1: Enterprise Router (ER) Architecture 155 Figure 1 above depicts the architectural model for an Enterprise 156 Router (ER). As shown in the figure, an ER may have a variety of 157 interface types including enterprise-edge, enterprise-interior, 158 provider-edge, internal-virtual, as well as VET interfaces used for 159 IP-in-IP encapsulation. The different types of interfaces are 160 defined, and the autoconfiguration mechanisms used for each type are 161 specified. This architecture applies equally for MANET routers, in 162 which enterprise-interior interfaces correspond to the wireless 163 multihop radio interfaces typically associated with MANETs. Out of 164 scope for this document is the autoconfiguration of provider 165 interfaces, which must be coordinated in a manner specific to the 166 service provider's network. 168 Enterprise networks must have a means for supporting both Provider- 169 Independent (PI) and Provider-Aggregated (PA) IP prefixes. This is 170 especially true for enterprise scenarios that involve mobility and 171 multihoming. Also in scope are ingress filtering for multihomed 172 sites, adaptation based on authenticated ICMP feedback from on-path 173 routers, effective tunnel path MTU mitigations, and routing scaling 174 suppression as required in many enterprise network scenarios. 176 Recognizing that one size does not fit all, the VET specification 177 provides adaptable mechanisms that address these issues, and more, in 178 a wide variety of enterprise network use cases. 180 VET represents a functional superset of 6over4 [RFC2529] and Intra- 181 Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and it 182 further supports additional encapsulations such as IPsec [RFC4301], 183 Subnetwork Encapsulation and Adaptation Layer (SEAL) 184 [I-D.templin-intarea-seal], etc. Together, these technologies serve 185 as functional building blocks for a new Internetworking architecture 186 known as Routing and Addressing in Next Generation EnteRprises 187 [I-D.templin-ranger] [I-D.russert-rangers]. 189 The VET principles can be either directly or indirectly traced to the 190 deliberations of the ROAD group in January 1992, and also to still 191 earlier works including NIMROD [RFC1753], the Catenet model for 192 internetworking [CATENET] [IEN48] [RFC2775], etc. [RFC1955] captures 193 the high-level architectural aspects of the ROAD group deliberations 194 in a "New Scheme for Internet Routing and Addressing (ENCAPS) for 195 IPNG". 197 VET is related to the present-day activities of the IETF INTAREA, 198 AUTOCONF, DHC, IPv6, MANET, and v6OPS working groups, as well as the 199 IRTF RRG working group. 201 2. Terminology 203 The mechanisms within this document build upon the fundamental 204 principles of IP-in-IP encapsulation. The terms "inner" and "outer" 205 are used to, respectively, refer to the innermost IP {address, 206 protocol, header, packet, etc.} *before* encapsulation, and the 207 outermost IP {address, protocol, header, packet, etc.} *after* 208 encapsulation. VET also allows for inclusion of "mid-layer" 209 encapsulations between the inner and outer layers, including IPSec 210 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 211 [I-D.templin-intarea-seal], etc. 213 The terminology in the normative references apply; the following 214 terms are defined within the scope of this document: 216 subnetwork 217 the same as defined in [RFC3819]. 219 enterprise 220 the same as defined in [RFC4852]. An enterprise is also 221 understood to refer to a cooperative networked collective with a 222 commonality of business, social, political, etc. interests. 224 Minimally, the only commonality of interest in some enterprise 225 network scenarios may be the cooperative provisioning of 226 connectivity itself. 228 site 229 a logical and/or physical grouping of interfaces that connect a 230 topological area less than or equal to an enterprise in scope. A 231 site within an enterprise can, in some sense, be considered as an 232 enterprise unto itself. 234 Mobile Ad hoc Network (MANET) 235 a connected topology of mobile or fixed routers that maintain a 236 routing structure among themselves over dynamic links, where a 237 wide variety of MANETs share common properties with enterprise 238 networks. The characteristics of MANETs are defined in [RFC2501], 239 Section 3. 241 enterprise/site/MANET 242 throughout the remainder of this document, the term "enterprise" 243 is used to collectively refer to any of {enterprise, site, MANET}, 244 i.e., the VET mechanisms and operational principles can be applied 245 to enterprises, sites, and MANETs of any size or shape. 247 Enterprise Router (ER) 248 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 249 mobile router that comprises a router function, a host function, 250 one or more enterprise-interior interfaces, and zero or more 251 internal virtual, enterprise-edge, provider-edge, and VET 252 interfaces. At a minimum, an ER forwards outer IP packets over 253 one or more sets of enterprise-interior interfaces, where each set 254 connects to a distinct enterprise. 256 Enterprise Border Router (EBR) 257 an ER that connects edge networks to the enterprise and/or 258 connects multiple enterprises together. An EBR is a tunnel 259 endpoint router, and it configures a separate VET interface over 260 each set of enterprise-interior interfaces that connect the EBR to 261 each distinct enterprise. In particular, an EBR may configure 262 multiple VET interfaces - one for each distinct enterprise. All 263 EBRs are also ERs. 265 Enterprise Border Gateway (EBG) 266 an EBR that connects VET interfaces configured over child 267 enterprises to a provider network - either directly via a 268 provider-edge interface or indirectly via another VET interface 269 configured over a parent enterprise. EBRs may act as EBGs on some 270 VET interfaces and as ordinary EBRs on other VET interfaces. All 271 EBGs are also EBRs. 273 enterprise-interior interface 274 an ER's attachment to a link within an enterprise. Packets sent 275 over enterprise-interior interfaces may be forwarded over multiple 276 additional enterprise-interior interfaces within the enterprise 277 before they are forwarded via an enterprise-edge interface, 278 provider-edge interface, or a VET interface configured over a 279 different enterprise. Enterprise-interior interfaces connect 280 laterally within the IP network hierarchy. 282 enterprise-edge interface 283 an EBR's attachment to a link (e.g., an Ethernet, a wireless 284 personal area network, etc.) on an arbitrarily complex edge 285 network that the EBR connects to an enterprise and/or provider 286 network. Enterprise-edge interfaces connect to lower levels 287 within the IP network hierarchy. 289 provider-edge interface 290 an EBR's attachment to the Internet or to a provider network 291 outside of the enterprise via which the Internet can be reached. 292 Provider-edge interfaces connect to higher levels within the IP 293 network hierarchy. 295 internal-virtual interface 296 an interface that is internal to an EBR and does not in itself 297 directly attach to a tangible physical link, e.g., an Ethernet 298 cable. Examples include a loopback interface, a virtual LAN 299 interface, or some form of tunnel interface. 301 Virtual Enterprise Traversal (VET) 302 an abstraction that uses IP-in-IP encapsulation to create an 303 overlay that spans an enterprise in a single (inner) IP hop. 305 VET interface 306 an EBR's tunnel virtual interface used for Virtual Enterprise 307 Traversal. The EBR configures a VET interface over a set of 308 underlying interfaces belonging to the same enterprise. When 309 there are multiple distinct enterprises (each with their own 310 distinct set of underlying interfaces), the EBR configures a 311 separate VET interface over each set of underlying interfaces, 312 i.e., the EBR configures multiple VET interfaces. 314 The VET interface encapsulates each inner IP packet in any mid- 315 layer headers plus an outer IP header, then it forwards it on an 316 underlying interface such that the Time to Live (TTL) - Hop Limit 317 in the inner header is not decremented as the packet traverses the 318 enterprise. The VET interface therefore presents an automatic 319 tunneling abstraction that represents the enterprise as a single 320 IP hop. 322 VET interfaces in non-multicast environments are Non-Broadcast, 323 Multiple Access (NBMA); VET interfaces in multicast environments 324 are multicast capable. 326 VET host 327 any node (host or router) that configures a VET interface for host 328 operation only. Note that a single node may configure some of its 329 VET interfaces as host interfaces and others as router interfaces. 331 VET node 332 any node that configures and uses a VET interface. 334 Provider-Independent (PI) prefix 335 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 336 that is either self-generated by an ER or delegated to an 337 enterprise by a registry. 339 Provider Aggregated (PA) prefix 340 an IPv6 or IPv4 prefix that is delegated to an enterprise by a 341 provider network. 343 Routing Locator (RLOC) 344 a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix 345 that can appear in enterprise-interior and/or interdomain routing 346 tables. Global-scope RLOC prefixes are delegated to specific 347 enterprises and routable within both the enterprise-interior and 348 interdomain routing regions. Enterprise-local-scope RLOC prefixes 349 (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 privacy 350 addresses [RFC1918], etc.) are self-generated by individual 351 enterprises and routable only within the enterprise-interior 352 routing region. 354 ERs use RLOCs for operating the enterprise-interior routing 355 protocol and for next-hop determination in forwarding packets 356 addressed to other RLOCs. End systems use RLOCs as addresses for 357 communications between endpoints within the same enterprise. VET 358 interfaces treat RLOCs as *outer* IP addresses during IP-in-IP 359 encapsulation. 361 Endpoint Interface iDentifier (EID) 362 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 363 within an enterprise-edge or VET overlay network scope, and may 364 also appear in enterprise-interior and/or interdomain mapping 365 tables. EID prefixes are typically separate and distinct from any 366 RLOC prefix space. 368 Edge network routers use EIDs for operating the enterprise-edge or 369 VET overlay network routing protocol and for next-hop 370 determination in forwarding packets addressed to other EIDs. End 371 systems use EIDs as addresses for communications between endpoints 372 either within the same enterprise or within different enterprises. 373 VET interfaces treat EIDs as *inner* IP addresses during IP-in-IP 374 encapsulation. 376 The following additional acronyms are used throughout the document: 378 CGA - Cryptographically Generated Address 379 DHCP(v4, v6) - Dynamic Host Configuration Protocol 380 FIB - Forwarding Information Base 381 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 382 NBMA - Non-Broadcast, Multiple Access 383 ND - Neighbor Discovery 384 PIO - Prefix Information Option 385 PRL - Potential Router List 386 PRLNAME - Identifying name for the PRL (default is "isatap") 387 RIO - Route Information Option 388 RS/RA - IPv6 ND Router Solicitation/Advertisement 389 SEAL - Subnetwork Encapsulation and Adaptation Layer 390 SLAAC - IPv6 StateLess Address AutoConfiguation 392 3. Enterprise Characteristics 394 Enterprises consist of links that are connected by Enterprise Routers 395 (ERs) as depicted in Figure 1. ERs typically participate in a 396 routing protocol over enterprise-interior interfaces to discover 397 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 398 Enterprise Border Routers (EBRs) are ERs that connect edge networks 399 to the enterprise and/or join multiple enterprises together. 400 Enterprise Border Gateways (EBGs) are EBRs that either directly or 401 indirectly connect enterprises to provider networks. 403 An enterprise may be as simple as a small collection of ERs and their 404 attached edge networks; an enterprise may also contain other 405 enterprises and/or be a subnetwork of a larger enterprise. An 406 enterprise may further encompass a set of branch offices and/or 407 nomadic hosts connected to a home office over one or several service 408 providers, e.g., through Virtual Private Network (VPN) tunnels. 410 Enterprises that comprise link types with sufficiently similar 411 properties (e.g., Layer 2 (L2) address formats, maximum transmission 412 units (MTUs), etc.) can configure a sub-IP layer routing service such 413 that IP sees the enterprise as an ordinary shared link the same as 414 for a (bridged) campus LAN. In that case, a single IP hop is 415 sufficient to traverse the enterprise without IP layer encapsulation. 417 Enterprises that comprise link types with diverse properties and/or 418 configure multiple IP subnets must also provide a routing service 419 that operates as an IP layer mechanism. In that case, multiple IP 420 hops may be necessary to traverse the enterprise such that care must 421 be taken to avoid multi-link subnet issues [RFC4903]. 423 Conceptually, an ER embodies both a host function and router 424 function. The host function supports Endpoint Interface iDentifier 425 (EID)-based and/or Routing LOCator (RLOC)-based communications 426 according to the weak end-system model [RFC1122]. The router 427 function engages in the enterprise-interior routing protocol, 428 connects any of the ER's edge networks to the enterprise, and may 429 also connect the enterprise to provider networks (see Figure 1). 431 In addition to other interface types, VET nodes configure VET 432 interfaces that view all other VET nodes in an enterprise as single- 433 hop neighbors attached to a virtual link. VET nodes configure a 434 separate VET interface for each distinct enterprise to which they 435 connect, and discover other EBRs on each VET interface that can be 436 used for forwarding packets to off-enterprise destinations. 438 For each distinct enterprise, an enterprise trust basis must be 439 established and consistently applied. For example, in enterprises in 440 which EBRs establish symmetric security associations, mechanisms such 441 as IPsec [RFC4301] can be used to assure authentication and 442 confidentiality. In other enterprise network scenarios, asymmetric 443 securing mechanisms such as SEcure Neighbor Discovery (SEND) 444 [RFC3971] may be necessary to authenticate exchanges based on trust 445 anchors. 447 Finally, in enterprises with a centralized management structure 448 (e.g., a corporate campus network), the enterprise name service and a 449 synchronized set of EBGs can provide infrastructure support for 450 virtual enterprise traversal. In that case, the EBGs can provide a 451 "default mapper" [I-D.jen-apt] service used for short-term packet 452 forwarding until EBR neighbor relationships can be established. In 453 enterprises with a distributed management structure (e.g., MANETs), 454 peer-to-peer coordination between the EBRs themselves may be 455 required. Recognizing that various use cases will entail a continuum 456 between a fully distributed and fully centralized approach, the 457 following sections present the mechanisms of Virtual Enterprise 458 Traversal as they apply to a wide variety of scenarios. 460 4. Autoconfiguration 462 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 463 specified in the following subsections. 465 4.1. Enterprise Router (ER) Autoconfiguration 467 ERs configure enterprise-interior interfaces and engage in any 468 routing protocols over those interfaces. 470 When an ER joins an enterprise, it first configures an IPv6 link- 471 local address on each enterprise-interior interface and configures an 472 IPv4 link-local address on each enterprise-interior interface that 473 requires an IPv4 link-local capability. IPv6 link-local address 474 generation mechanisms include Cryptographically Generated Addresses 475 (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 476 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 477 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 478 provide an IPv4 link-local address generation capability. 480 Next, the ER configures one or more RLOCs and engages in any routing 481 protocols on its enterprise-interior interfaces. The ER can 482 configure RLOCs via explicit management, DHCP autoconfiguration, 483 pseudo-random self-generation from a suitably large address pool, or 484 through an alternate autoconfiguration mechanism. The ER may 485 optionally configure and assign a separate RLOC for each underlying 486 interface, or it may configure only a single RLOC and assign it to a 487 VET interface configured over the underlying interfaces (see Section 488 4.2.1). In the latter case, the ER can use the VET interface for 489 link layer multiplexing and traffic engineering purposes as specified 490 in Appendix B. 492 Alternatively (or in addition), the ER can request RLOC prefix 493 delegations via an automated prefix delegation exchange over an 494 enterprise-interior interface and can assign the prefix(es) on 495 enterprise-edge interfaces. In that case, the ER can use an RLOC 496 assigned to an enterprise-edge interface for enterprise-interior 497 routing protocol operation and next-hop determination purposes. Note 498 that in some cases, the same enterprise-edge interfaces may assign 499 both RLOC and an EID addresses if there is a means for source address 500 selection. In other cases (e.g., for separation of security 501 domains), RLOCs and EIDs must be assigned on separate sets of 502 enterprise-edge interfaces. 504 Self-generation of RLOCs for IPv6 can be from a large public or 505 local-use IPv6 address range (e.g., IPv6 Unique Local Addresses 506 [RFC4193]). Self-generation of RLOCs for IPv4 can be from a large 507 public or private IPv4 private address range (e.g., [RFC1918]). When 508 self-generation is used alone, the ER must continuously monitor the 509 RLOCs for uniqueness, e.g., by monitoring the routing protocol. 511 DHCP generation of RLOCs may require support from relays within the 512 enterprise. For DHCPv6, relays that do not already know the RLOC of 513 a server within the enterprise forward requests to the 514 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For 515 DHCPv4, relays that do not already know the RLOC of a server within 516 the enterprise forward requests to the site-scoped IPv4 multicast 517 group address 'All_DHCPv4_Servers', which should be set to 518 239.255.2.1 unless an alternate multicast group for the site is 519 known. DHCPv4 servers that delegate RLOCs should therefore join the 520 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 521 received for that group. 523 A combined approach using both DHCP and self-generation is also 524 possible when the ER configures both a DHCP client and relay that are 525 connected, e.g., via a pair of back-to-back connected Ethernet 526 interfaces, a tun/tap interface, a loopback interface, inter-process 527 communication, etc. The ER first self-generates a temporary RLOC 528 used only for the purpose of procuring an actual RLOC taken from a 529 disjoint addressing range. The ER then engages in the routing 530 protocol and performs a DHCP client/relay exchange using the 531 temporary RLOC as the address of the relay. When the DHCP server 532 delegates an actual RLOC address/prefix, the ER abandons the 533 temporary RLOC and re-engages in the routing protocol using an RLOC 534 taken from the delegation. 536 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 537 enterprise-interior interfaces as singleton addresses (i.e., as 538 addresses with /32 prefix lengths for IPv4, and as addresses with 539 /128 prefix lengths for IPv6) may be necessary to avoid multi-link 540 subnet issues. In the preferred arrangement, assignment of RLOCs on 541 VET interfaces only (i.e., as specified in Appendix B) avoids this 542 issue altogether. 544 4.2. Enterprise Border Router (EBR) Autoconfiguration 546 EBRs are ERs that configure VET interfaces over distinct sets of 547 underlying interfaces belonging to the same enterprise; an EBR can 548 connect to multiple enterprises, in which case it would configure 549 multiple VET interfaces. In addition to the ER autoconfiguration 550 procedures specified in Section 4.1, EBRs perform the following 551 autoconfiguration operations. 553 4.2.1. VET Interface Autoconfiguration 555 VET interface autoconfiguration entails: 1) interface initialization, 556 2) EBG discovery and enterprise identification, and 3) EID 557 configuration. These functions are specified in the following 558 sections. 560 4.2.1.1. Interface Initialization 562 EBRs configure a VET interface over a set of underlying interfaces 563 belonging to the same enterprise, where the VET interface presents a 564 virtual-link abstraction in which all EBRs in the enterprise appear 565 as single-hop neighbors through the use of IP in IP encapsulation. 566 After the EBR configures a VET interface, it initializes the 567 interface and assigns an IPv6 link-local address and an IPv4 link- 568 local address if necessary. 570 When IPv6 and IPv4 are used as the inner/outer protocols 571 (respectively), the EBR autoconfigures an ISATAP link-local address 572 ([RFC5214], Section 6.2) on the VET interface to support packet 573 forwarding and operation of the IPv6 neighbor discovery protocol. 574 The ISATAP link-local address embeds an IPv4 RLOC, and need not be 575 checked for uniqueness since the IPv4 RLOC itself is managed for 576 uniqueness (see Section 4.1). 578 Link-local address configuration for other inner/outer IP protocol 579 combinations is through administrative configuration or through an 580 unspecified alternate method. Link-local address configuration for 581 other inner/outer IP protocol combinations may not be necessary if an 582 EID can be configured through other means (see Section 4.2.1.3). 584 After the EBR initializes a VET interface, it can communicate with 585 other VET nodes as single-hop neighbors on the VET interface from the 586 viewpoint of the inner IP protocol. 588 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 589 Identification 591 The EBR next discovers a list of EBGs for each of its VET interfaces. 592 The list can be discovered through information conveyed in the 593 routing protocol, through the Potential Router List (PRL) discovery 594 mechanisms outlined in Section 8.3.2 of [RFC5214], through DHCP 595 options, etc. In multicast-capable enterprises, EBRs can also listen 596 for advertisements on the 'rasadv' [RASADV] multicast group address. 598 In particular, whether or not routing information is available, the 599 EBR can discover the list of EBGs by resolving an identifying name 600 for the PRL ('PRLNAME') formed as 'hostname.domainname', where 601 'hostname' is an enterprise-specific name string and 'domainname' is 602 an enterprise-specific DNS suffix. The EBR discovers 'PRLNAME' 603 through manual configuration, a DHCP option, 'rasadv' protocol 604 advertisements, link-layer information (e.g., an IEEE 802.11 Service 605 Set Identifier (SSID)), or through some other means specific to the 606 enterprise. In the absence of other information, the EBR sets the 607 'hostname' component of 'PRLNAME' to "isatap" and sets the 608 'domainname' component only if an enterprise-specific DNS suffix 609 "example.com" is known (e.g., as "isatap.example.com"). 611 The global Internet interdomain routing core represents a specific 612 example of an enterprise network scenario, albeit on an enormous 613 scale. The 'PRLNAME' assigned to the global Internet interdomain 614 routing core is "isatap.net". 616 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 617 resolving 'PRLNAME' to a list of RLOC addresses through a name 618 service lookup. For centrally managed enterprises, the EBR resolves 619 'PRLNAME' using an enterprise-local name service (e.g., the 620 enterprise-local DNS). For enterprises with a distributed management 621 structure, the EBR resolves 'PRLNAME' using Link-Local Multicast Name 622 Resolution (LLMNR) [RFC4795] over the VET interface. In that case, 623 all EBGs in the PRL respond to the LLMNR query, and the EBR accepts 624 the union of all responses. 626 Each distinct enterprise must have a unique identity that EBRs can 627 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 628 well as the RLOCs of EBGs and the IP prefixes they aggregate serve as 629 an identifier for the enterprise. 631 4.2.1.3. EID Configuration 633 After EBG discovery, the EBR configures EIDs on its VET interfaces. 634 When IPv6 and IPv4 are used as the inner/outer protocols 635 (respectively), the EBR autoconfigures EIDs as specified in 636 Section 5.4.1. In particular, the EBR acts as a host on its VET 637 interfaces for router and prefix discovery purposes but acts as a 638 router on its VET interfaces for routing protocol operation and 639 packet forwarding purposes. 641 EID configuration for other inner/outer IP protocol combinations is 642 through administrative configuration or through an unspecified 643 alternate method; in some cases, such EID configuration can be 644 performed independently of EBG discovery. 646 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 648 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 649 autoconfiguration exchanges with EBGs over VET interfaces, where each 650 EBG may be configured as either a DHCP relay or DHCP server. 652 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 653 delegation exchange, explicit management, etc. 655 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 656 exchanges. In particular, the EBR (acting as a requesting router) 657 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 658 obtain IPv6 EID prefixes from the server (acting as a delegating 659 router). 661 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 662 exchange [RFC3315]. For example, to perform the 2-message exchange, 663 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 664 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 665 relay (see Section 4.1). The relay then forwards the message over 666 the VET interface to an EBG, which either services the request or 667 relays it further. The forwarded Solicit message will elicit a reply 668 from the server containing PA IPv6 prefix delegations. 670 The EBR can propose a specific prefix to the DHCPv6 server per 671 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 672 available. The server will check the proposed prefix for consistency 673 and uniqueness, then return it in the reply to the EBR if it was able 674 to perform the delegation. 676 After the EBR receives PA prefix delegations, it can provision the 677 prefixes on enterprise-edge interfaces as well as on other VET 678 interfaces for which it is configured as an EBG. It can also 679 provision the prefixes on enterprise-interior interfaces as long as 680 other nodes on those interfaces unambiguously associate the prefixes 681 with the EBR. 683 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 685 Independent of any PA prefixes, EBRs can acquire and use Provider- 686 Independent (PI) EID prefixes that are self-configured (e.g., using 687 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 688 using [I-D.ietf-ipv6-ula-central], etc.). When an EBR acquires a PI 689 prefix, it must also obtain credentials that it can use to prove 690 prefix ownership when it registers the prefixes with EBGs within an 691 enterprise (see Section 5.4 and Section 5.5). 693 After the EBR receives PI prefix delegations, it can provision the 694 prefixes on enterprise-edge interfaces as well as on other VET 695 interfaces for which it is configured as an EBG. It can also 696 provision the prefixes on enterprise-interior interfaces as long as 697 other nodes on those interfaces can unambiguously associate the 698 prefixes with the EBR. 700 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 702 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 704 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 706 EBGs are EBRs that connect child enterprises to provider networks via 707 provider-edge interfaces and/or via VET interfaces configured over 708 parent enterprises. EBGs autoconfigure their provider-edge 709 interfaces in a manner that is specific to the provider connections, 710 and they autoconfigure their VET interfaces that were configured over 711 parent enterprises, using the EBR autoconfiguration procedures 712 specified in Section 4.2. 714 For each of its VET interfaces configured over a child enterprise, 715 the EBG initializes the interface and configures an EID the same as 716 for an ordinary EBR (see Section 4.2.1). It must then arrange to add 717 one or more of its RLOCs associated with the child enterprise to the 718 PRL, and it must maintain these resource records in accordance with 719 [RFC5214], Section 9. In particular, for each VET interface 720 configured over a child enterprise, the EBG adds the RLOCs to name- 721 service resource records for 'PRLNAME'. 723 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 724 configured over child enterprises with a distributed management 725 structure. 727 EBGs configure a DHCP relay/server on VET interfaces configured over 728 child enterprises that require DHCP services. 730 To avoid looping, EBGs must not configure a default route on a VET 731 interface configured over a child interface. 733 4.4. VET Host Autoconfiguration 735 Nodes that cannot be attached via an EBR's enterprise-edge interface 736 (e.g., nomadic laptops that connect to a home office via a Virtual 737 Private Network (VPN)) can instead be configured for operation as a 738 simple host connected to the VET interface. Such VET hosts perform 739 the same VET interface autoconfiguration procedures as specified for 740 EBRs in Section 4.2.1, but they configure their VET interfaces as 741 host interfaces (and not router interfaces). VET hosts can then send 742 packets to the EID addresses of other hosts on the VET interface, or 743 to off-enterprise EID destinations via a next-hop EBR. 745 Note that a node may be configured as a host on some VET interfaces 746 and as an EBR/EBG on other VET interfaces. 748 5. Internetworking Operation 750 Following the autoconfiguration procedures specified in Section 4, 751 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 752 operations as discussed in the following sections. 754 5.1. Routing Protocol Participation 756 Following autoconfiguration, ERs engage in any RLOC-based IP routing 757 protocols and forward IP packets with RLOC addresses. EBRs can 758 additionally engage in any EID-based IP routing protocols and forward 759 IP packets with EID addresses. Note that the EID-based IP routing 760 domains are separate and distinct from any RLOC-based IP routing 761 domains. 763 5.2. RLOC-Based Communications 765 When permitted by policy and supported by routing, end systems can 766 avoid VET interface encapsulation through communications that 767 directly invoke the outer IP protocol using RLOC addresses instead of 768 EID addresses. End systems can use source address selection rules to 769 determine whether to use EID or RLOC addresses based on, e.g., name- 770 service records. 772 5.3. EID-Based Communications 774 In many enterprise scenarios, the use of EID-based communications 775 (i.e., instead of RLOC-based communications) may be necessary and/or 776 beneficial to support address scaling, NAT avoidance, security domain 777 separation, site multihoming, traffic engineering, etc. 779 The remainder of this section discusses internetworking operation for 780 EID-based communications using the VET interface abstraction. 782 5.4. IPv6 Router Discovery and Prefix Registration 784 The following sections discuss router and prefix discovery 785 considerations for the case of IPv6 as the inner IP protocol. 787 5.4.1. IPv6 Router and Prefix Discovery 789 EBGs follow the router and prefix discovery procedures specified in 790 [RFC5214], Section 8.2. They send solicited RAs over VET interfaces 791 for which they are configured as gateways with default router 792 lifetimes, with PIOs that contain PA prefixes for SLAAC, and with any 793 other required options/parameters. The RAs can also include PIOs 794 with the 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' 795 as a hint of an aggregated prefix from which the EBG is willing to 796 delegate longer PA prefixes. When PIOs that contain PA prefixes for 797 SLAAC are included, the 'M' flag in the RA should also be set to 0. 799 VET nodes follow the router and prefix discovery procedures specified 800 in [RFC5214], Section 8.3. They discover EBGs within the enterprise 801 as specified in Section 4.2.1.2, then perform RS/RA exchanges with 802 the EBGs to establish and maintain default routes. In particular, 803 the VET node sends unicast RS messages to EBGs over its VET 804 interface(s) to receive RAs. Depending on the enterprise network 805 trust basis, VET nodes may be required to use SEND to secure the 806 RS/RA exchanges. 808 When the VET node receives an RA, it authenticates the message, then 809 configures a default route based on the Router Lifetime. If the RA 810 contains Prefix Information Options (PIOs) with the 'A' and 'L' bits 811 set to 1, the VET node also autoconfigures IPv6 addresses from the 812 advertised prefixes using SLAAC and assigns them to the VET 813 interface. Thereafter, the VET node accepts packets that are 814 forwarded by EBGs for which it has current default routing 815 information (i.e., ingress filtering is based on the default router 816 trust relationship rather than a prefix-specific ingress filter 817 entry). 819 In enterprises in which DHCPv6 is preferred, DHCPv6 exchanges between 820 EBRs and EBGs may be sufficient to convey default router and prefix 821 information. In that case, RS/RA exchanges may not be necessary. 823 5.4.2. IPv6 PA Prefix Registration 825 After an EBR discovers default routes, it can use DHCP prefix 826 delegation to obtain PA prefixes via an EBG as specified in 827 Section 4.2.2. The DHCP server ensures that the delegations are 828 unique and that the EBG's router function will forward IP packets 829 over the VET interface to the correct EBR. In particular, the EBG 830 must register and track the PA prefixes that are delegated to each 831 EBR. 833 The PA prefix registrations remain active in the EBGs as long as the 834 EBR continues to issue DHCP renewals over the VET interface before 835 lease lifetimes expire. The lease lifetime also keeps the delegation 836 state active even if communications between the EBR and DHCP server 837 are disrupted for a period of time (e.g., due to an enterprise 838 network partition) before being reestablished (e.g., due to an 839 enterprise network merge). 841 5.4.3. IPv6 PI Prefix Registration 843 After an EBR discovers default routes, it must register its PI 844 prefixes by sending RAs to a set of one or more EBGs with Route 845 Information Options (RIOs) [RFC4191] that contain the EBR's PI 846 prefixes. Each RA must include the RLOC of an EBG as the outer IP 847 destination address and a link-local address assigned to the VET 848 interface as the inner IP destination address. For enterprises that 849 use SEND, the RAs also include a CGA link-local inner source address, 850 SEND credentials, plus any certificates needed to prove ownership of 851 the PI prefixes. The EBR additionally tracks the set of EBGs to 852 which it sends RAs so that it can send subsequent RAs to the same 853 set. 855 When the EBG receives the RA, it first authenticates the message; if 856 the authentication fails, the EBG discards the RA. Otherwise, the 857 EBG installs the PI prefixes with their respective lifetimes in its 858 Forwarding Information Base (FIB) and configures them for both 859 ingress filtering [RFC3704] and forwarding purposes. In particular, 860 the EBG configures the FIB entries as ingress filter rules to accept 861 packets received on the VET interface that have a source address 862 taken from the PI prefixes. It also configures the FIB entries to 863 forward packets received on other interfaces with a destination 864 address taken from the PI prefixes to the EBR that registered the 865 prefixes on the VET interface. 867 The EBG then publishes the PI prefixes in a distributed database 868 (e.g., in a private instance of a routing protocol in which only EBGs 869 participate, via an automated name-service update mechanism 870 [RFC3007], etc.). For enterprises that are managed under a 871 centralized administrative authority, the EBG also publishes the PI 872 prefixes in the enterprise-local name-service (e.g., the enterprise- 873 local DNS [RFC1035]). 875 In particular, the EBG publishes each /56 prefix taken from the PI 876 prefixes as a separate Fully Qualified Domain Name (FQDN) that 877 consists of a sequence of 14 nibbles in reverse order (i.e., the same 878 as in [RFC3596], Section 2.5) followed by the string 'ip6' followed 879 by the string 'PRLNAME'. For example, when 'PRLNAME' is 880 "isatap.example.com", the EBG publishes the prefix '2001:DB8::/56' 881 as: 882 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. 884 The EBG includes the outer RLOC source address of the RA (e.g., in a 885 DNS A resource record) in each prefix publication. For enterprises 886 that use SEND, the EBG also includes the inner IPv6 CGA source 887 address (e.g., in a DNS AAAA record) in each prefix publication. If 888 the prefix was already installed in the distributed database, the EBG 889 instead adds the outer RLOC source address (e.g., in an additional 890 DNS A record) to the preexisting publication to support PI prefixes 891 that are multihomed. For enterprises that use SEND, this latter 892 provision requires all EBRs of a multihomed site that advertise the 893 same PI prefixes in RAs to use the same CGA and the same SEND 894 credentials. 896 After the EBG authenticates the RA and publishes the PI prefixes, it 897 next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the 898 VET interfaces configured over any of its parent enterprises, and it 899 relays a proxied RA to the EBGs on those interfaces. (For 900 enterprises that use SEND, the EBG additionally acts as a SEcure 901 Neighbor Discovery Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) 902 EBGs in parent enterprises that receive the proxied RAs in turn act 903 as NDProxys/SENDProxys to relay the RAs to EBGs on their parent 904 enterprises, etc. The RA proxying and PI prefix publication recurses 905 in this fashion and ends when an EBR attached to an interdomain 906 routing core is reached. 908 After the initial PI prefix registration, the EBR that owns the 909 prefix(es) must periodically send additional RAs to its set of EBGs 910 to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in 911 parent enterprises to which it relays the proxied RAs, and should 912 relay subsequent RAs to the same set. 914 This procedure has a direct analogy in the Teredo method of 915 maintaining state in network middleboxes through the periodic 916 transmission of "bubbles" [RFC4380]. 918 5.4.4. IPv6 Next-Hop EBR Discovery 920 VET nodes discover destination-specific next-hop EBRs within the 921 enterprise by querying the name service for the /56 IPv6 PI prefix 922 taken from a packet's destination address, by forwarding packets via 923 a default route to an EBG, or by some other inner-IP-to-outer-IP 924 address mapping mechanism. For example, for the IPv6 destination 925 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 926 node can lookup the domain name: 927 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. 929 If the name-service lookup succeeds, it will return RLOC addresses 930 (e.g., in DNS A records) that correspond to next-hop EBRs to which 931 the VET node can forward packets. (In enterprises that use SEND, it 932 will also return an IPv6 CGA address, e.g., in a DNS AAAA record.) 934 Name-service lookups in enterprises with a centralized management 935 structure use an infrastructure-based service, e.g., an enterprise- 936 local DNS. Name-service lookups in enterprises with a distributed 937 management structure and/or that lack an infrastructure-based name- 938 service instead use LLMNR over the VET interface. When LLMNR is 939 used, the EBR that performs the lookup sends an LLMNR query (with the 940 /56 prefix taken from the IP destination address encoded in dotted- 941 nibble format as shown above) and accepts the union of all replies it 942 receives from other EBRs on the VET interface. When an EBR receives 943 an LLMNR query, it responds to the query IFF it aggregates an IP 944 prefix that covers the prefix in the query. 946 Alternatively, in enterprises with a stable and highly-available set 947 of EBGs, the VET node can simply forward an initial packet via a 948 default route to an EBG. The EBG will forward the packet to a next- 949 hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] 950 (using SEND, if necessary). If the packet's source address is on- 951 link on the VET interface, the EBG returns an ordinary "router-to- 952 host" redirect with the source address of the packet as its 953 destination. If the packet's source address is not on-link, the EBG 954 instead returns a "router-to-router" redirect with the link-local 955 ISATAP address of the previous-hop EBR as its destination. When IPv4 956 is used as the outer IP protocol, the EBG also includes in the 957 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 958 contain the IPv4 RLOCs of potential next-hop EBRs arranged in order 959 from lowest to highest priority (i.e., the first LLAO contains the 960 lowest priority RLOC and the final LLAO option contains the highest 961 priority). These LLAOs are formatted using a modified version of the 962 form specified in Section 5 of [RFC2529], as shown in Figure 2 (the 963 LLAO format for IPv6 as the outer IP protocol is out of scope). 965 +-------+-------+-------+-------+-------+-------+-------+-------+ 966 | Type |Length | TTL | IPv4 Address | 967 +-------+-------+-------+-------+-------+-------+-------+-------+ 969 Figure 2: VET Link-Layer Address Option Format 971 For each such IPv6/IPv4 LLAO, the Type is set to 2 (for Target Link- 972 Layer Address Option), Length is set to 1, and IPv4 Address is set to 973 the IPv4 RLOC of the next-hop EBR. TTL is set to the time in seconds 974 that the recipient may cache the RLOC, where the value 65535 975 represents infinity and the value 0 suspends forwarding through this 976 RLOC. 978 When a VET host receives an ordinary "router-to-host" redirect, it 979 processes the redirect exactly as specified in [RFC4861], Section 8. 981 When an EBR receives a "router-to-router" redirect, it discovers the 982 RLOC addresses of potential next-hop EBRs by examining the LLAOs 983 included in the redirect. The EBR then installs a FIB entry that 984 contains the /56 prefix of the destination address encoded in the 985 redirect and the list of RLOCs of potential next-hop EBRs. The EBR 986 then enables the FIB entry for forwarding to next-hop EBRs but DOES 987 NOT enable it for ingress filtering acceptance of packets from next- 988 hop EBRs (i.e., the forwarding determination is unidirectional). 990 In enterprises in which spoofing is possible, after discovering 991 potential next-hop EBRs (either through name-service lookup or ICMP 992 redirect) the EBR must send authenticating credentials before 993 forwarding packets via the next-hops. To do so, the EBR must send 994 RAs over the VET interface (using SEND, if necessary) to one or more 995 of the potential next-hop EBRs with an RLOC as the outer IP 996 destination address. The RAs must include a Route Information Option 997 (RIO) [RFC4191] that contains the /56 PI prefix of the original 998 packet's source address. After sending the RAs, the EBR can either 999 enable the new FIB entry for forwarding immediately or delay until it 1000 receives an explicit acknowledgement that a next-hop EBR received the 1001 RA (e.g., using the SEAL explicit acknowledgement mechanism -- see 1002 Section 5.7). 1004 When a next-hop EBR receives the RA, it authenticates the message 1005 then it performs a name-service lookup on the prefix in the RIO if 1006 further authenticating evidence is required. If the name service 1007 returns resource records that are consistent with the inner and outer 1008 IP addresses of the RA, the next-hop EBR then installs the prefix in 1009 the RIO in its FIB and enables the FIB entry for ingress filtering 1010 but DOES NOT enable it for forwarding purposes. After an EBR sends 1011 initial RAs following a redirect, it should send periodic RAs to 1012 refresh the next-hop EBR's ingress filter prefix lifetimes as long as 1013 traffic is flowing. 1015 EBRs retain the FIB entries created as a result of an ICMP redirect 1016 until all RLOC TTLs expire, or until no hints of forward progress 1017 through any of the associated RLOCs are received. In this way, RLOC 1018 liveness detection exactly parallels IPv6 Neighbor Unreachability 1019 Detection ([RFC4861], Section 3). 1021 5.5. IPv4 Router Discovery and Prefix Registration 1023 When IPv4 is used as the inner IP protocol, router discovery and 1024 prefix registration exactly parallel the mechanisms specified for 1025 IPv6 in Section 5.4. To support this, modifications to the ICMPv4 1026 Router Advertisement [RFC1256] function to include SEND constructs 1027 and modifications to the ICMPv4 Redirect [RFC0792] function to 1028 support router-to-router redirects will be specified in a future 1029 document. Additionally, publications for IPv4 prefixes will be in 1030 dotted-nibble format in the 'ip4.isatap.example.com' domain. For 1031 example, the IPv4 prefix 192.0.2/24 would be represented as: 1032 '2.0.0.0.0.c.ip4.isatap.example.com' 1034 5.6. VET Encapsulation 1036 VET nodes forward packets by consulting the FIB to determine a 1037 specific EBR/EBG as the next-hop router on a VET interface. When 1038 multiple next-hop routers are available, VET nodes can use default 1039 router preferences, routing protocol information, traffic engineering 1040 configurations, etc. to select the best exit router. When there is 1041 no FIB information other than "default" available, VET nodes can 1042 discover the next-hop EBR/EBG through the mechanisms specified in 1043 Section 5.4 and Section 5.5. 1045 VET interfaces encapsulate inner IP packets in any mid-layer headers 1046 followed by an outer IP header according to the specific 1047 encapsulation type (e.g., [RFC4301], [RFC5214], 1048 [I-D.templin-intarea-seal], etc.); they next submit the encapsulated 1049 packet to the outer IP forwarding engine for transmission on an 1050 underlying interface. 1052 For forwarding to next-hop addresses over VET interfaces that use 1053 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 1054 address (i.e., the IPv4 RLOC of the next-hop EBR) through static 1055 extraction of the IPv4 address embedded in the next-hop ISATAP 1056 address. For other IP-in-IP encapsulations, determination of the 1057 outer destination address is through administrative configuration or 1058 through an unspecified alternate method. When there are multiple 1059 candidate destination RLOCs available, the VET node should only 1060 select an RLOC for which there is current forwarding information in 1061 the outer IP protocol FIB. 1063 5.7. SEAL Encapsulation 1065 VET nodes should use SEAL encapsulation [I-D.templin-intarea-seal] 1066 over VET interfaces to accommodate path MTU diversity, to defeat 1067 source address spoofing, and to monitor next-hop EBR reachability. 1068 SEAL encapsulation maintains a unidirectional and monotonically 1069 incrementing per-packet identification value known as the 'SEAL_ID'. 1070 When a VET node that uses SEAL encapsulation sends a SEND-protected 1071 Router Advertisement (RA) or Router Solicitation (RS) message to 1072 another VET node, both nodes cache the new SEAL_ID as per-tunnel 1073 state used for maintaining a window of unacknowledged SEAL_IDs. 1075 In terms of security, when a VET node receives an ICMP message, it 1076 can confirm that the packet-in-error within the ICMP message 1077 corresponds to one of its recently sent packets by examining the 1078 SEAL_ID along with source and destination addresses, etc. 1079 Additionally, a next-hop EBR can track the SEAL_ID in packets 1080 received from EBRs for which there is an ingress filter entry and 1081 discard packets that have SEAL_ID values outside of the current 1082 window. 1084 In terms of next-hop reachability, an EBR can set the SEAL 1085 "Acknowledgement Requested" bit in messages to receive confirmation 1086 that a next-hop EBR is reachable. Setting the "Acknowledgement 1087 Requested" bit is also used as the method for maintaining the window 1088 of outstanding SEAL_IDs. 1090 5.8. Generating Errors 1092 When an EBR receives an IPv6 packet over a VET interface and there is 1093 no matching ingress filter entry, it drops the packet and returns an 1094 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 1095 ingress/egress policy" message to the previous-hop EBR subject to 1096 rate limiting. 1098 When an EBR receives an IPv6 packet over a VET interface, and there 1099 is no longest-prefix-match FIB entry for the destination, it returns 1100 an ICMPv6 "Destination Unreachable; No route to destination" message 1101 to the previous hop EBR subject to rate limiting. 1103 When an EBR receives an IPv6 packet over a VET interface and the 1104 longest-prefix-match FIB entry for the destination is via a next-hop 1105 configured over the same VET interface the packet arrived on, the EBR 1106 forwards the packet, then (if the FIB prefix is longer than ::/0) 1107 sends a router-to-router ICMPv6 Redirect message (using SEND, if 1108 necessary) to the previous-hop EBR as specified in Section 5.4.4. 1110 Generation of other ICMP messages [RFC0792] [RFC4443] is the same as 1111 for any IP interface. 1113 5.9. Processing Errors 1115 When an EBR receives an ICMPv6 "Destination Unreachable; Source 1116 address failed ingress/egress policy" message from a next-hop EBR, 1117 and there is a longest-prefix-match FIB entry for the original 1118 packet's destination that is more specific than ::/0, the EBR 1119 discards the message and marks the FIB entry for the destination as 1120 "forwarding suspended" for the RLOC taken from the source address of 1121 the ICMPv6 message. The EBR should then allow subsequent packets to 1122 flow through different RLOCs associated with the FIB entry until it 1123 forwards a new RA to the suspended RLOC. If the EBR receives 1124 excessive ICMPv6 ingress/egress policy errors through multiple RLOCs 1125 associated with the same FIB entry, it should delete the FIB entry 1126 and allow subsequent packets to flow through an EBG if supported in 1127 the specific enterprise scenario. 1129 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1130 to destination" message from a next-hop EBR, it forwards the ICMPv6 1131 message to the source of the original packet as normal. If the EBR 1132 has longest-prefix-match FIB entry for the original packet's 1133 destination that is more specific than ::/0, the EBR also deletes the 1134 FIB entry. 1136 When an EBR receives an authentic ICMPv6 Redirect, it processes the 1137 packet as specified in Section 5.4.4. 1139 When an EBG receives new mapping information for a specific 1140 destination prefix, it can propagate the update to other EBRs/EBGs by 1141 sending an ICMPv6 redirect message to the 'All Routers' link-local 1142 multicast address with an LLAO with the TTL for the unreachable LLAO 1143 set to zero, and with a NULL packet in error. 1145 Additionally, a VET node may receive ICMP "Destination Unreachable; 1146 net / host unreachable" messages from an ER indicating that the path 1147 to a VET neighbor may be failing. The VET node should first check, 1148 e.g., the SEAL_ID, IPsec sequence number, source address of the 1149 original packet if available, etc. to obtain reasonable assurance 1150 that the ICMP message is authentic, then should mark the longest- 1151 prefix-match FIB entry for the destination as "forwarding suspended" 1152 for the RLOC destination address of the ICMP packet-in-error. If the 1153 VET node receives excessive ICMP unreachable errors through multiple 1154 RLOCs associated with the same FIB entry, it should delete the FIB 1155 entry and allow subsequent packets to flow through a different route. 1157 5.10. Mobility and Multihoming Considerations 1159 EBRs that travel between distinct enterprise networks must either 1160 abandon their PA prefixes that are relative to the "old" enterprise 1161 and obtain new ones relative to the "new" enterprise or somehow 1162 coordinate with a "home" enterprise to retain ownership of the 1163 prefixes. In the first instance, the EBR would be required to 1164 coordinate a network renumbering event using the new PA prefixes 1165 [RFC4192]. In the second instance, an ancillary mobility management 1166 mechanism must be used. 1168 EBRs can retain their PI prefixes as they travel between distinct 1169 enterprise networks as long as they register the prefixes with new 1170 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1171 departure. Prefix registration with new EBGs is coordinated exactly 1172 as specified in Section 5.4.3; prefix withdrawal from old EBGs is 1173 simply through re-announcing the PI prefixes with zero lifetimes. 1175 Since EBRs can move about independently of one another, stale FIB 1176 entry state may be left in VET nodes when a neighboring EBR departs. 1177 Additionally, EBRs can lose state for various reasons, e.g., power 1178 failure, machine reboot, etc. For this reason, EBRs are advised to 1179 set relatively short PI prefix lifetimes in RIO options, and to send 1180 additional RAs to refresh lifetimes before they expire. (EBRs should 1181 place conservative limits on the RAs they send to reduce congestion, 1182 however.) 1184 EBRs may register their PI prefixes with multiple EBGs for 1185 multihoming purposes. EBRs should only forward packets via EBGs with 1186 which it has registered its PI prefixes, since other EBGs may drop 1187 the packets and return ICMPv6 "Destination Unreachable; Source 1188 address failed ingress/egress policy" messages. 1190 EBRs can also act as delegating routers to sub-delegate portions of 1191 their PI prefixes to requesting routers on their enterprise-edge 1192 interfaces and on VET interfaces for which they are configured as 1193 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1194 become the PA prefixes for downstream-dependent nodes. Downstream- 1195 dependent nodes that travel with a mobile provider EBR can continue 1196 to use addresses configured from PA prefixes; downstream-dependent 1197 nodes that move away from their provider EBR must perform address/ 1198 prefix renumbering when they associate with a new provider. 1200 The EBGs of a multihomed enterprise should participate in a private 1201 inner IP routing protocol instance between themselves (possibly over 1202 an alternate topology) to accommodate enterprise partitions/merges as 1203 well as intra-enterprise mobility events. These peer EBGs should 1204 accept packets from one another without respect to the destination 1205 (i.e., ingress filtering is based on the peering relationship rather 1206 than a prefix-specific ingress filter entry). 1208 5.11. Multicast 1210 In multicast-capable deployments, ERs provide an enterprise-wide 1211 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1212 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1213 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1214 over their enterprise-interior interfaces such that outer IP 1215 multicast messages of site-scope or greater scope will be propagated 1216 across the enterprise. For such deployments, VET nodes can also 1217 provide an inner IP multicast/broadcast capability over their VET 1218 interfaces through mapping of the inner IP multicast address space to 1219 the outer IP multicast address space. In that case, operation of 1220 link-scoped (or greater scoped) inner IP multicasting services (e.g., 1221 a link-scoped neighbor discovery protocol) over the VET interface is 1222 available, but link-scoped services should be used sparingly to 1223 minimize enterprise-wide flooding. 1225 VET nodes encapsulate inner IP multicast messages sent over the VET 1226 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1227 outer IP header with a site-scoped outer IP multicast address as the 1228 destination. For the case of IPv6 and IPv4 as the inner/outer 1229 protocols (respectively), [RFC2529] provides mappings from the IPv6 1230 multicast address space to a site-scoped IPv4 multicast address space 1231 (for other IP-in-IP encapsulations, mappings are established through 1232 administrative configuration or through an unspecified alternate 1233 static mapping). 1235 Multicast mapping for inner IP multicast groups over outer IP 1236 multicast groups can be accommodated, e.g., through VET interface 1237 snooping of inner multicast group membership and routing protocol 1238 control messages. To support inner-to-outer IP multicast mapping, 1239 the VET interface acts as a virtual outer IP multicast host connected 1240 to its underlying interfaces. When the VET interface detects that an 1241 inner IP multicast group joins or leaves, it forwards corresponding 1242 outer IP multicast group membership reports on an underlying 1243 interface over which the VET interface is configured. If the VET 1244 node is configured as an outer IP multicast router on the underlying 1245 interfaces, the VET interface forwards locally looped-back group 1246 membership reports to the outer IP multicast routing process. If the 1247 VET node is configured as a simple outer IP multicast host, the VET 1248 interface instead forwards actual group membership reports (e.g., 1249 IGMP messages) directly over an underlying interface. 1251 Since inner IP multicast groups are mapped to site-scoped outer IP 1252 multicast groups, the VET node must ensure that the site-scope outer 1253 IP multicast messages received on the underlying interfaces for one 1254 VET interface do not "leak out" to the underlying interfaces of 1255 another VET interface. This is accommodated through normal site- 1256 scoped outer IP multicast group filtering at enterprise boundaries. 1258 5.12. Service Discovery 1260 VET nodes can perform enterprise-wide service discovery using a 1261 suitable name-to-address resolution service. Examples of flooding- 1262 based services include the use of LLMNR [RFC4795] over the VET 1263 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1264 over an underlying interface. More scalable and efficient service 1265 discovery mechanisms are for further study. 1267 5.13. Enterprise Partitioning 1269 EBGs can physically partition an enterprise by configuring multiple 1270 VET interfaces over multiple distinct sets of underlying interfaces. 1271 In that case, each partition (i.e., each VET interface) must 1272 configure its own distinct 'PRLNAME' (e.g., 1273 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1275 EBGs can logically partition an enterprise using a single VET 1276 interface by sending RAs with PIOs containing different IPv6 PA 1277 prefixes to group nodes into different logical partitions. EBGs can 1278 identify partitions, e.g., by examining RLOC prefixes, observing the 1279 interfaces over which RSs are received, etc. In that case, a single 1280 'PRLNAME' can cover all partitions. 1282 5.14. EBG Prefix State Recovery 1284 EBGs must retain explicit state that tracks the inner IP prefixes 1285 owned by EBRs within the enterprise, e.g., so that packets are 1286 delivered to the correct EBRs and not incorrectly "leaked out" of the 1287 enterprise via a default route. For PA prefixes, the state is 1288 maintained via an EBR's DHCP prefix delegation lease renewals, while 1289 for PI prefixes the state is maintained via an EBR's periodic prefix 1290 registration RAs. 1292 When an EBG loses some or all of its state (e.g., due to a power 1293 failure), it must recover the state so that packets can be forwarded 1294 over correct routes. If the EBG aggregates PA prefixes from which 1295 the IP prefixes of all EBRs in the enterprise are sub-delegated, then 1296 the EBG can recover state through DHCP prefix delegation lease 1297 renewals, through bulk lease queries, or through on-demand name- 1298 service lookups based due to IP packet forwarding. If the EBG serves 1299 as an anchor for PI prefixes, however, care must be taken to avoid 1300 looping while state is recovered through prefix registration RAs from 1301 EBRs. In that case, when the EBG that is recovering state forwards 1302 an IP packet for which it has no explicit route other than ::/0, it 1303 must first perform an on-demand name-service lookup to refresh state. 1305 6. IANA Considerations 1307 There are no IANA considerations for this document. 1309 7. Security Considerations 1311 Security considerations for MANETs are found in [RFC2501]. 1313 Security considerations with tunneling that apply also to VET are 1314 found in [RFC2529] [RFC5214]. In particular, VET nodes must verify 1315 that the outer IP source address of a packet received on a VET 1316 interface is correct for the inner IP source address using the 1317 procedures specified in Section 7.3 of [RFC5214] in conjunction with 1318 the ingress filtering mechanisms specified in this document. 1320 SEND [RFC3971], IPsec [RFC4301], and SEAL [I-D.templin-intarea-seal] 1321 provide additional securing mitigations to detect source address 1322 spoofing and bogus RA messages sent by rogue routers. 1324 Rogue routers can send bogus RA messages with spoofed RLOC source 1325 addresses that can consume network resources and cause EBGs to 1326 perform extra work. Nonetheless, EBGs should not "blacklist" such 1327 RLOCs, as that may result in a denial of service to the RLOCs' 1328 legitimate owners. 1330 8. Related Work 1332 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1333 automatic tunneling in [RFC2529]; this concept was later called: 1334 "Virtual Ethernet" and investigated by Quang Nguyen under the 1335 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1336 their colleagues have motivated a number of foundational concepts on 1337 which this work is based. 1339 Telcordia has proposed DHCP-related solutions for MANETs through the 1340 CECOM MOSAIC program. 1342 The Naval Research Lab (NRL) Information Technology Division uses 1343 DHCP in their MANET research testbeds. 1345 Security concerns pertaining to tunneling mechanisms are discussed in 1346 [I-D.ietf-v6ops-tunnel-security-concerns]. 1348 Default router and prefix information options for DHCPv6 are 1349 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1351 An automated IPv4 prefix delegation mechanism is proposed in 1352 [I-D.ietf-dhc-subnet-alloc]. 1354 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1355 [I-D.clausen-manet-autoconf-recommendations]. 1357 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1359 Various proposals within the IETF have suggested similar mechanisms. 1361 9. Acknowledgements 1363 The following individuals gave direct and/or indirect input that was 1364 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1365 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1366 Ralph Droms, Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, 1367 Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe 1368 Macker, David Meyer, Thomas Narten, Pekka Nikander, Dave Oran, 1369 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole 1370 Troan, Michaela Vanderveen, Lixia Zhang, and others in the IETF 1371 AUTOCONF and MANET working groups. Many others have provided 1372 guidance over the course of many years. 1374 10. Contributors 1376 The following individuals have contributed to this document: 1378 Eric Fleischman (eric.fleischman@boeing.com) 1379 Thomas Henderson (thomas.r.henderson@boeing.com) 1380 Steven Russert (steven.w.russert@boeing.com) 1381 Seung Yi (seung.yi@boeing.com) 1383 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1384 of the document. 1386 Jim Bound's foundational work on enterprise networks provided 1387 significant guidance for this effort. We mourn his loss and honor 1388 his contributions. 1390 11. References 1392 11.1. Normative References 1394 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1395 September 1981. 1397 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1398 RFC 792, September 1981. 1400 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1401 converting network protocol addresses to 48.bit Ethernet 1402 address for transmission on Ethernet hardware", STD 37, 1403 RFC 826, November 1982. 1405 [RFC1035] Mockapetris, P., "Domain names - implementation and 1406 specification", STD 13, RFC 1035, November 1987. 1408 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1409 RFC 2131, March 1997. 1411 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1412 (IPv6) Specification", RFC 2460, December 1998. 1414 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1415 Update", RFC 3007, November 2000. 1417 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1418 and M. Carney, "Dynamic Host Configuration Protocol for 1419 IPv6 (DHCPv6)", RFC 3315, July 2003. 1421 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1422 "DNS Extensions to Support IP Version 6", RFC 3596, 1423 October 2003. 1425 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1426 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1427 December 2003. 1429 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1430 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1432 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1433 RFC 3972, March 2005. 1435 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1436 More-Specific Routes", RFC 4191, November 2005. 1438 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1439 Architecture", RFC 4291, February 2006. 1441 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1442 Message Protocol (ICMPv6) for the Internet Protocol 1443 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1445 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1446 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1447 September 2007. 1449 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1450 Address Autoconfiguration", RFC 4862, September 2007. 1452 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1453 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1454 March 2008. 1456 11.2. Informative References 1458 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1459 Switching Networks", May 1974. 1461 [I-D.cheshire-dnsext-multicastdns] 1462 Cheshire, S. and M. Krochmal, "Multicast DNS", 1463 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1464 September 2008. 1466 [I-D.clausen-manet-autoconf-recommendations] 1467 Clausen, T. and U. Herberg, "MANET Router Configuration 1468 Recommendations", 1469 draft-clausen-manet-autoconf-recommendations-00 (work in 1470 progress), February 2009. 1472 [I-D.clausen-manet-linktype] 1473 Clausen, T., "The MANET Link Type", 1474 draft-clausen-manet-linktype-00 (work in progress), 1475 October 2008. 1477 [I-D.droms-dhc-dhcpv6-default-router] 1478 Droms, R. and T. Narten, "Default Router and Prefix 1479 Advertisement Options for DHCPv6", 1480 draft-droms-dhc-dhcpv6-default-router-00 (work in 1481 progress), March 2009. 1483 [I-D.ietf-autoconf-manetarch] 1484 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1485 Network Architecture", draft-ietf-autoconf-manetarch-07 1486 (work in progress), November 2007. 1488 [I-D.ietf-csi-proxy-send] 1489 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1490 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1491 in progress), November 2008. 1493 [I-D.ietf-dhc-subnet-alloc] 1494 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1495 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-09 1496 (work in progress), March 2009. 1498 [I-D.ietf-ipv6-ula-central] 1499 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1500 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1501 progress), June 2007. 1503 [I-D.ietf-manet-smf] 1504 Macker, J. and S. Team, "Simplified Multicast Forwarding 1505 for MANET", draft-ietf-manet-smf-08 (work in progress), 1506 November 2008. 1508 [I-D.ietf-v6ops-tunnel-security-concerns] 1509 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1510 Concerns With IP Tunneling", 1511 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1512 progress), October 2008. 1514 [I-D.jen-apt] 1515 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1516 L. Zhang, "APT: A Practical Transit Mapping Service", 1517 draft-jen-apt-01 (work in progress), November 2007. 1519 [I-D.russert-rangers] 1520 Russert, S., Fleischman, E., and F. Templin, "RANGER 1521 Scenarios", draft-russert-rangers-00 (work in progress), 1522 May 2009. 1524 [I-D.templin-intarea-seal] 1525 Templin, F., "The Subnetwork Encapsulation and Adaptation 1526 Layer (SEAL)", draft-templin-intarea-seal-04 (work in 1527 progress), June 2009. 1529 [I-D.templin-ranger] 1530 Templin, F., "Routing and Addressing in Next-Generation 1531 EnteRprises (RANGER)", draft-templin-ranger-07 (work in 1532 progress), February 2009. 1534 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1535 July 1978. 1537 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1538 Protocol Specification", October 2008. 1540 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1541 Communication Layers", STD 3, RFC 1122, October 1989. 1543 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1544 September 1991. 1546 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1547 Routing and Addressing Architecture", RFC 1753, 1548 December 1994. 1550 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1551 E. Lear, "Address Allocation for Private Internets", 1552 BCP 5, RFC 1918, February 1996. 1554 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1555 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1557 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1558 (MANET): Routing Protocol Performance Issues and 1559 Evaluation Considerations", RFC 2501, January 1999. 1561 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1562 Domains without Explicit Tunnels", RFC 2529, March 1999. 1564 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1565 February 2000. 1567 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1568 via IPv4 Clouds", RFC 3056, February 2001. 1570 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1571 Networks", BCP 84, RFC 3704, March 2004. 1573 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1574 RFC 3753, June 2004. 1576 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1577 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1578 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1579 RFC 3819, July 2004. 1581 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1582 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1583 May 2005. 1585 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1586 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1587 September 2005. 1589 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1590 Addresses", RFC 4193, October 2005. 1592 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1593 Internet Protocol", RFC 4301, December 2005. 1595 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1596 Network Address Translations (NATs)", RFC 4380, 1597 February 2006. 1599 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1600 Proxies (ND Proxy)", RFC 4389, April 2006. 1602 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1603 Multicast Name Resolution (LLMNR)", RFC 4795, 1604 January 2007. 1606 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1607 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1608 Focus", RFC 4852, April 2007. 1610 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1611 June 2007. 1613 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1614 Extensions for Stateless Address Autoconfiguration in 1615 IPv6", RFC 4941, September 2007. 1617 Appendix A. Duplicate Address Detection (DAD) Considerations 1619 A priori uniqueness determination (also known as "pre-service DAD") 1620 for an RLOC assigned on an enterprise-interior interface would 1621 require either flooding the entire enterprise or somehow discovering 1622 a link in the enterprise on which a node that configures a duplicate 1623 address is attached and performing a localized DAD exchange on that 1624 link. But, the control message overhead for such an enterprise-wide 1625 DAD would be substantial and prone to false-negatives due to packet 1626 loss and intermittent connectivity. An alternative to pre-service 1627 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1628 interfaces and employ a passive in-service DAD (e.g., one that 1629 monitors routing protocol messages for duplicate assignments). 1631 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1632 CGAs, IPv6 privacy addresses, etc. with very small probability of 1633 collision. Pseudo-random IPv4 RLOCs can be generated through random 1634 assignment from a suitably large IPv4 prefix space. 1636 Consistent operational practices can assure uniqueness for EBG- 1637 aggregated addresses/prefixes, while statistical properties for 1638 pseudo-random address self-generation can assure uniqueness for the 1639 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1640 RLOC delegation authority should be used when available, while a 1641 passive in-service DAD mechanism should be used to detect RLOC 1642 duplications when there is no RLOC delegation authority. 1644 Appendix B. Link Layer Multiplexing and Traffic Engineering 1646 For each distinct enterprise that it connects to, an EBR configures a 1647 VET interface over possibly multiple underlying interfaces that all 1648 connect to the same enterprise. The VET interface therefore 1649 represents the EBR's logical point of attachment to the enterprise, 1650 and provides a logical interface for link-layer multiplexing over its 1651 underlying interfaces as described in Section 3.3.4.1 of [RFC1122]: 1653 "Finally, we note another possibility that is NOT multihoming: one 1654 logical interface may be bound to multiple physical interfaces, in 1655 order to increase the reliability or throughput between directly 1656 connected machines by providing alternative physical paths between 1657 them. For instance, two systems might be connected by multiple 1658 point-to-point links. We call this "link-layer multiplexing". 1659 With link-layer multiplexing, the protocols above the link layer 1660 are unaware that multiple physical interfaces are present; the 1661 link- layer device driver is responsible for multiplexing and 1662 routing packets across the physical interfaces." 1664 EBRs support this link-layer multiplexing in accordance with the Weak 1665 End System Model (see Section 3.3.4.2 of [RFC1122]). In particular, 1666 when an EBR autoconfigures an RLOC address (see Section 4.1), it can 1667 assign the RLOC to the VET interface instead of an underlying 1668 interface. The EBR therefore only needs to obtain a single RLOC 1669 address if there are multiple underlying interfaces, i.e., it does 1670 not need to obtain one for each underlying interface. The EBR can 1671 then leave the underlying interfaces unnumbered, or it can configure 1672 a randomly chosen IP link-local address (e.g., from the prefix 1673 169.254/16 [RFC3927] for IPv4) on underlying interfaces that require 1674 a configuration. The EBR need not check these link-local addresses 1675 for uniqueness within the enterprise, as they will not normally be 1676 used as the source address for packets. 1678 When the EBR discovers a route via the enterprise interior routing 1679 protocol, it configures a preferred route in the IP FIB that points 1680 to the VET interface instead of the underlying interface. At the 1681 same time, the EBR also configures an ancillary route that points to 1682 the underlying interface. If the EBR discovers that the same route 1683 is reachable via multiple underlying interfaces, the EBR configures 1684 multiple ancillary routes (i.e., one for each interface). If the EBR 1685 discovers that the route is no longer reachable via any underlying 1686 interface, it removes the route in the IP FIB that points to the VET 1687 interface. 1689 With these arrangements, all locally-generated packets with RLOC 1690 destinations will flow through the VET interface (and thereby use the 1691 VET interface's RLOC address as the source address) instead of 1692 through the underlying interfaces. In the same fashion, all 1693 forwarded packets with RLOC destinations will flow through the VET 1694 interface instead of through the underlying interfaces. 1696 This arrangement has several operational advantages that enable a 1697 number of traffic engineering capabilities. First, the VET interface 1698 can insert the SEAL header so that ID-based duplicate packet 1699 detection is enabled within the enterprise. Secondly, SEAL can 1700 dynamically adjust its packet sizing parameters so that an optimum 1701 Maximum Transmission Unit (MTU) can be determined. This is true even 1702 if the VET interface reroutes traffic between underlying interfaces 1703 with different MTUs. 1705 Moreover, the EBR can configure default and more-specific routes on 1706 the VET interface to direct traffic through a specific egress EBR 1707 (eEBR) that may be many hops away. Encapsulation will ensure that a 1708 specific eEBR is chosen, and the best eEBR can be chosen when 1709 multiple are available. Also, local applications see a stable IP 1710 source address even if there are multiple underlying interfaces. 1711 This link-layer multiplexing can therefore provide continuous 1712 operation across failovers between multiple links attached to the 1713 same enterprise without any need for readdressing. Finally, the VET 1714 interface can forward packets with RLOC-based destinations over an 1715 underlying interface without any encapsulation if encapsulation 1716 avoidance is desired. 1718 It must be specifically noted that the above arrangement constitutes 1719 a case in which the same RLOC may be used as both the inner and outer 1720 IP source address. This will not present a problem as long as both 1721 ends configure a VET interface in the same fashion. This can be 1722 determined based on a handshake between nodes, e.g., if one end 1723 supports SEAL encapsulation and the other does not the traffic 1724 engineering approach cannot be used. 1726 It must also be noted that EID-based communications can use the same 1727 VET interface arrangement, except that the EID-based next hop must be 1728 mapped to an RLOC-based next-hop within the VET interface. For IPvX- 1729 in-IPvX encapsulation, as well as for IPv4-in-IPv6 encapsulation, 1730 this requires a VET interface specific address mapping database. For 1731 IPv6-in-IPv4 encapsulation, the mapping is accomplished through 1732 simple static extraction of an IPv4 address embedded in an IPv6 1733 ISATAP address. 1735 Appendix C. Change Log 1737 (Note to RFC editor - this section to be removed before publication 1738 as an RFC.) 1739 Changes from -00 to -00: 1741 o Section 4.1 clarifications on link-local assignment and RLOC 1742 autoconfiguration. 1744 o Appendix B clarifications on Weak End System Model 1746 Changes from RFC5558 to -00: 1748 o New appendix on RLOC configuration on VET intefaces. 1750 Author's Address 1752 Fred L. Templin (editor) 1753 Boeing Research & Technology 1754 P.O. Box 3707 MC 7L-49 1755 Seattle, WA 98124 1756 USA 1758 Email: fltemplin@acm.org