idnits 2.17.1 draft-templin-intarea-vet-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 918: '...prefixes, but it MUST NOT include any ...' RFC 2119 keyword, line 932: '...erfaces; the EBR MAY include multiple ...' RFC 2119 keyword, line 950: '...ion. However, the EBR MUST NOT assign...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 23, 2009) is 5236 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1035' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: 'RFC3007' is defined on line 1509, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 1516, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-dhcpv6-agentopt-delegate' is defined on line 1593, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1681, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1687, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-07 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-08 == Outdated reference: A later version (-02) exists of draft-hain-ipv6-ulac-01 == Outdated reference: A later version (-05) exists of draft-ietf-csi-proxy-send-01 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-04 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-10 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-09 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 == Outdated reference: A later version (-03) exists of draft-nakibly-v6ops-tunnel-loops-00 == Outdated reference: A later version (-05) exists of draft-russert-rangers-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 7 errors (**), 0 flaws (~~), 20 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 December 23, 2009 5 Expires: June 26, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-05.txt 10 Abstract 12 Enterprise networks connect hosts and routers over various link 13 types, and may also connect to provider networks and/or the global 14 Internet. Enterprise network nodes require a means to automatically 15 provision IP addresses/prefixes and support internetworking operation 16 in a wide variety of use cases including Small Office, Home Office 17 (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, 18 multi-organizational corporate networks and the interdomain core of 19 the global Internet itself. This document specifies a Virtual 20 Enterprise Traversal (VET) abstraction for autoconfiguration and 21 operation of nodes in enterprise networks. VET can also be 22 considered as version 2 of the Intra-Site Automatic Tunnel Addressing 23 Protocol (i.e., "ISATAPv2"). 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on June 26, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 11 67 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 12 69 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 14 70 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 14 71 4.2.2. Provider-Aggregated (PA) EID Prefix 72 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 73 4.2.3. Provider-Independent (PI) EID Prefix 74 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 75 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 18 76 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 18 77 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 19 78 5.1. Prefix Registration . . . . . . . . . . . . . . . . . . . 19 79 5.2. Routing Protocol Participation . . . . . . . . . . . . . . 20 80 5.3. Address Selection . . . . . . . . . . . . . . . . . . . . 20 81 5.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 20 82 5.4.1. Router and Prefix Discovery . . . . . . . . . . . . . 21 83 5.4.2. Next Hop Determination . . . . . . . . . . . . . . . . 23 84 5.4.3. Redirect Function . . . . . . . . . . . . . . . . . . 24 85 5.4.4. Reverse Path Forwarding Checks . . . . . . . . . . . . 25 86 5.4.5. IPv4 Neighbor Discovery . . . . . . . . . . . . . . . 25 87 5.5. Generating Errors . . . . . . . . . . . . . . . . . . . . 25 88 5.6. Processing Errors . . . . . . . . . . . . . . . . . . . . 26 89 5.7. Mobility and Multihoming Considerations . . . . . . . . . 27 90 5.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28 91 5.9. Service Discovery . . . . . . . . . . . . . . . . . . . . 29 92 5.10. Enterprise Partitioning . . . . . . . . . . . . . . . . . 29 93 5.11. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 29 94 5.12. Support for Legacy ISATAP Services . . . . . . . . . . . . 29 95 5.13. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 29 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 98 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 100 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 104 Appendix A. Duplicate Address Detection (DAD) Considerations . . 38 105 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 39 106 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 41 107 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 42 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 110 1. Introduction 112 Enterprise networks [RFC4852] connect hosts and routers over various 113 link types (see [RFC4861], Section 2.2). The term "enterprise 114 network" in this context extends to a wide variety of use cases and 115 deployment scenarios. For example, an "enterprise" can be as small 116 as a SOHO network, as complex as a multi-organizational corporation, 117 or as large as the global Internet itself. ISP networks are another 118 example use case that fits well with the VET enterprise network 119 model. Mobile Ad hoc Networks (MANETs) [RFC2501] can also be 120 considered as a challenging example of an enterprise network, in that 121 their topologies may change dynamically over time and that they may 122 employ little/no active management by a centralized network 123 administrative authority. These specialized characteristics for 124 MANETs require careful consideration, but the same principles apply 125 equally to other enterprise network scenarios. 127 This document specifies a Virtual Enterprise Traversal (VET) 128 abstraction for autoconfiguration and internetworking operation, 129 where addresses of different scopes may be assigned on various types 130 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 131 [RFC2460] are discussed within this context. The use of standard 132 DHCP [RFC2131] [RFC3315] and neighbor discovery [RFC0826] [RFC1256] 133 [RFC4861] mechanisms is assumed unless otherwise specified. 135 Provider-Edge Interfaces 136 x x x 137 | | | 138 +--------------------+---+--------+----------+ E 139 | | | | | n 140 | I | | .... | | t 141 | n +---+---+--------+---+ | e 142 | t | +--------+ /| | r 143 | e I x----+ | Host | I /*+------+--< p I 144 | r n | |Function| n|**| | r n 145 | n t | +--------+ t|**| | i t 146 | a e x----+ V e|**+------+--< s e 147 | l r . | E r|**| . | e r 148 | f . | T f|**| . | f 149 | V a . | +--------+ a|**| . | I a 150 | i c . | | Router | c|**| . | n c 151 | r e x----+ |Function| e \*+------+--< t e 152 | t s | +--------+ \| | e s 153 | u +---+---+--------+---+ | r 154 | a | | .... | | i 155 | l | | | | o 156 +--------------------+---+--------+----------+ r 157 | | | 158 x x x 159 Enterprise-Edge Interfaces 161 Figure 1: Enterprise Router (ER) Architecture 163 Figure 1 above depicts the architectural model for an Enterprise 164 Router (ER). As shown in the figure, an ER may have a variety of 165 interface types including enterprise-edge, enterprise-interior, 166 provider-edge, internal-virtual, as well as VET interfaces used for 167 IP in IP encapsulation. The different types of interfaces are 168 defined, and the autoconfiguration mechanisms used for each type are 169 specified. This architecture applies equally for MANET routers, in 170 which enterprise-interior interfaces correspond to the wireless 171 multihop radio interfaces typically associated with MANETs. Out of 172 scope for this document is the autoconfiguration of provider 173 interfaces, which must be coordinated in a manner specific to the 174 service provider's network. 176 Enterprise networks must have a means for supporting both Provider- 177 Independent (PI) and Provider-Aggregated (PA) addressing. This is 178 especially true for enterprise scenarios that involve mobility and 179 multihoming. Also in scope are ingress filtering for multihomed 180 sites, adaptation based on authenticated ICMP feedback from on-path 181 routers, effective tunnel path MTU mitigations, and routing scaling 182 suppression as required in many enterprise network scenarios. The 183 VET specification provides adaptable mechanisms that address these 184 and other issues in a wide variety of enterprise network use cases. 186 VET represents a functional superset of 6over4 [RFC2529] and the 187 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], 188 and can be considered as version 2 of the ISATAP protocol (i.e., 189 "ISATAPv2"). VET works in conjunction with the Subnetwork 190 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal], 191 and also supports additional encapsulations such as IPsec [RFC4301]. 192 VET further defines mechanisms that are very similar in nature to 193 those specified for IPv6 operation over Non-Broadcast Multiple Access 194 (NBMA) networks [RFC2491]. 196 VET and its associated technologies serve as functional building 197 blocks for a new Internetworking architecture known as Routing and 198 Addressing in Next Generation EnteRprises [I-D.templin-ranger] 199 [I-D.russert-rangers]. The VET principles can be either directly or 200 indirectly traced to the deliberations of the ROAD group in January 201 1992, and also to still earlier works including NIMROD [RFC1753] and 202 the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. 203 [RFC1955] captures the high-level architectural aspects of the ROAD 204 group deliberations in a "New Scheme for Internet Routing and 205 Addressing (ENCAPS) for IPNG". 207 VET is related to the present-day activities of the IETF INTAREA, 208 AUTOCONF, DHC, IPv6, MANET, and V6OPS working groups, as well as the 209 IRTF RRG working group. 211 2. Terminology 213 The mechanisms within this document build upon the fundamental 214 principles of IP in IP encapsulation. The terms "inner" and "outer" 215 are used to, respectively, refer to the innermost IP {address, 216 protocol, header, packet, etc.} *before* encapsulation, and the 217 outermost IP {address, protocol, header, packet, etc.} *after* 218 encapsulation. VET also uses the Subnetwork Encapsulation and 219 Adaptation Layer (SEAL) [I-D.templin-intarea-seal] as a "mid-layer" 220 encapsulation between the inner and outer IP headers, and also allows 221 for inclusion of other mid-layer encapsulations including IPSec 222 [RFC4301]. 224 The terminology in the normative references apply; the following 225 terms are defined within the scope of this document: 227 Virtual Enterprise Traversal (VET) 228 an abstraction that uses IP in IP encapsulation to create overlays 229 for traversing enterprise networks. VET can be considered as 230 version 2 of the ISATAP protocol (i.e., "ISATAPv2"). 232 enterprise 233 the same as defined in [RFC4852]. An enterprise is also 234 understood to refer to a cooperative networked collective with a 235 commonality of business, social, political, etc. interests. 236 Minimally, the only commonality of interest in some enterprise 237 network scenarios may be the cooperative provisioning of 238 connectivity itself. 240 subnetwork 241 the same as defined in [RFC3819]. 243 site 244 a logical and/or physical grouping of interfaces that connect a 245 topological area less than or equal to an enterprise in scope. A 246 site within an enterprise can, in some sense, be considered as an 247 enterprise unto itself. 249 Mobile Ad hoc Network (MANET) 250 a connected topology of mobile or fixed routers that maintain a 251 routing structure among themselves over dynamic links. The 252 characteristics of MANETs are defined in [RFC2501], Section 3, and 253 a wide variety of MANETs share common properties with enterprise 254 networks 256 enterprise/site/MANET 257 throughout the remainder of this document, the term "enterprise" 258 is used to collectively refer to any of {enterprise, site, MANET}, 259 i.e., the VET mechanisms and operational principles can be applied 260 to enterprises, sites, and MANETs of any size or shape. 262 Enterprise Router (ER) 263 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 264 mobile router that comprises a router function, a host function, 265 one or more enterprise-interior interfaces, and zero or more 266 internal virtual, enterprise-edge, provider-edge, and VET 267 interfaces. At a minimum, an ER forwards outer IP packets over 268 one or more sets of enterprise-interior interfaces, where each set 269 connects to a distinct enterprise. 271 Enterprise Border Router (EBR) 272 an ER that connects edge networks to the enterprise and/or 273 connects multiple enterprises together. An EBR is a tunnel 274 endpoint router, and it configures a separate VET interface over 275 each set of enterprise-interior interfaces that connect the EBR to 276 each distinct enterprise. In particular, an EBR may configure 277 multiple VET interfaces - one for each distinct enterprise. All 278 EBRs are also ERs. 280 Enterprise Border Gateway (EBG) 281 an EBR that connects VET interfaces configured over child 282 enterprises to a provider network - either directly via a 283 provider-edge interface or indirectly via another VET interface 284 configured over a parent enterprise. EBRs may act as EBGs on some 285 VET interfaces and as ordinary EBRs on other VET interfaces. All 286 EBGs are also EBRs. 288 VET host 289 any node (host or router) that configures a VET interface for 290 host-operation only. Note that a node may configure some of its 291 VET interfaces as host interfaces and others as router interfaces. 293 VET node 294 any node (host or router) that configures and uses a VET 295 interface. 297 enterprise-interior interface 298 an ER's attachment to a link within an enterprise. Packets sent 299 over enterprise-interior interfaces may be forwarded over multiple 300 additional enterprise-interior interfaces within the enterprise 301 before they are forwarded via an enterprise-edge interface, 302 provider-edge interface, or a VET interface configured over a 303 different enterprise. Enterprise-interior interfaces connect 304 laterally within the IP network hierarchy. 306 enterprise-edge interface 307 an EBR's attachment to a link (e.g., an Ethernet, a wireless 308 personal area network, etc.) on an arbitrarily complex edge 309 network that the EBR connects to an enterprise and/or provider 310 network. Enterprise-edge interfaces connect to lower levels 311 within the IP network hierarchy. 313 provider-edge interface 314 an EBR's attachment to the Internet or to a provider network 315 outside of the enterprise via which the Internet can be reached. 316 Provider-edge interfaces connect to higher levels within the IP 317 network hierarchy. 319 internal-virtual interface 320 an interface that is internal to an EBR and does not in itself 321 directly attach to a tangible physical link, e.g., an Ethernet 322 cable. Examples include a loopback interface, a virtual private 323 network interface, or some form of tunnel interface. 325 VET link 326 a virtual link that uses automatic tunneling to create an overlay 327 network that spans an enterprise-interior routing region. VET 328 links can be segmented (e.g., by IP in IP protocol filtering 329 gateways) into multiple distinct segments that can be joined 330 together by bridges or IP routers the same as for any link. 331 Bridging would view the multiple (bridged) segments as a single 332 VET link, whereas IP routing would view the multiple segments as 333 multiple distinct VET links. VET link segments can further be 334 partitioned into multiple logical routing areas, where each area 335 is identified by a distinct set of EBGs. 337 VET links in non-multicast environments are Non-Broadcast, 338 Multiple Access (NBMA); VET links in multicast environments are 339 multicast capable. 341 VET interface 342 a VET node's attachment to a VET link. VET nodes configure each 343 VET interface over a set of underlying interfaces that connect to 344 an enterprise-interior routing region spanned by a single VET 345 link. When there are multiple distinct VET links (each with their 346 own distinct set of underlying interfaces), the VET node 347 configures a separate VET interface for each link. Similarly, 348 when a VET link comprises multiple areas, a separate VET interface 349 is configured for each area. 351 The VET interface encapsulates each inner IP packet in any mid- 352 layer headers followed by an outer IP header, then forwards the 353 packet on an underlying interface such that the Time to Live (TTL) 354 - Hop Limit in the inner header is not decremented as the packet 355 traverses the link. 357 VET address 358 an IPv6 address assigned to a VET interface that embeds an IPv4 359 address within the IPv6 address interface identifier. VET 360 addresses are formed exactly as specified for ISATAP addresses in 361 Sections 6.1 and 6.2 of [RFC5214]. 363 Provider-Independent (PI) prefix 364 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 365 that is either self-generated by an EBR or delegated to an EBR by 366 a registry. 368 Provider Aggregated (PA) prefix 369 an IPv6 or IPv4 prefix that is delegated to an EBR by a provider 370 network. 372 Routing Locator (RLOC) 373 a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix 374 that can appear in enterprise-interior and/or interdomain routing 375 tables. Global-scope RLOC prefixes are delegated to specific 376 enterprises and routable within both the enterprise-interior and 377 interdomain routing regions. Enterprise-local-scope RLOC prefixes 378 (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 privacy 379 addresses [RFC1918], etc.) are self-generated by individual 380 enterprises and routable only within the enterprise-interior 381 routing region. 383 ERs use RLOCs for operating the enterprise-interior routing 384 protocol and for next-hop determination in forwarding packets 385 addressed to other RLOCs. End systems use RLOCs as addresses for 386 communications between endpoints within the same enterprise. VET 387 interfaces treat RLOCs as *outer* IP addresses during IP in IP 388 encapsulation. 390 Endpoint Interface iDentifier (EID) 391 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 392 within an enterprise-edge or VET overlay network scope, and may 393 also appear in enterprise-interior and/or interdomain mapping 394 tables. EID prefixes are separate and distinct from any RLOC 395 prefix space. 397 Edge network routers use EIDs for operating the enterprise-edge or 398 VET overlay network routing protocol and for next-hop 399 determination in forwarding packets addressed to other EIDs. End 400 systems use EIDs as addresses for communications between endpoints 401 either within the same enterprise or within different enterprises. 402 VET interfaces treat EIDs as *inner* IP addresses during IP in IP 403 encapsulation. 405 The following additional acronyms are used throughout the document: 407 CGA - Cryptographically Generated Address 408 DHCP(v4, v6) - Dynamic Host Configuration Protocol 409 FIB - Forwarding Information Base 410 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 411 NBMA - Non-Broadcast, Multiple Access 412 ND - Neighbor Discovery 413 PIO - Prefix Information Option 414 PRL - Potential Router List 415 PRLNAME - Identifying name for the PRL (default is "isatapv2") 416 RIO - Route Information Option 417 RPF - Reverse Path Forwarding 418 RS/RA - IPv6 ND Router Solicitation/Advertisement 419 SEAL - Subnetwork Encapsulation and Adaptation Layer 420 SLAAC - IPv6 StateLess Address AutoConfiguation 422 3. Enterprise Characteristics 424 Enterprises consist of links that are connected by Enterprise Routers 425 (ERs) as depicted in Figure 1. ERs typically participate in a 426 routing protocol over enterprise-interior interfaces to discover 427 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 428 Enterprise Border Routers (EBRs) are ERs that connect edge networks 429 to the enterprise and/or join multiple enterprises together. 430 Enterprise Border Gateways (EBGs) are EBRs that connect enterprises 431 to provider networks. 433 Conceptually, an ER embodies both a host function and router 434 function. The host function supports Endpoint Interface iDentifier 435 (EID)-based and/or Routing LOCator (RLOC)-based communications 436 according to the weak end-system model [RFC1122]. The router 437 function engages in the enterprise-interior routing protocol, 438 connects any of the ER's edge networks to the enterprise, and may 439 also connect the enterprise to provider networks (see Figure 1). 441 An enterprise may be as simple as a small collection of ERs and their 442 attached edge networks; an enterprise may also contain other 443 enterprises and/or be a subnetwork of a larger enterprise. An 444 enterprise may further encompass a set of branch offices and/or 445 nomadic hosts connected to a home office over one or several service 446 providers, e.g., through Virtual Private Network (VPN) tunnels. 447 Finally, an enterprise may contain many internal partitions that are 448 logical or physical groupings of nodes for the purpose of load 449 balancing, organizational separation, etc. In that case, each 450 internal partition resembles either a distinct area on the VET link 451 or a distinct VET link segment that can be connected to other 452 partitions via either L2 bridging or L3 routing. 454 Enterprises that comprise link types with sufficiently similar 455 properties (e.g., Layer 2 (L2) address formats, maximum transmission 456 units (MTUs), etc.) can configure a sub-IP layer routing service such 457 that IP sees the enterprise as an ordinary shared link the same as 458 for a (bridged) campus LAN. In that case, a single IP hop is 459 sufficient to traverse the enterprise without IP layer encapsulation. 460 Enterprises that comprise link types with diverse properties and/or 461 configure multiple IP subnets must also provide an enterprise- 462 interior routing service that operates as an IP layer mechanism. In 463 that case, multiple IP hops may be necessary to traverse the 464 enterprise such that care must be taken to avoid multi-link subnet 465 issues [RFC4903]. 467 In addition to other interface types, VET nodes configure VET 468 interfaces that view all other nodes on the VET link area as single- 469 hop neighbors. VET nodes configure a separate VET interface for each 470 distinct VET link are to which they connect, and discover other EBRs 471 on each VET link that can be used for forwarding packets to off-link 472 destinations. 474 For each distinct enterprise, an enterprise trust basis must be 475 established and consistently applied. For example, in enterprises in 476 which EBRs establish symmetric security associations, mechanisms such 477 as IPsec [RFC4301] can be used to assure authentication and 478 confidentiality. In other enterprise network scenarios, asymmetric 479 securing mechanisms such as SEcure Neighbor Discovery (SEND) 480 [RFC3971] may be necessary to authenticate exchanges based on trust 481 anchors. Still other enterprises may have sufficient infrastructure 482 trust basis (e.g., through proper deployment of filtering gateways at 483 enterprise borders) and may not require nodes to implement such 484 additional mechanisms. 486 Finally, in enterprises with a centralized management structure 487 (e.g., a corporate campus network), an enterprise mapping service and 488 a synchronized set of EBGs can provide sufficient infrastructure 489 support for virtual enterprise traversal. In that case, the EBGs can 490 provide a "default mapper" [I-D.jen-apt] service used for short-term 491 packet forwarding until EBR neighbor relationships can be 492 established. In enterprises with a distributed management structure 493 (e.g., MANETs), peer-to-peer coordination between the EBRs themselves 494 may be required. Recognizing that various use cases will entail a 495 continuum between a fully distributed and fully centralized approach, 496 the following sections present the mechanisms of Virtual Enterprise 497 Traversal as they apply to a wide variety of scenarios. 499 4. Autoconfiguration 501 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 502 specified in the following subsections. 504 4.1. Enterprise Router (ER) Autoconfiguration 506 ERs configure enterprise-interior interfaces and engage in any 507 routing protocols over those interfaces. 509 When an ER joins an enterprise, it first configures an IPv6 link- 510 local address on each enterprise-interior interface and configures an 511 IPv4 link-local address on each enterprise-interior interface that 512 requires an IPv4 link-local capability. IPv6 link-local address 513 generation mechanisms include Cryptographically Generated Addresses 514 (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 515 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 516 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 517 provide an IPv4 link-local address generation capability. 519 Next, the ER configures one or more RLOCs and engages in any routing 520 protocols on its enterprise-interior interfaces. The ER can 521 configure RLOCs via explicit management, DHCP autoconfiguration, 522 pseudo-random self-generation from a suitably large address pool, or 523 through an alternate autoconfiguration mechanism. The ER may 524 optionally configure and assign a separate RLOC for each underlying 525 interface, or it may configure only a single RLOC and assign it to a 526 VET interface configured over the underlying interfaces (see Section 527 4.2.1). In the latter case, the ER can use the VET interface for 528 link layer multiplexing and traffic engineering purposes as specified 529 in Appendix B. 531 Alternatively (or in addition), the ER can request RLOC prefix 532 delegations via an automated prefix delegation exchange over an 533 enterprise-interior interface and can assign the prefix(es) on 534 enterprise-edge interfaces. Note that in some cases, the same 535 enterprise-edge interfaces may assign both RLOC and EID addresses if 536 there is a means for source address selection. In other cases (e.g., 537 for separation of security domains), RLOCs and EIDs must be assigned 538 on separate sets of enterprise-edge interfaces. 540 Self-generation of RLOCs for IPv6 can be from a large public or 541 local-use IPv6 address range (e.g., IPv6 Unique Local Addresses 542 [RFC4193]). Self-generation of RLOCs for IPv4 can be from a large 543 public or local-use IPv4 address range (e.g., [RFC1918]). When self- 544 generation is used alone, the ER must continuously monitor the RLOCs 545 for uniqueness, e.g., by monitoring the enterprise-interior routing 546 protocol. 548 DHCP generation of RLOCs may require support from relays within the 549 enterprise. For DHCPv6, relays that do not already know the RLOC of 550 a server within the enterprise forward requests to the 551 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For 552 DHCPv4, relays that do not already know the RLOC of a server within 553 the enterprise forward requests to the site-scoped IPv4 multicast 554 group address 'All_DHCPv4_Servers', which should be set to 555 239.255.2.1 unless an alternate multicast group for the site is 556 known. DHCPv4 servers that delegate RLOCs should therefore join the 557 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 558 received for that group. 560 A combined approach using both DHCP and self-generation is also 561 possible when the ER configures both a DHCP client and relay that are 562 connected, e.g., via a pair of back-to-back connected Ethernet 563 interfaces, a tun/tap interface, a loopback interface, inter-process 564 communication, etc. The ER first self-generates a temporary RLOC 565 used only for the purpose of procuring an actual RLOC taken from a 566 disjoint addressing range. The ER then engages in the enterprise- 567 interior routing protocol and performs a DHCP client/relay exchange 568 using the temporary RLOC as the address of the relay. When the DHCP 569 server delegates an actual RLOC address/prefix, the ER abandons the 570 temporary RLOC and re-engages in the enterprise-interior routing 571 protocol using an RLOC taken from the delegation. 573 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 574 enterprise-interior interfaces as singleton addresses (i.e., as 575 addresses with /32 prefix lengths for IPv4, or as addresses with /128 576 prefix lengths for IPv6) may be necessary to avoid multi-link subnet 577 issues. In other use cases, assignment of an RLOC on a VET interface 578 as specified in Appendix B can provide link layer multiplexing and 579 traffic engineering over multiple underlying interfaces using only a 580 single IP address. 582 4.2. Enterprise Border Router (EBR) Autoconfiguration 584 EBRs are ERs that configure VET interfaces over distinct sets of 585 underlying interfaces belonging to the same enterprise; an EBR can 586 connect to multiple enterprises, in which case it would configure 587 multiple interfaces. In addition to the ER autoconfiguration 588 procedures specified in Section 4.1, EBRs perform the following 589 autoconfiguration operations. 591 4.2.1. VET Interface Autoconfiguration 593 VET interface autoconfiguration entails: 1) interface initialization, 594 2) EBG discovery, and 3) EID configuration. These functions are 595 specified in the following sections. 597 4.2.1.1. Interface Initialization 599 EBRs configure a VET interface over a set of underlying interfaces 600 belonging to the same enterprise, where the VET interface connects to 601 a VET link area in which all EBRs in the enterprise appear as single- 602 hop neighbors through the use of IP in IP encapsulation. After the 603 EBR configures a VET interface, it initializes the interface and 604 assigns an IPv6 link-local address and an IPv4 link-local address if 605 necessary. The EBR also associates an RLOC obtained as specified in 606 Section 4.1 with the VET interface to serve as the source address for 607 outer IP packets. 609 When IPv6 and IPv4 are used as the inner/outer protocols 610 (respectively), the EBR autoconfigures an IPv6 link-local VET address 611 on the VET interface to support packet forwarding and operation of 612 the IPv6 neighbor discovery protocol. The link-local VET address is 613 formed exactly as specified in Sections 6.1 and 6.2 of [RFC5214]. 614 The link-local address need not be checked for uniqueness since the 615 IPv4 RLOC embedded in the address itself is managed for uniqueness 616 (see Section 4.1). 618 Link-local address configuration for other inner/outer IP protocol 619 combinations is through administrative configuration or through an 620 unspecified alternate method. However, link-local address 621 configuration for other inner/outer IP protocol combinations may not 622 be necessary if a non-link-local address can be configured through 623 other means (e.g., administrative configuration, DHCP, etc.). 625 After the EBR initializes a VET interface, it can communicate with 626 other VET nodes as single-hop neighbors on the VET link from the 627 viewpoint of the inner IP protocol. The EBR can also configure the 628 VET interface for link-layer multiplexing and traffic engineering 629 purposes as specified in Appendix B. 631 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 632 Identification 634 The EBR next discovers a list of EBGs for each of its VET interfaces. 635 The list can be discovered through information conveyed in the 636 enterprise-interior routing protocol, through the Potential Router 637 List (PRL) discovery mechanisms outlined in Section 8.3.2 of 638 [RFC5214], through a DHCP option [I-D.templin-isatap-dhcp], etc. In 639 multicast-capable enterprises, EBRs can also listen for 640 advertisements on the 'rasadv' [RASADV] multicast group address. 642 Whether or not routing information is available, the EBR can discover 643 the list of EBGs by resolving an identifying name for the PRL 644 ('PRLNAME') formed as 'hostname.domainname', where 'hostname' is an 645 enterprise-specific name string and 'domainname' is an enterprise- 646 specific DNS suffix. The EBR discovers 'PRLNAME' through manual 647 configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 648 protocol advertisements, link-layer information (e.g., an IEEE 802.11 649 Service Set Identifier (SSID)), or through some other means specific 650 to the enterprise. In the absence of other information, the EBR sets 651 the 'hostname' component of 'PRLNAME' to "isatapv2" and sets the 652 'domainname' component to the enterprise-specific DNS suffix 653 "example.com" (e.g., as "isatapv2.example.com"). 655 After discovering a list of IP addresses and/or domain names for the 656 PRL, the EBR resolves any domain names into a list of RLOC addresses 657 through a name service lookup. For centrally managed enterprises, 658 the EBR resolves domain names using an enterprise-local name service 659 (e.g., the enterprise-local DNS). For enterprises with a distributed 660 management structure, the EBR resolves domain names using Link-Local 661 Multicast Name Resolution (LLMNR) [RFC4795] over the VET interface. 662 In that case, all EBGs in the PRL respond to the LLMNR query, and the 663 EBR accepts the union of all responses. 665 The global Internet interdomain routing core represents a specific 666 example list of an enterprise network scenario, albeit on an enormous 667 scale. The 'PRLNAME' assigned to the global Internet interdomain 668 routing core for the purpose of VET is "isatapv2.net". After 669 discovering 'PRLNAME', the EBR can discover the list of EBGs by 670 resolving 'PRLNAME' to a list of RLOC addresses through a name 671 service lookup. For centrally managed enterprises, the EBR resolves 672 'PRLNAME' using an enterprise-local name service (e.g., the 673 enterprise-local DNS). For enterprises with a distributed management 674 structure, the EBR resolves 'PRLNAME' using Link-Local Multicast Name 675 Resolution (LLMNR) [RFC4795] over the VET interface. In that case, 676 all EBGs in the PRL respond to the LLMNR query, and the EBR accepts 677 the union of all responses. Each distinct enterprise VET interface 678 must have a unique identity that EBRs can use to uniquely discern 679 their enterprise affiliations. 'PRLNAME' as well as the RLOCs The 680 list of EBGs and the IP prefixes they aggregate serve as an 681 identifier for the enterprise. 683 Each distinct VET interface must have a unique identity that EBRs can 684 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 685 well as the RLOCs of EBGs and the IP prefixes they aggregate serve as 686 an identifier for the interface. 688 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 690 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 691 autoconfiguration exchanges with EBGs over VET interfaces, where each 692 EBG may be configured as either a DHCP relay or DHCP server. 694 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 695 delegation exchange, explicit management, etc. 697 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 698 exchanges. In particular, the EBR (acting as a requesting router) 699 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 700 obtain IPv6 EID prefixes from the server (acting as a delegating 701 router). 703 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 704 exchange [RFC3315]. For example, to perform the 2-message exchange, 705 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 706 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 707 relay (see Section 4.1). The relay then forwards the message over 708 the VET interface to an EBG, which either services the request or 709 relays it further. The forwarded Solicit message will elicit a reply 710 from the server containing PA IPv6 prefix delegations. 712 The EBR can also propose a specific prefix to the DHCPv6 server per 713 Section 7 of [RFC3633]. The server will check the proposed prefix 714 for consistency and uniqueness, then return it in the reply to the 715 EBR if it was able to perform the delegation. 717 After the EBR receives PA prefix delegations, it can provision the 718 prefixes on enterprise-edge interfaces as well as on other VET 719 interfaces for which it is configured as an EBG. It can also 720 provision the prefixes on enterprise-interior interfaces so that non- 721 mobile hosts on those interfaces can use them for EID address 722 autoconfiguration. 724 The PA prefix delegations remain active as long as the EBR continues 725 to issue DHCP renewals over the VET interface before lease lifetimes 726 expire. The lease lifetime also keeps the delegation state active 727 even if communications between the EBR and DHCP server are disrupted 728 for a period of time (e.g., due to an enterprise network partition, 729 power failure, etc.). 731 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 733 Independent of any PA prefixes, EBRs can acquire and use Provider- 734 Independent (PI) EID prefixes that are self-configured (e.g., using 735 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 736 through a regional Internet registry, through a different provider, 737 through a centrally-assigned unique local address delegation 738 authority [I-D.hain-ipv6-ulac], etc.). When an EBR acquires a PI 739 prefix, it must also obtain credentials that it can use to prove 740 ownership when it registers the prefixes (see Section 5.4 and 741 Section 5.4.5). 743 After the EBR receives PI prefix delegations, it can provision the 744 prefixes on enterprise-edge interfaces as well as on other VET 745 interfaces for which it is configured as an EBG. It can also 746 provision the prefixes on enterprise-interior interfaces as long as 747 other nodes on those interfaces can unambiguously associate the 748 prefixes with the EBR. 750 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 752 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 754 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 756 EBGs are EBRs that connect child enterprises to provider networks via 757 provider-edge interfaces and/or via VET interfaces configured over 758 parent enterprises. EBGs autoconfigure their provider-edge 759 interfaces in a manner that is specific to the provider connections, 760 and they autoconfigure their VET interfaces that were configured over 761 parent enterprises using the EBR autoconfiguration procedures 762 specified in Section 4.2. 764 For each of its VET interfaces configured over a child enterprise, 765 the EBG initializes the interface the same as for an ordinary EBR 766 (see Section 4.2.1). It must then arrange to add one or more of its 767 RLOCs associated with the child enterprise to the PRL as specified in 768 [RFC5214], Section 9. In particular, for each VET interface 769 configured over a child enterprise, the EBG adds the RLOCs to name 770 service resource records for 'PRLNAME' ("isatapv2.example.com, by 771 default). 773 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 774 configured over child enterprises with a distributed management 775 structure. 777 EBGs configure a DHCP relay/server on VET interfaces configured over 778 child enterprises that require DHCP services. 780 To avoid looping, EBGs must not configure a default route on a VET 781 interface configured over a child interface. 783 4.4. VET Host Autoconfiguration 785 Nodes that cannot be attached via an EBR's enterprise-edge interface 786 (e.g., nomadic laptops that connect to a home office via a Virtual 787 Private Network (VPN)) can instead be configured for operation as a 788 simple host connected to the VET interface. Such VET hosts perform 789 the same VET interface initialization and border gateway discovery 790 procedures as specified for EBRs in Section 4.2.1, but they configure 791 their VET interfaces as host interfaces (and not router interfaces). 792 Note also that a node may be configured as a host on some VET 793 interfaces and as an EBR/EBG on other VET interfaces. 795 VET hosts perform address autoconfiguration on VET interfaces 796 according to [RFC4862]. When a VET host generates a VET address, it 797 first creates an interface identifier that embeds its IPv4 RLOC 798 address as specified in Section 6.1 of [RFC5214]. The host then 799 configures IPv6 unicast VET addresses from advertised on-link 800 prefixes received in RA messages and assigns them to the VET 801 interface, i.e., it does not perform Duplicate Address Detection 802 (DAD) on the addresses since the embedded IPv4 RLOC address already 803 provides uniqueness. 805 5. Internetworking Operation 807 Following the autoconfiguration procedures specified in Section 4, 808 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 809 operations as discussed in the following sections. 811 5.1. Prefix Registration 813 Following autoconfiguration, EBRs must register their PI/PA prefixes 814 with provider networks by sending RAs to each EBG listed in 'PRLNAME' 815 with Route Information Options that contain the EBR's prefixes (see: 816 Section 5.4.1). For enterprises that use SEND, the RAs also include 817 a CGA link-local inner source address, SEND credentials, plus any 818 certificates needed to prove ownership of the prefixes. Each RA must 819 include the RLOC of an EBG as the outer IP destination address and a 820 link-local address formed from the RLOC as the inner IP destination 821 address. Each such EBG in turn relays the RAs to EBGs on their 822 parent enterprises. After the initial prefix registration, the EBR 823 must periodically send additional RAs to its set of EBGs to refresh 824 prefix lifetimes (an RA interval of 120 seconds is recommended). 825 This procedure has a direct analogy in the Teredo method of 826 maintaining state in network middleboxes through the periodic 827 transmission of "bubbles" [RFC4380]. 829 When an EBG receives the RA, it first authenticates the message; if 830 the authentication fails, the EBG discards the RA. Otherwise, the 831 EBG installs the prefixes with their respective lifetimes in its 832 Forwarding Information Base (FIB) and configures them for both 833 ingress filtering [RFC3704] and forwarding purposes. In particular, 834 the EBG configures the FIB entries as ingress filter rules to accept 835 packets received on the VET interface that have a source address 836 taken from the prefixes. It also configures the FIB entries to 837 permit forwarding of packets with a destination address taken from 838 the prefixes to the EBR that registered the prefixes on the VET 839 interface. 841 After the EBG authenticates the RA and updates its FIB, it next acts 842 as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the VET 843 interfaces configured over any of its parent enterprises, and relays 844 a proxied RA to the EBGs on those interfaces. (For enterprises that 845 use SEND, the EBG additionally acts as a SEcure Neighbor Discovery 846 Proxy (SENDProxy) ][I-D.ietf-csi-proxy-send].) EBGs in parent 847 enterprises that receive the proxied RAs in turn act as NDProxys/ 848 SENDProxys to relay the RAs to EBGs on their parent enterprises, etc. 849 The RA proxying recurses in this fashion and ends when an EBR 850 attached to an interdomain routing core is reached. 852 5.2. Routing Protocol Participation 854 Following prefix registration, ERs engage in any enterpise-interior 855 routing protocols and forward IP packets with RLOC addresses. EBRs 856 can additionally engage in any overlay network routing protocols and 857 forward IP packets with EID addresses. Note that the EID-based 858 overlay network IP routing domains are separate and distinct from any 859 RLOC-based enterprise-interior IP routing domains. 861 EBRs use the list of EBGs on the VET interface (see: Section 4.2.1.2) 862 as an initial list of neighbors for overlay network routing protocol 863 participation. Routing protocol participation on non-multicast VET 864 interfaces uses the NBMA model, e.g., in the same manner as for OSPF 865 over NBMA interfaces [RFC5340]. 867 5.3. Address Selection 869 When permitted by policy and supported by enterprise-interior 870 routing, end systems should avoid VET interface encapsulation through 871 communications that directly invoke the outer IP protocol using RLOC 872 addresses instead of EID addresses. For example, an enterprise that 873 provides native IPv4 internal network services can provide continued 874 support for native IPv4 communications even when encapsulated IPv6 875 services are available on the overlay network. In other enterprise 876 scenarios, the use of EID-based communications (i.e., instead of 877 RLOC-based communications) may be necessary and/or beneficial to 878 support address scaling, NAT avoidance, security domain separation, 879 site multihoming, traffic engineering, etc. . 881 End systems can use source address selection rules to determine 882 whether to use EID-based encapsulated or RLOC-based native addressing 883 based on, e.g., name service information. The remainder of this 884 section discusses internetworking operation for EID-based 885 communications using the VET interface abstraction. 887 5.4. Neighbor Discovery 889 The following sections discuss IPv6 Neighbor Discovery (ND) 890 considerations for the case of IPv6 as the inner IP protocol and IPv4 891 as the outer protocol (ND considerations for other IP protocol 892 combinations are out of scope). Depending on the enterprise network 893 trust basis, VET nodes may be required to use mechanisms such as SEND 894 to secure their ND exchanges. 896 5.4.1. Router and Prefix Discovery 898 5.4.1.1. EBR Specification 900 EBRs discover the addresses of EBGs for each VET interface as 901 specified in Section 4.2.1.2, and participate in a dynamic routing 902 protocol over the VET interface. When a dynamic routing protocol 903 cannot be used (or, when an out-of-band routing exchange is required) 904 EBRs send RA messages with a "Solicit (S)" bit set to inform EBGs of 905 their PI/PA prefixes and to receive RA messages from the EBGs in 906 reply. Each RA message has the same format as specified in Section 907 4.2 of [RFC4861], but with a new 'S' bit in the RA flags field as 908 follows: 910 +-+-+-+-+-+-+-+-+ 911 |M|O|H|Prf|P|S|R| 912 +-+-+-+-+-+-+-+-+ 914 Figure 2: Router Advertisement Flags Field 916 When an EBR sends an RA with the 'S' bit set, it includes Route 917 Information Options (RIOs) [RFC4191] that contain any of its PI/PA 918 prefixes, but it MUST NOT include any other autoconfiguration 919 parameters (e.g., non-zero Router Lifetime, Prefix Information 920 Options (PIOs), etc.) The EBR also unconditionally sets the 'M' bit 921 to 0 and the 'O' bit to 1. Next, the EBR includes Source Link-Layer 922 Address Options (SLLAOs) formatted using a modified version of the 923 form specified in Section 5 of [RFC2529] as shown in Figure 3: 925 +-------+-------+-------+-------+-------+-------+-------+-------+ 926 | Type |Length | Reserved | IPv4 Address | 927 +-------+-------+-------+-------+-------+-------+-------+-------+ 929 Figure 3: VET Link-Layer Address Option Format 931 Each SLLAO encodes the IPv4 RLOC address of one of its enterprise- 932 interior interfaces; the EBR MAY include multiple SLLAO's (e.g., to 933 support fault tolerance should an enterprise-interior interface 934 fail). When the EBR includes multiple SLLAOs, it arranges them in 935 increasing order of priority, i.e., the first SLLAO includes the 936 lowest priority RLOC and the final SLLAO includes the highest 937 priority RLOC. 939 For enterprises that use SEND, the EBR also includes a CGA link-local 940 inner source address, SEND credentials, plus any certificates needed 941 to prove ownership of the prefixes in Route Information Options 942 (RIOs). The EBR additionally tracks the set of EBGs to which it 943 sends RAs so that it can send subsequent RAs to the same set. Note 944 that the CGA link-local address is used only as the inner source 945 address of ND messages using SEND, and therefore need not be checked 946 for uniqueness on the link. 948 When an EBR receives a solicited RA from an EBG (see Section 949 5.3.1.2), it authenticates the message then processes any 950 autoconfiguration information. However, the EBR MUST NOT assign 951 prefixes from any of the EBG's advertised PIOs to the link, since 952 legacy VET hosts may have no way of knowing whether an EBR is 953 authorized to source packets from a particular prefix range. This 954 implies that the EBR considers any prefixes in PIOs as associated 955 with the VET interface but not on-link on the VET interface; 956 therefore, communications involving a VET host and an EBR will be 957 forwarded via an EBG until a redirection event occurs. 959 Similarly, when an EBR receives a solicited NA from a VET host (see 960 Section 5.3.1.3), it authenticates the message then creates an entry 961 for the host in its neighbor cache. Thereafter, the EBR uses 962 ordinary Neighbor Unreachability Detection (NUD) to confirm VET host 963 reachability. 965 5.4.1.2. EBG Specification 967 EBGs follow the router and prefix discovery procedures specified in 968 Section 8.2 of [RFC5214], except that they send solicited RAs in 969 response to both ordinary RS messages and RA messages with the 'S' 970 bit set (see: Section 5.4.1.1). This behavior extends the Router 971 Advertisement Consistency specification in Section 6.2.7 of [RFC4861] 972 by requiring EBGs to process received RA messages with the 'S' bit 973 set and send an RA of their own in reply. 975 When the EBG receives an RS or RA with the 'S' bit set, it first 976 authenticates the message. If the VET interface maintains a neighbor 977 cache, the EBG next creates or updates a neighbor cache entry for the 978 VET link-local source address corresponding to the solicitation 979 according to Section 6.2.6 of [RFC4861]. If the neighbor cache entry 980 cannot be created or updated (e.g., due to insufficient resources), 981 the EBG silently discards the solicitation and does not send an RA. 982 Otherwise, the EBG creates/updates the neighbor cache entry, sets a 983 "Time To Live (TTL)" on the entry that is no shorter than any of its 984 advertised router or prefix lifetimes, and sends an RA response to 985 the solicitation. If the neighbor cache entry TTL subsequently 986 expires before a new solicitation arrives, the EBG deletes the 987 neighbor cache entry. Note that if the VET interface does not 988 maintain a neighbor cache, the EBG simply omits these neighbor cache 989 manipulations and sends the RA response to the solicitation. 991 After creating or updating the neighbor cache entry, if the 992 solicitation was an RA message with the 'S' bit set the EBG processes 993 any RIOs but ignores all other information in the message. The EBG 994 then advertises the RIO prefixes to any of its provider networks, 995 whether as a specific prefix or as a portion of an aggregated prefix. 997 Whether the solicitation was an RS or an RA, the EBG next prepares an 998 RA that includes Router Lifetimes, PIOs, and any other options/ 999 parameters that the EBG is configured to include. The EBG also 1000 unconditionally sets the 'M' bit to 0, the 'O' bit to 1 and the 'S' 1001 bit to 0. Next, the EBG includes SLLAOs and SEND parameters the same 1002 as specified for EBRs in Section 5.4.1.1. Finally, the EBG sends the 1003 solicited RA to the VET node that sent the solicitation. 1005 5.4.1.3. VET Host Specification 1007 VET hosts follow the router and prefix discovery procedures specified 1008 in [RFC5214], Section 8.3. They discover the addresses of EBGs for 1009 each VET interface as specified in Section 4.2.1.2, and send an RS 1010 message to each EBG in order to receive RAs with autoconfiguration 1011 information. 1013 When the VET host receives a solicited RA from an EBG, it 1014 authenticates the message then performs autoconfiguration the same as 1015 for any link (see also: Section 4.4). When the VET host receives an 1016 unsolicited RA from an EBR (i.e., an RA with the 'S' bit set), it 1017 authenticates the message then processes any RIOs and sends a 1018 Neighbor Advertisement (NA) message back to the EBR. 1020 5.4.2. Next Hop Determination 1022 VET nodes perform next-hop determination via longest prefix match the 1023 same as for any IPv6 interface and sends packets according to the 1024 most-specific matching entry in the FIB, i.e., even if the most 1025 specific FIB entry is "default". When there is no matching entry in 1026 the FIB (i.e., not even "default"), VET nodes can discover next-hop 1027 EBRs within the enterprise by querying the name service for the /56 1028 IPv6 PI prefix taken from a packet's destination address (or, by some 1029 other inner-IP to outer-IP address mapping mechanism). For example, 1030 for the IPv6 destination address '2001:DB8:1:2::1' and 'PRLNAME' 1031 "isatapv2.example.com" the VET node can lookup the domain name: 1032 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 1034 Name-service lookups in enterprises with a centralized management 1035 structure use an infrastructure-based service, e.g., an enterprise- 1036 local DNS. Name-service lookups in enterprises with a distributed 1037 management structure and/or that lack an infrastructure-based name 1038 service instead use LLMNR over the VET interface. When LLMNR is 1039 used, the EBR that performs the lookup sends an LLMNR query (with the 1040 /56 prefix taken from the IP destination address encoded in dotted- 1041 nibble format as shown above) and accepts the union of all replies it 1042 receives from other EBRs on the VET interface. When an EBR receives 1043 an LLMNR query, it responds to the query IFF it aggregates an IP 1044 prefix that covers the prefix in the query. 1046 If the name-service lookup succeeds, it will return RLOC addresses 1047 (e.g., in DNS A records) that correspond to next-hop EBRs to which 1048 the VET node can forward packets. 1050 5.4.3. Redirect Function 1052 In enterprises with a stable and highly-available set of EBGs, the 1053 VET node can simply forward initial packets via a default route to an 1054 EBG. The EBG will forward the packet and return an ICMPv6 Redirect 1055 as specified in Section 8 of [RFC4861] if the next-hop corresponds to 1056 a VET node on the same interface. 1058 If the source address of the packet causing the redirect is on-link 1059 on the VET interface, the EBG returns an ordinary "router-to-host" 1060 redirect with the source address of the packet as its destination. 1061 When a VET host receives the redirect, it processes the redirect 1062 exactly as specified in Section 8 of [RFC4861]. 1064 If the source address of the packet causing the redirect is not on- 1065 link, the EBG instead returns a "router-to-router" redirect with the 1066 link-local VET address of the previous-hop EBR as its destination, 1067 with the link-local address of a next-hop EBR as the redirected 1068 target, and with the destination address of the original packet as 1069 the redirected destination. The EBG includes in the redirect one or 1070 more IPv6 TLLAOs formatted as specified in Section 5.3.1.1. Each 1071 TLLAO contains the IPv4 RLOC of a potential next-hop EBR interfaces 1072 arranged in order from lowest to highest priority (i.e., the first 1073 TLLAO contains the lowest priority RLOC and the final TLLAO option 1074 contains the highest priority). Finally, the EBG includes the header 1075 of the redirected packet. 1077 When an EBR receives a "router-to-router" redirect, it discovers the 1078 RLOC addresses of potential next-hop EBRs by examining the TLLAOs 1079 included in the redirect. The EBR then prepares an RA with the 'S' 1080 bit set as specified in Section 5.3.1.1, and includes an RIO that 1081 contains a /56 prefix taken from the original packet's source 1082 address. The EBR then sends the RA to the VET link-local address of 1083 a next-hop EBR interface formed from an IPv4 RLOC embedded in one of 1084 the redirect's TLLAOs. 1086 When a next-hop EBR receives the RA, it authenticates the message 1087 (e.g., using SEND credentials). The EBR then installs any prefixes 1088 in RIOs in its FIB and marks them for use as ingress filtering only 1089 (i.e., and not for forwarding). The EBR then sends a NULL RA message 1090 reply back to the previous-hop EBR with the 'S' bit set to 0. When 1091 the previous-hop EBR receives the RA reply, it installs the /56 1092 prefix corresponding to the packet's destination address in its FIB 1093 and marks it for use as forwarding only (i.e., and not for ingress 1094 filtering). 1096 EBRs retain the FIB entries created as a result of an ICMP redirect 1097 until the route lifetimes expire, or until no hints of forward 1098 progress through any of the associated RLOCs are received. In this 1099 way, RLOC liveness detection exactly parallels IPv6 Neighbor 1100 Unreachability Detection ([RFC4861], Section 3). 1102 5.4.4. Reverse Path Forwarding Checks 1104 VET nodes determine whether a packet received on a VET interface can 1105 be accepted based on an ingress filtering check. The VET node 1106 determines the previous hop router for a received packet by 1107 constructing a VET link-local address that embeds the outer IPv4 1108 source address. It then examines its FIB to determine whether there 1109 is an entry that matches the inner IPv6 source address and has the 1110 VET link-local address as the next hop. If such a FIB entry exists, 1111 the VET host accepts the packet; otherwise, it discards the packet. 1113 5.4.5. IPv4 Neighbor Discovery 1115 When IPv4 is used as the inner IP protocol, router discovery and 1116 prefix registration exactly parallel the mechanisms specified for 1117 IPv6 in Section 5.4. To support this, modifications to the ICMPv4 1118 Router Advertisement [RFC1256] function to include SEND constructs 1119 and modifications to the ICMPv4 Redirect [RFC0792] function to 1120 support router-to-router redirects will be specified in a future 1121 document. Additionally, publications for IPv4 prefixes will be in 1122 dotted-nibble format in the 'ip4.isatapv2.example.com' domain. For 1123 example, the IPv4 prefix 192.0.2/24 would be represented as: 1124 '2.0.0.0.0.c.ip4.isatapv2.example.com' 1126 5.5. Generating Errors 1128 When an EBR receives an IPv6 packet over a VET interface and there is 1129 no matching ingress filter entry, it drops the packet and returns an 1130 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 1131 ingress/egress policy" message to the previous-hop EBR subject to 1132 rate limiting. 1134 When an EBR receives an IPv6 packet over a VET interface, and there 1135 is no longest-prefix-match FIB entry for the destination, it returns 1136 an ICMPv6 "Destination Unreachable; No route to destination" message 1137 to the previous hop EBR subject to rate limiting. 1139 When an EBR receives an IPv6 packet over a VET interface and the 1140 longest-prefix-match FIB entry for the destination is via a next-hop 1141 configured over the same VET interface the packet arrived on, the EBR 1142 forwards the packet. If the FIB prefix is longer than ::/0, the EBR 1143 then sends a router-to-router ICMPv6 Redirect message (using SEND, if 1144 necessary) to the previous-hop EBR as specified in Section 5.4.3. 1146 Generation of other ICMP messages [RFC0792] [RFC4443] is the same as 1147 for any IP interface. 1149 5.6. Processing Errors 1151 When a VET node receives an ICMPv6 "Destination Unreachable; Source 1152 address failed ingress/egress policy" message, and there is a 1153 longest-prefix-match FIB entry for the original packet's destination 1154 that is more specific than ::/0, the node discards the message and 1155 marks the FIB entry for the destination as "forwarding suspended" for 1156 the RLOC taken from the source address of the ICMPv6 message. The 1157 node should then allow subsequent packets to flow through different 1158 RLOCs associated with the FIB entry. If the node receives excessive 1159 ICMPv6 ingress/egress policy errors through multiple RLOCs associated 1160 with the same FIB entry, it should delete the FIB entry and allow 1161 subsequent packets to flow through an EBG if supported in the 1162 specific enterprise scenario. 1164 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1165 to destination" message, it forwards the ICMPv6 message to the source 1166 of the original packet as normal. If the node has a longest-prefix- 1167 match FIB entry for the original packet's destination that is more 1168 specific than ::/0, the node also deletes the FIB entry. 1170 When a VET node receives an authentic ICMPv6 Redirect, it processes 1171 the packet as specified in Section 5.4.3. 1173 Additionally, a VET node may receive ICMP "Destination Unreachable; 1174 net / host unreachable" messages from an ER on the path indicating 1175 that the path to a VET neighbor may be failing. The node should 1176 first check authenticating information (e.g., the SEAL_ID, IPsec 1177 sequence number, source address of the original packet if available, 1178 etc.) to obtain reasonable assurance that the ICMP message is 1179 authentic, then should mark the longest-prefix-match FIB entry for 1180 the destination as "forwarding suspended" for the RLOC destination 1181 address of the ICMP packet-in-error. If the node receives excessive 1182 ICMP unreachable errors through multiple RLOCs associated with the 1183 same FIB entry, it should delete the FIB entry and allow subsequent 1184 packets to flow through a different route. 1186 5.7. Mobility and Multihoming Considerations 1188 EBRs that travel between distinct enterprise networks must either 1189 abandon their PA prefixes that are relative to the "old" enterprise 1190 and obtain new ones relative to the "new" enterprise or somehow 1191 coordinate with a "home" enterprise to retain ownership of the 1192 prefixes. In the first instance, the EBR would be required to 1193 coordinate a network renumbering event using the new PA prefixes 1194 [RFC4192]. In the second instance, an ancillary mobility management 1195 mechanism must be used. 1197 EBRs can retain their PI prefixes as they travel between distinct 1198 enterprise networks as long as they register the prefixes with new 1199 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1200 departure. Prefix registration with new EBGs is coordinated exactly 1201 as specified in Section 4.2.4; prefix withdrawal from old EBGs is 1202 simply through re-announcing the PI prefixes with zero lifetimes. 1204 Since EBRs can move about independently of one another, stale FIB 1205 entry state may be left in VET nodes when a neighboring EBR departs. 1206 Additionally, EBRs can lose state for various reasons, e.g., power 1207 failure, machine reboot, etc. For this reason, EBRs are advised to 1208 set relatively short PI prefix lifetimes in RIO options, and to send 1209 additional RAs to refresh lifetimes before they expire. (EBRs should 1210 place conservative limits on the RAs they send to reduce congestion, 1211 however.) 1213 EBRs may register their PI prefixes with multiple EBGs for 1214 multihoming purposes. EBRs should only forward packets via EBGs with 1215 which it has registered its PI prefixes, since other EBGs may drop 1216 the packets and return ICMPv6 "Destination Unreachable; Source 1217 address failed ingress/egress policy" messages. 1219 EBRs can also act as delegating routers to sub-delegate portions of 1220 their PI prefixes to requesting routers on their enterprise-edge 1221 interfaces and on VET interfaces for which they are configured as 1222 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1223 become the PA prefixes for downstream-dependent nodes. 1225 The EBGs of a multihomed enterprise should participate in a private 1226 inner IP routing protocol instance between themselves (possibly over 1227 an alternate topology) to accommodate enterprise partitions/merges as 1228 well as intra-enterprise mobility events. These peer EBGs should 1229 accept packets from one another without respect to the destination 1230 (i.e., ingress filtering is based on the peering relationship rather 1231 than a prefix-specific ingress filter entry). 1233 5.8. Multicast 1235 In multicast-capable deployments, ERs provide an enterprise-wide 1236 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1237 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1238 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1239 over their enterprise-interior interfaces such that outer IP 1240 multicast messages of site-scope or greater scope will be propagated 1241 across the enterprise. For such deployments, VET nodes can also 1242 provide an inner IP multicast/broadcast capability over their VET 1243 interfaces through mapping of the inner IP multicast address space to 1244 the outer IP multicast address space. In that case, operation of 1245 link-scoped (or greater scoped) inner IP multicasting services (e.g., 1246 a link-scoped neighbor discovery protocol) over the VET interface is 1247 available, but link-scoped services should be used sparingly to 1248 minimize enterprise-wide flooding. 1250 VET nodes encapsulate inner IP multicast messages sent over the VET 1251 interface in any mid-layer headers (e.g., SEAL, IPsec, etc.) followed 1252 by an outer IP header with a site-scoped outer IP multicast address 1253 as the destination. For the case of IPv6 and IPv4 as the inner/outer 1254 protocols (respectively), [RFC2529] provides mappings from the IPv6 1255 multicast address space to a site-scoped IPv4 multicast address space 1256 (for other encapsulations, mappings are established through 1257 administrative configuration or through an unspecified alternate 1258 static mapping). 1260 Multicast mapping for inner IP multicast groups over outer IP 1261 multicast groups can be accommodated, e.g., through VET interface 1262 snooping of inner multicast group membership and routing protocol 1263 control messages. To support inner-to-outer IP multicast mapping, 1264 the VET interface acts as a virtual outer IP multicast host connected 1265 to its underlying interfaces. When the VET interface detects that an 1266 inner IP multicast group joins or leaves, it forwards corresponding 1267 outer IP multicast group membership reports on an underlying 1268 interface over which the VET interface is configured. If the VET 1269 node is configured as an outer IP multicast router on the underlying 1270 interfaces, the VET interface forwards locally looped-back group 1271 membership reports to the outer IP multicast routing process. If the 1272 VET node is configured as a simple outer IP multicast host, the VET 1273 interface instead forwards actual group membership reports (e.g., 1274 IGMP messages) directly over an underlying interface. 1276 Since inner IP multicast groups are mapped to site-scoped outer IP 1277 multicast groups, the VET node must ensure that the site-scope outer 1278 IP multicast messages received on the underlying interfaces for one 1279 VET interface do not "leak out" to the underlying interfaces of 1280 another VET interface. This is accommodated through normal site- 1281 scoped outer IP multicast group filtering at enterprise boundaries. 1283 5.9. Service Discovery 1285 VET nodes can perform enterprise-wide service discovery using a 1286 suitable name-to-address resolution service. Examples of flooding- 1287 based services include the use of LLMNR [RFC4795] over the VET 1288 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1289 over an underlying interface. More scalable and efficient service 1290 discovery mechanisms are for further study. 1292 5.10. Enterprise Partitioning 1294 EBGs can physically partition an enterprise by configuring multiple 1295 VET interfaces over multiple distinct sets of underlying interfaces. 1296 In that case, each partition (i.e., each VET interface) must 1297 configure its own distinct 'PRLNAME' (e.g., 1298 'isatapv2.zone1.example.com', 'isatapv2.zone2.example.com', etc.). 1300 EBGs can logically partition an enterprise using a single VET 1301 interface by sending RAs with PIOs containing different IPv6 PA 1302 prefixes to group nodes into different logical partitions. EBGs can 1303 identify partitions, e.g., by examining RLOC prefixes, observing the 1304 interfaces over which RSs are received, etc. In that case, a single 1305 'PRLNAME' can cover all partitions. 1307 5.11. EBG Prefix State Recovery 1309 EBGs must retain explicit state that tracks the inner IP prefixes 1310 owned by EBRs within the enterprise, e.g., so that packets are 1311 delivered to the correct EBRs and not incorrectly "leaked out" of the 1312 enterprise via a default route. When an EBG loses some or all of its 1313 state (e.g., due to a power failure), it must recover the state so 1314 that packets can be forwarded over correct routes. 1316 5.12. Support for Legacy ISATAP Services 1318 EBGs support legacy ISATAP services according to the specifications 1319 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1320 interfaces and VET interfaces over the same sets of underlying 1321 interface as long as the PRL names and IPv6 prefixes associated with 1322 the ISATAP/VET interfaces are distinct. 1324 5.13. SEAL Encapsulation 1326 After address resolution, the VET interface encapsulates the inner IP 1327 packet in any mid-layer headers (e.g., IPsec [RFC4301]) followed a 1328 SEAL header [I-D.templin-intarea-seal] followed by an outer IP 1329 header; it next submits the encapsulated packet to the outer IP 1330 forwarding engine for transmission on an underlying interface. 1332 VET interfaces use SEAL encapsulation to accommodate path MTU 1333 diversity, to defeat source address spoofing, and to enable sub-IP 1334 layer hints of forward progress that can be piggybacked on ordinary 1335 data messages. SEAL encapsulation maintains a unidirectional and 1336 monotonically incrementing per-packet identification value known as 1337 the 'SEAL_ID'. When a VET node that uses SEAL encapsulation receives 1338 an authentic neighbor discovery message from another VET node, it can 1339 cache the new SEAL_ID as per-tunnel state used for maintaining a 1340 window of unacknowledged SEAL_IDs. 1342 In terms of security, when a VET node receives an ICMP message or a 1343 SEAL error message, it can confirm that the packet-in-error within 1344 the message corresponds to one of its recently sent packets by 1345 examining the SEAL_ID along with source and destination addresses, 1346 etc. Additionally, a next-hop EBR can track the SEAL_ID in packets 1347 received from EBRs for which there is an ingress filter entry and 1348 discard packets that have SEAL_ID values outside of the current 1349 window. (Note that for IPv6 in IPv4 encapsulation packets with a 1350 link-local IPv6 destination address are excluded from this check to 1351 support operation of the neighbor discovery protocol.) 1353 In terms of next-hop reachability, an EBR can set the SEAL 1354 "Acknowledgement Requested" bit in messages to receive confirmation 1355 that a next-hop EBR is reachable. (Note that this is a mid-layer 1356 reachability confirmation, and not an L2 reachability indication.) 1357 Setting the "Acknowledgement Requested" bit is also used as the 1358 method for maintaining the window of outstanding SEAL_IDs. 1360 6. IANA Considerations 1362 There are no IANA considerations for this document. 1364 7. Security Considerations 1366 Security considerations for MANETs are found in [RFC2501]. 1368 The security considerations found in [RFC2529] [RFC5214] 1369 [I-D.nakibly-v6ops-tunnel-loops] also apply to VET. In particular: 1371 o VET nodes must ensure that a VET interface does not span multiple 1372 sites as specified in Section 6.2 of [RFC5214]. 1374 o VET nodes must verify that the outer IP source address of a packet 1375 received on a VET interface is correct for the inner IP source 1376 address; for the case of IPv6 in IPv4 encapsulation, this is 1377 accommodated using the procedures specified in Section 7.3 of 1378 [RFC5214]. 1380 o EBRs must implement both inner and outer IP ingress filtering in a 1381 manner that is consistent with [RFC2827] as well as ip-proto-41 1382 filtering. When the node at the physical boundary of the 1383 enterprise is an ordinary ER (i.e., and not an EBR), the ER itself 1384 should implement filtering. 1386 Additionally, VET interfaces that use IPv6 in IPv4 encapsulation and 1387 that maintain a coherent neighbor cache drop all outbound packet for 1388 which the IPv6 next hop is not a neighbor and the IPv6 source address 1389 is not link-local; they also drop all incoming packets for which the 1390 IPv6 previous hop is not a neighbor and the IPv6 destination address 1391 is not link-local. (Here, the previous hop is determined by 1392 examining the IPv4 source address.) 1394 Finally, VET interfaces that use IPv6 in IPv4 encapsulation drop all 1395 outbound packets for which the IPv6 source address is "foreign- 1396 prefix::0200:5efe:V4ADDR" and drop all incoming packets for which the 1397 IPv6 destination address is "foreign-prefix::0200:5efe:V4ADDR" . 1398 (Here, "foreign-prefix" is an IPv6 prefix that is not assigned to the 1399 VET interface, and "V4ADDR" is a public IPv4 address over which the 1400 VET interface is configured.) Note that these checks are only 1401 required for VET interfaces that cannot maintain a coherent neighbor 1402 cache. 1404 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1405 where attacks on the neighbor discovery protocol are possible. SEAL 1406 [I-D.templin-intarea-seal] provides a per-packet identification that 1407 can be used to detect source address spoofing. 1409 Rogue neighbor discovery messages with spoofed RLOC source addresses 1410 can consume network resources and cause VET nodes to perform extra 1411 work. Nonetheless, VET nodes should not "blacklist" such RLOCs, as 1412 that may result in a denial of service to the RLOCs' legitimate 1413 owners. 1415 8. Related Work 1417 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1418 automatic tunneling in [RFC2529]; this concept was later called: 1419 "Virtual Ethernet" and investigated by Quang Nguyen under the 1420 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1421 their colleagues have motivated a number of foundational concepts on 1422 which this work is based. 1424 Telcordia has proposed DHCP-related solutions for MANETs through the 1425 CECOM MOSAIC program. 1427 The Naval Research Lab (NRL) Information Technology Division uses 1428 DHCP in their MANET research testbeds. 1430 Security concerns pertaining to tunneling mechanisms are discussed in 1431 [I-D.ietf-v6ops-tunnel-security-concerns]. 1433 Default router and prefix information options for DHCPv6 are 1434 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1436 An automated IPv4 prefix delegation mechanism is proposed in 1437 [I-D.ietf-dhc-subnet-alloc]. 1439 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1440 [I-D.clausen-manet-autoconf-recommendations]. 1442 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1444 Various proposals within the IETF have suggested similar mechanisms. 1446 9. Acknowledgements 1448 The following individuals gave direct and/or indirect input that was 1449 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1450 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1451 Chris Dearlove, Ralph Droms, Dino Farinacci, Vince Fuller, Thomas 1452 Goff, Joel Halpern, Bob Hinden, Sascha Hlusiak, Sapumal Jayatissa, 1453 Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, Gabi 1454 Nakibly, Thomas Narten, Pekka Nikander, Dave Oran, Alexandru 1455 Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole Troan, 1456 Michaela Vanderveen, Lixia Zhang, and others in the IETF AUTOCONF and 1457 MANET working groups. Many others have provided guidance over the 1458 course of many years. 1460 10. Contributors 1462 The following individuals have contributed to this document: 1464 Eric Fleischman (eric.fleischman@boeing.com) 1465 Thomas Henderson (thomas.r.henderson@boeing.com) 1466 Steven Russert (steven.w.russert@boeing.com) 1467 Seung Yi (seung.yi@boeing.com) 1469 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1470 of the document. 1472 Jim Bound's foundational work on enterprise networks provided 1473 significant guidance for this effort. We mourn his loss and honor 1474 his contributions. 1476 11. References 1478 11.1. Normative References 1480 [I-D.templin-intarea-seal] 1481 Templin, F., "The Subnetwork Encapsulation and Adaptation 1482 Layer (SEAL)", draft-templin-intarea-seal-07 (work in 1483 progress), October 2009. 1485 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1486 September 1981. 1488 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1489 RFC 792, September 1981. 1491 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1492 converting network protocol addresses to 48.bit Ethernet 1493 address for transmission on Ethernet hardware", STD 37, 1494 RFC 826, November 1982. 1496 [RFC1035] Mockapetris, P., "Domain names - implementation and 1497 specification", STD 13, RFC 1035, November 1987. 1499 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1500 RFC 2131, March 1997. 1502 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1503 (IPv6) Specification", RFC 2460, December 1998. 1505 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1506 Defeating Denial of Service Attacks which employ IP Source 1507 Address Spoofing", BCP 38, RFC 2827, May 2000. 1509 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1510 Update", RFC 3007, November 2000. 1512 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1513 and M. Carney, "Dynamic Host Configuration Protocol for 1514 IPv6 (DHCPv6)", RFC 3315, July 2003. 1516 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1517 "DNS Extensions to Support IP Version 6", RFC 3596, 1518 October 2003. 1520 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1521 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1522 December 2003. 1524 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1525 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1527 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1528 RFC 3972, March 2005. 1530 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1531 More-Specific Routes", RFC 4191, November 2005. 1533 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1534 Architecture", RFC 4291, February 2006. 1536 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1537 Message Protocol (ICMPv6) for the Internet Protocol 1538 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1540 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1541 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1542 September 2007. 1544 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1545 Address Autoconfiguration", RFC 4862, September 2007. 1547 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1548 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1549 March 2008. 1551 11.2. Informative References 1553 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1554 Switching Networks", May 1974. 1556 [I-D.cheshire-dnsext-multicastdns] 1557 Cheshire, S. and M. Krochmal, "Multicast DNS", 1558 draft-cheshire-dnsext-multicastdns-08 (work in progress), 1559 September 2009. 1561 [I-D.clausen-manet-autoconf-recommendations] 1562 Clausen, T. and U. Herberg, "MANET Router Configuration 1563 Recommendations", 1564 draft-clausen-manet-autoconf-recommendations-00 (work in 1565 progress), February 2009. 1567 [I-D.clausen-manet-linktype] 1568 Clausen, T., "The MANET Link Type", 1569 draft-clausen-manet-linktype-00 (work in progress), 1570 October 2008. 1572 [I-D.droms-dhc-dhcpv6-default-router] 1573 Droms, R. and T. Narten, "Default Router and Prefix 1574 Advertisement Options for DHCPv6", 1575 draft-droms-dhc-dhcpv6-default-router-00 (work in 1576 progress), March 2009. 1578 [I-D.hain-ipv6-ulac] 1579 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1580 IPv6 Unicast Unique Local Address Prefixes", 1581 draft-hain-ipv6-ulac-01 (work in progress), October 2009. 1583 [I-D.ietf-autoconf-manetarch] 1584 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1585 Network Architecture", draft-ietf-autoconf-manetarch-07 1586 (work in progress), November 2007. 1588 [I-D.ietf-csi-proxy-send] 1589 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1590 ND Support for SEND", draft-ietf-csi-proxy-send-01 (work 1591 in progress), July 2009. 1593 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 1594 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 1595 Assignment Notification (RAAN) Option", 1596 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 1597 progress), July 2009. 1599 [I-D.ietf-dhc-subnet-alloc] 1600 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1601 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-10 1602 (work in progress), November 2009. 1604 [I-D.ietf-manet-smf] 1605 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1606 draft-ietf-manet-smf-09 (work in progress), July 2009. 1608 [I-D.ietf-v6ops-tunnel-security-concerns] 1609 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1610 Concerns With IP Tunneling", 1611 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1612 progress), October 2008. 1614 [I-D.jen-apt] 1615 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1616 L. Zhang, "APT: A Practical Transit Mapping Service", 1617 draft-jen-apt-01 (work in progress), November 2007. 1619 [I-D.nakibly-v6ops-tunnel-loops] 1620 Nakibly, G., "Routing Loops using ISATAP and 6to4: Problem 1621 Statement and Proposed Solutions", 1622 draft-nakibly-v6ops-tunnel-loops-00 (work in progress), 1623 October 2009. 1625 [I-D.russert-rangers] 1626 Russert, S., Fleischman, E., and F. Templin, "RANGER 1627 Scenarios", draft-russert-rangers-01 (work in progress), 1628 September 2009. 1630 [I-D.templin-isatap-dhcp] 1631 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1632 Option for the Intra-Site Automatic Tunnel Addressing 1633 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1634 progress), December 2009. 1636 [I-D.templin-ranger] 1637 Templin, F., "Routing and Addressing in Next-Generation 1638 EnteRprises (RANGER)", draft-templin-ranger-09 (work in 1639 progress), October 2009. 1641 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1642 July 1978. 1644 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1645 Protocol Specification", October 2008. 1647 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1648 Communication Layers", STD 3, RFC 1122, October 1989. 1650 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1651 September 1991. 1653 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1654 Routing and Addressing Architecture", RFC 1753, 1655 December 1994. 1657 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1658 E. Lear, "Address Allocation for Private Internets", 1659 BCP 5, RFC 1918, February 1996. 1661 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1662 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1664 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1665 Extensions", RFC 2132, March 1997. 1667 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1668 over Non-Broadcast Multiple Access (NBMA) networks", 1669 RFC 2491, January 1999. 1671 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1672 (MANET): Routing Protocol Performance Issues and 1673 Evaluation Considerations", RFC 2501, January 1999. 1675 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1676 Domains without Explicit Tunnels", RFC 2529, March 1999. 1678 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1679 February 2000. 1681 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1682 via IPv4 Clouds", RFC 3056, February 2001. 1684 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1685 Networks", BCP 84, RFC 3704, March 2004. 1687 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1688 RFC 3753, June 2004. 1690 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1691 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1692 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1693 RFC 3819, July 2004. 1695 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1696 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1697 May 2005. 1699 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1700 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1701 September 2005. 1703 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1704 Addresses", RFC 4193, October 2005. 1706 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1707 Internet Protocol", RFC 4301, December 2005. 1709 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1710 Network Address Translations (NATs)", RFC 4380, 1711 February 2006. 1713 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1714 Proxies (ND Proxy)", RFC 4389, April 2006. 1716 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1717 Multicast Name Resolution (LLMNR)", RFC 4795, 1718 January 2007. 1720 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1721 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1722 Focus", RFC 4852, April 2007. 1724 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1725 June 2007. 1727 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1728 Extensions for Stateless Address Autoconfiguration in 1729 IPv6", RFC 4941, September 2007. 1731 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1732 for IPv6", RFC 5340, July 2008. 1734 Appendix A. Duplicate Address Detection (DAD) Considerations 1736 A priori uniqueness determination (also known as "pre-service DAD") 1737 for an RLOC assigned on an enterprise-interior interface would 1738 require either flooding the entire enterprise or somehow discovering 1739 a link in the enterprise on which a node that configures a duplicate 1740 address is attached and performing a localized DAD exchange on that 1741 link. But, the control message overhead for such an enterprise-wide 1742 DAD would be substantial and prone to false-negatives due to packet 1743 loss and intermittent connectivity. An alternative to pre-service 1744 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1745 interfaces and employ a passive in-service DAD (e.g., one that 1746 monitors routing protocol messages for duplicate assignments). 1748 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1749 CGAs, IPv6 privacy addresses, etc. with very small probability of 1750 collision. Pseudo-random IPv4 RLOCs can be generated through random 1751 assignment from a suitably large IPv4 prefix space. 1753 Consistent operational practices can assure uniqueness for EBG- 1754 aggregated addresses/prefixes, while statistical properties for 1755 pseudo-random address self-generation can assure uniqueness for the 1756 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1757 RLOC delegation authority should be used when available, while a 1758 passive in-service DAD mechanism should be used to detect RLOC 1759 duplications when there is no RLOC delegation authority. 1761 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1763 For each distinct enterprise that it connects to, an EBR configures a 1764 VET interface over possibly multiple underlying interfaces that all 1765 connect to the same enterprise. The VET interface therefore 1766 represents the EBR's logical point of attachment to the enterprise, 1767 and provides a logical interface for link-layer multiplexing over its 1768 underlying interfaces as described in Section 3.3.4.1 of [RFC1122]: 1770 "Finally, we note another possibility that is NOT multihoming: one 1771 logical interface may be bound to multiple physical interfaces, in 1772 order to increase the reliability or throughput between directly 1773 connected machines by providing alternative physical paths between 1774 them. For instance, two systems might be connected by multiple 1775 point-to-point links. We call this "link-layer multiplexing". 1776 With link-layer multiplexing, the protocols above the link layer 1777 are unaware that multiple physical interfaces are present; the 1778 link-layer device driver is responsible for multiplexing and 1779 routing packets across the physical interfaces." 1781 EBRs can support such a link-layer multiplexing capability across the 1782 enterprise in accordance with the Weak End System Model (see Section 1783 3.3.4.2 of [RFC1122]). In particular, when an EBR autoconfigures an 1784 RLOC address (see Section 4.1), it can associate it with the VET 1785 interface only instead of assigning it to an underlying interface. 1786 The EBR therefore only needs to obtain a single RLOC address even if 1787 there are multiple underlying interfaces, i.e., it does not need to 1788 obtain one for each underlying interface. The EBR can then leave the 1789 underlying interfaces unnumbered, or it can configure a randomly 1790 chosen IP link-local address (e.g., from the prefix 169.254/16 1791 [RFC3927] for IPv4) on underlying interfaces that require a 1792 configuration. The EBR need not check these link-local addresses for 1793 uniqueness within the enterprise, as they will not normally be used 1794 as the source address for packets. 1796 When the EBR engages in the enterprise-interior routing protocol, it 1797 uses the RLOC address assigned to the VET interface as the source 1798 address for all routing protocol control messages, however it must 1799 also supply an interface identifier (e.g., a small integer) that 1800 uniquely identifies the underlying interface that the control message 1801 is sent over. For example, if the underlying interfaces are known as 1802 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1803 sends a routing protocol control message over the "eth7" interface. 1804 This is necessary to ensure that other routers can determine the 1805 specific interface over which the EBR's routing protocol control 1806 message was sent, but the token need only be unique within the EBR 1807 itself and need not be unique throughout the enterprise. 1809 When the EBR discovers an RLOC route via the enterprise interior 1810 routing protocol, it configures a preferred route in the IP FIB that 1811 points to the VET interface instead of the underlying interface. At 1812 the same time, the EBR also configures an ancillary route that points 1813 to the underlying interface. If the EBR discovers that the same RLOC 1814 route is reachable via multiple underlying interfaces, it configures 1815 multiple ancillary routes (i.e., one for each interface). If the EBR 1816 discovers that the RLOC route is no longer reachable via any 1817 underlying interface, it removes the route in the IP FIB that points 1818 to the VET interface. 1820 With these arrangements, all locally-generated packets with RLOC 1821 destinations will flow through the VET interface (and thereby use the 1822 VET interface's RLOC address as the source address) instead of 1823 through the underlying interfaces. In the same fashion, all 1824 forwarded packets with RLOC destinations will flow through the VET 1825 interface instead of through the underlying interfaces. 1827 This arrangement has several operational advantages that enable a 1828 number of traffic engineering capabilities. First, the VET interface 1829 inserts the SEAL header so that ID-based duplicate packet detection 1830 is enabled within the enterprise. Secondly, SEAL can dynamically 1831 adjust its packet sizing parameters so that an optimum Maximum 1832 Transmission Unit (MTU) can be determined. This is true even if the 1833 VET interface reroutes traffic between underlying interfaces with 1834 different MTUs. 1836 Most importantly, the EBR can configure default and more-specific 1837 routes on the VET interface to direct traffic through a specific 1838 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1839 will ensure that a specific eEBR is chosen, and the best eEBR can be 1840 chosen when multiple are available. Also, local applications see a 1841 stable IP source address even if there are multiple underlying 1842 interfaces. This link-layer multiplexing can therefore provide 1843 continuous operation across failovers between multiple links attached 1844 to the same enterprise without any need for readdressing. Finally, 1845 the VET interface can forward packets with RLOC-based destinations 1846 over an underlying interface without any encapsulation if 1847 encapsulation avoidance is desired. 1849 It must be specifically noted that the above arrangement constitutes 1850 a case in which the same RLOC may be used as both the inner and outer 1851 IP source address. This will not present a problem as long as both 1852 ends configure a VET interface in the same fashion. 1854 It must also be noted that EID-based communications can use the same 1855 VET interface arrangement, except that the EID-based next hop must be 1856 mapped to an RLOC-based next-hop within the VET interface. For IPvX- 1857 in-SEAL-in-IPvX encapsulation, as well as for IPv4-in-SEAL-in-Pv6 1858 encapsulation, this requires a VET interface specific address mapping 1859 database. For IPv6-in-SEAL-in-IPv4 encapsulation, the mapping is 1860 accomplished through simple static extraction of an IPv4 address 1861 embedded in a VET address. 1863 Appendix C. Anycast Services 1865 Some of the IPv4 addresses that appear in the Potential Router List 1866 may be anycast addresses, i.e., they may be configured on the VET 1867 interfaces of multiple EGBRs/EBGs. In that case, each VET router 1868 interface that configures the same anycast address must provide 1869 equivalent packet forwarding and IPv6 Neighbor Discovery services. 1871 Use of an anycast address as the IP destination address of tunneled 1872 packets can have subtle interactions with tunnel path MTU and 1873 neighbor discovery. For example, if the initial fragments of a 1874 fragmented tunneled packet with an anycast IP destination address are 1875 routed to different egress tunnel endpoints than the remaining 1876 fragments, the multiple endpoints will be left with incomplete 1877 reassembly buffers. This issue can be mitigated by ensuring that 1878 each egress tunnel endpoint implements a proactive reassembly buffer 1879 garbage collection strategy. Additionally, ingress tunnel endpoints 1880 that send packets with an anycast IP destination address must use the 1881 minimum path MTU for all egress tunnel endpoints that configure the 1882 same anycast address as the tunnel MTU. Finally, ingress tunnel 1883 endpoints must treat ICMP unreachable messages from a router within 1884 the tunnel as at most a weak indication of neighbor unreachability, 1885 since the failures may only be transient and quickly corrected 1886 through reconvergence of the underlying routing protocol. 1888 Use of an anycast address as the IP source address of tunneled 1889 packets can lead to more serious issues. For example, when the IP 1890 source address of a tunneled packet is anycast, ICMP messages 1891 produced by routers within the tunnel might be delivered to different 1892 ingress tunnel endpoints than the ones that produced the packets. In 1893 that case, functions such as path MTU discovery and neighbor 1894 unreachability detection may experience non-deterministic behavior 1895 that can lead to communications failures. Additionally, the 1896 fragments of multiple tunneled packets produced by multiple ingress 1897 tunnel endpoints may be delivered to the same reassembly buffer at a 1898 single egress tunnel endpoint. In that case, data corruption may 1899 result due to fragment misassociation during reassembly. 1901 In view of these considerations, EBRs/EBGs that configure an anycast 1902 address should also configure one or more unicast addresses from the 1903 Potential Router List; they should further accept tunneled packets 1904 destined to any of their anycast or unicast addresses, but should 1905 send tunneled packets using a unicast address as the source address. 1906 The sole exception to this rule is that EBRs/EBGs should respond to 1907 unicast IPv6 Neighbor and Router Solicitation messages by using the 1908 destination address of the solicitation as the source address for the 1909 corresponding advertisement messages, i.e., whether the address is 1910 anycast or unicast. In order to influence traffic to use an anycast 1911 route (and thereby leverage the natural fault tolerance afforded by 1912 anycast), ISATAP routers should set higher preferences on the default 1913 routes they advertise using an anycast address as the source and set 1914 lower preferences on the default routes they advertise using a 1915 unicast address as the source (see: [RFC4191]). 1917 Appendix D. Change Log 1919 (Note to RFC editor - this section to be removed before publication 1920 as an RFC.) 1922 Changes from -03 to -04: 1924 o security consideration clarifications 1926 Changes from -02 to -03: 1928 o security consideration clarifications 1930 o new PRLNAME for VET is "isatav2.example.com" 1932 o VET now uses SEAL natively 1934 o EBGs can support both legacy ISATAP and VET over the same 1935 underlying interfaces. 1937 Changes from -01 to -02: 1939 o Defined CGA and privacy address configuration on VET interfaces 1941 o Interface identifiers added to routing protocol control messages 1942 for link-layer multiplexing 1944 Changes from -00 to -01: 1946 o Section 4.1 clarifications on link-local assignment and RLOC 1947 autoconfiguration. 1949 o Appendix B clarifications on Weak End System Model 1951 Changes from RFC5558 to -00: 1953 o New appendix on RLOC configuration on VET intefaces. 1955 Author's Address 1957 Fred L. Templin (editor) 1958 Boeing Research & Technology 1959 P.O. Box 3707 MC 7L-49 1960 Seattle, WA 98124 1961 USA 1963 Email: fltemplin@acm.org