idnits 2.17.1 draft-templin-autoconf-dhcp-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2009) is 5582 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ENCAPS' is mentioned on line 178, but not defined == Unused Reference: 'RFC4291' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1231, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-07 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-08 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 4 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 and Technology 4 Intended status: Informational January 13, 2009 5 Expires: July 17, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-27.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 17, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 Enterprise networks connect routers over various link types, and may 48 also connect to provider networks and/or the global Internet. Nodes 49 in enterprise networks must have a way to automatically provision IP 50 addresses/prefixes and other information, and must also support 51 internetworking operation even in highly-dynamic networks. This 52 document specifies a Virtual Enterprise Traversal (VET) abstraction 53 for autoconfiguration and operation of nodes in enterprise networks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 8 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1. Enterprise Interior Router (EIR) Autoconfiguration . . . . 9 62 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 11 63 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 11 64 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration . . 12 65 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration . . 13 66 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 13 67 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 13 68 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 14 69 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 14 70 5.2. PA Prefix Maintenance . . . . . . . . . . . . . . . . . . 14 71 5.3. IPv6 EBG Discovery . . . . . . . . . . . . . . . . . . . . 14 72 5.4. IPv6 PI Prefix Registration . . . . . . . . . . . . . . . 15 73 5.5. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . . . 17 74 5.6. Forwarding Packets . . . . . . . . . . . . . . . . . . . . 18 75 5.7. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 18 76 5.8. Generating Errors . . . . . . . . . . . . . . . . . . . . 19 77 5.9. Processing Errors . . . . . . . . . . . . . . . . . . . . 19 78 5.10. Mobility and Multihoming Considerations . . . . . . . . . 20 79 5.11. Enterprise-Local Communications . . . . . . . . . . . . . 21 80 5.12. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 21 81 5.13. Service Discovery . . . . . . . . . . . . . . . . . . . . 21 82 5.14. Enterprise Partitioning . . . . . . . . . . . . . . . . . 22 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 91 Appendix A. Duplicate Address Detection (DAD) Considerations . . 27 92 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 1. Introduction 97 Enterprise networks [RFC4852] connect routers over various link types 98 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 99 (MANETs) [RFC2501] can be considered as a challenging example of an 100 enterprise network, in that their topologies may change dynamically 101 over time and that they may employ little/no active management by a 102 centralized network administrative authority. These specialized 103 characteristics for MANETs require careful consideration, but the 104 same principles apply equally to other enterprise network scenarios. 106 This document specifies a Virtual Enterprise Traversal (VET) 107 abstraction for autoconfiguration and internetworking operation, 108 where addresses of different scopes may be assigned on various types 109 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 110 [RFC2460] are discussed within this context. The use of standard 111 DHCP [RFC2131][RFC3315] and neighbor discovery [RFC0826][RFC4861] 112 mechanisms is assumed unless otherwise specified. 114 Provider-edge Interfaces 115 x x x 116 | | | 117 +--------------------+---+--------+----------+ E 118 | | | | | n 119 | I | | .... | | t 120 | n +---+---+--------+---+ | e 121 | t | +--------+ /| | r 122 | e I x----+ | Host | I /*+------+--< p I 123 | r n | |Function| n|**| | r n 124 | n t | +--------+ t|**| | i t 125 | a e x----+ V e|**+------+--< s e 126 | l r . | E r|**| . | e r 127 | f . | T f|**| . | f 128 | V a . | +--------+ a|**| . | I a 129 | i c . | | Router | c|**| . | n c 130 | r e x----+ |Function| e \*+------+--< t e 131 | t s | +--------+ \| | e s 132 | u +---+---+--------+---+ | r 133 | a | | .... | | i 134 | l | | | | o 135 +--------------------+---+--------+----------+ r 136 | | | 137 x x x 138 Enterprise-edge Interfaces 140 Figure 1: Enterprise Router Architecture 142 Figure 1 above depicts the architectural model for an enterprise 143 router. As shown in the figure, an enterprise router may have a 144 variety of interface types including enterprise-edge, enterprise- 145 interior, provider-edge, internal-virtual, as well as VET interfaces 146 used for encapsulation of inner IP packets within outer IP headers. 147 The different types of interfaces are defined, and the 148 autoconfiguration mechanisms used for each type are specified. This 149 architecture applies equally for MANET routers, in which enterprise- 150 interior interfaces correspond to the wireless multihop radio 151 interfaces typically associated with MANETs. Out of scope for this 152 document is the autoconfiguration of provider interfaces, which must 153 be coordinated in a manner specific to the service provider's 154 network. 156 Enterprise routers must have a means for supporting both Provider- 157 Independent (PI) and Provider-Independent (PA) IP prefixes for 158 global-scope communications. This is especially true for enterprise 159 scenarios that involve mobility and multihoming. Ingress filtering 160 for multi-homed sites, adaptation based on authenticated ICMP 161 feedback from on-path routers, effective tunnel path MTU mitigations 162 and routing scaling suppression are also required in many enterprise 163 network scenarios. The VET specification provides a comprehensive 164 solution that addresses these issues and more. 166 VET represents a functional superset of 6over4 [RFC2529] and ISATAP 167 [RFC5214], and further supports additional encapsulations such as 168 IPsec [RFC4301], SEAL [I-D.templin-seal], etc. As a result, VET 169 provides a map-and-encaps architecture using IP-in-IP tunneling based 170 on both forwarding table and mapping service lookups (defined 171 herein). 173 The VET principles can be either directly or indirectly traced to the 174 deliberations of the ROAD group in January 1992, and also to still 175 earlier works including NIMROD [RFC1753], the Catenet model for 176 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 177 the high-level architectural aspects of the ROAD group deliberations 178 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 179 IPNG". 181 VET is related to the present-day activites of the IETF autoconf, 182 dhc, ipv6, manet and v6ops working groups, as well as the IRTF rrg 183 working group. 185 2. Terminology 187 The mechanisms within this document build upon the fundamental 188 principles of IP-within-IP encapsulation. The terms "inner" and 189 "outer" are used to respectively refer to the innermost IP {address, 190 protocol, header, packet, etc.} *before* encapsulation, and the 191 outermost IP {address, protocol, header, packet, etc.} *after* 192 encapsulation. VET also supports the inclusion of "mid-layer" 193 encapsulations between the inner and outer layers, including IPSec 194 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 195 [I-D.templin-seal], etc. 197 The terminology in the normative references apply; the following 198 terms are defined within the scope of this document: 200 subnetwork 201 the same as defined in [RFC3819]. 203 enterprise 204 the same as defined in [RFC4852]. 206 site 207 a logical and/or physical grouping of interfaces that connect a 208 topological area less than or equal to an enterprise in scope. A 209 site within an enterprise can in some sense be considered as an 210 enterprise unto itself. 212 Mobile Ad-hoc Network (MANET) 213 a connected topology of mobile or fixed routers that maintain a 214 routing structure among themselves over dynamic links, where a 215 wide variety of MANETs share common properties with enterprise 216 networks. Characteristics of MANETs are defined in [RFC2501], 217 Section 3. 219 enterprise/site/MANET 220 throughout the remainder of this document, the term "enterprise" 221 is used to collectively refer to any of enterprise/site/MANET, 222 i.e., the VET mechanisms and operational principles apply equally 223 to enterprises, sites and MANETs. 225 enterprise router 226 an Enterprise Interior Router, Enterprise Border Router, or 227 Enterprise Border Gateway. As depicted in Figure 1, an enterprise 228 router comprises a router function, a host function, one or more 229 enterprise-interior interfaces and zero or more internal virtual, 230 enterprise-edge, provider-edge and VET interfaces. 232 Enterprise Interior Router (EIR) 233 a fixed or mobile enterprise router that forwards packets over one 234 or more sets of enterprise-interior interface, where each set 235 connects to a distinct enterprise. 237 Enterprise Border Router (EBR) 238 an EIR that connects edge networks to the enterprise, and/or 239 connects multiple enterprises together. An EBR configures a 240 seperate VET interface over each set of enterprise-interior 241 interfaces that connect the EBR to each distinct enterprise. In 242 particular, an EBR may configure mulitple VET interfaces - one for 243 each distinct enterprise. All EBRs are also EIRs. 245 Enterprise Border Gateway (EBG) 246 an EBR that connects VET interfaces configued over child 247 enterprises to a provider network - either directly via a 248 provider-edge interface, or indirectly via another VET interface 249 configured over a parent enterprise. EBRs may act as EBGs on some 250 VET interfaces and as ordinary EBRs on other VET interfaces. All 251 EBGs are also EBRs. 253 enterprise-interior interface 254 a EIR's attachment to a link within an enterprise. Packets sent 255 over enterprise-interior interfaces may be forwarded over multiple 256 additional enterprise-interior interfaces within the enterprise 257 before they are forwarded via an enterprise-edge interface, 258 provider-edge interface or a VET interface configured over a 259 different enterprise. 261 enterprise-edge interface 262 an EBR's attachment to a link (e.g., an ethernet, a wireless 263 personal area network, etc.) on an arbitrarily-complex edge 264 network that the EBR connects to an enterprise and/or to provider 265 networks. 267 internal-virtual interface 268 a virtual interface that is a special case of either an 269 enterprise-edge or an enterprise-interior interface. Internal- 270 virtual interfaces that are also enterprise-edge interfaces are 271 often loopback interfaces of some form. Internal-virtual 272 interfaces that are also enterprise-interior interfaces are often 273 tunnel interfaces of some form configured over another enterprise- 274 interior interface. 276 provider-edge interface 277 an EBR's attachment to the Internet, or to a provider network 278 outside of the enterprise via which the Internet can be reached. 280 Routing Locator (RLOC) 281 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 282 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 283 is assigned to an enterprise-interior interface and unique within 284 the enterprise. RLOCs are used as identifiers for operating the 285 routing protocol and/or locators for packet forwarding within the 286 scope of the enterprise. RLOCs are used as the *outer* IP 287 addresses during encapsulation, and can also be used as addresses 288 for enterprise-internal communications that do not require 289 encapsulation. 291 Provider-Independent (PI) prefix 292 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 293 that is routable within a limited scope and may also appear in a 294 global mapping table. PI prefixes that can appear in a global 295 mapping table are typically delegated to an EBR by a registry, but 296 are not aggregated by a provider network. Local-use IPv6 and IPv4 297 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of 298 a PI prefix, but these typically do not appear in a global mapping 299 table. 301 Provider Aggregated (PA) prefix 302 an IPv6 or IPv4 prefix that is either derived from a PI prefix or 303 delegated directly to a provider network by a registry. 305 Virtual Enterprise Traversal (VET) 306 an abstraction that uses IP-in-IP encapsulation to span a multi- 307 link enterprise in a single (inner) IP hop. 309 VET interface 310 an EBR's Non-Broadcast, Multiple Access (NBMA) interface used for 311 Virtual Enterprise Traversal. The EBR configures a VET interface 312 over a set of underlying enterprise-interior interface(s) 313 belonging to the same enterprise. When there are multiple 314 distinct enterprises (each with their own distinct set of 315 enterprise-interior interfaces), the EBR configures a separate VET 316 interface over each set of enterprise-interior interfaces, i.e., 317 the EBR configures multiple VET interfaces. 319 The VET interface encapsulates each inner IP packet in any mid- 320 layer headers plus an outer IP header then forwards it on an 321 underlying enterprise-interior interface such that the TTL/Hop 322 Limit in the inner header is not decremented as the packet 323 traverses the enterprise. The VET interface therefore presents an 324 automatic tunneling abstraction that represents the enterprise as 325 a single IP hop. 327 VET host 328 any node (host or router) that configures a VET interface for host 329 operation only. Note that a single node may configure some of its 330 VET interfaces as host interfaces and others as router interfaces. 332 VET node 333 any node that configures and uses a VET interface. 335 The following additional acronyms are used throughout the document: 337 CGA - Cryptographically Generated Address 338 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 339 FIB - Forwarding Information Base 340 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 341 NBMA - Non-Broadcast, Multiple Access 342 ND - Neighbor Discovery 343 PA - Provider Aggregated 344 PI - Provider Independent 345 PIO - Prefix Information Option 346 PRL - Potential Router List 347 PRLNAME - Identifying name for the PRL (default is "isatap") 348 RIO - Route Information Option 349 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 350 SEAL - Subnetwork Encapsulation and Adaptation Layer 351 SLAAC - IPv6 StateLess Address AutoConfiguation 353 3. Enterprise Characteristics 355 Enterprises consist of links that are connected by enterprise routers 356 as depicted in Figure 1. All enterprise routers are also Enterprise 357 Interior Routers (EIRs), and typically participate in a routing 358 protocol over enterprise-interior interfaces to discover routes that 359 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 360 Border Routers (EBRs) are EIRs that connect edge networks and/or join 361 multiple enterprises together, while Enterprise Border Gateways 362 (EBGs) are EBRs that either directly or indirectly connect 363 enterprises to provider networks. 365 An enterprise may be as simple as a small collection of enterprise 366 routers (and their attached edge networks); an enterprise may also 367 contain other enterprises and/or be a subnetwork of a larger 368 enterprise. An enterprise may further encompass a set of branch 369 offices and/or nomadic hosts connected to a home office over one or 370 several service providers, e.g., through Virtual Private Network 371 (VPN) tunnels. 373 Enterprises that comprise link types with sufficiently similar 374 properties (e.g., Layer-2 (L2) address formats, maximum transmission 375 units (MTUs), etc.) can configure a sub-IP layer routing service such 376 that IP sees the enterprise as an ordinary shared link the same as 377 for a (bridged) campus LAN. In that case, a single IP hop is 378 sufficient to traverse the enterprise without IP layer encapsulation. 380 Enterprises that comprise link types with diverse properties and/or 381 configure multiple IP subnets must also provide a routing service 382 that operates as an IP layer mechanism. In that case, multiple IP 383 hops may be necessary to traverse the enterprise such that specific 384 autoconfiguration procedures are necessary to avoid multilink subnet 385 issues [RFC4903]. In particular, we describe herein the use of IP- 386 in-IP encapsulation to span the enterprise in a single (inner) IP hop 387 in order to avoid the multilink subnet issues that arise when 388 enterprise-interior interfaces are used directly by applications. 390 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 391 both a host function and router function. The host function supports 392 global-scoped communications over any of the enterprise router's non- 393 enterprise-interior interfaces according to the weak end system model 394 [RFC1122] and also supports enterprise-local-scoped communications 395 over its enterprise-interior interfaces. The router function engages 396 in the enterprise-interior routing protocol, connects any of the 397 enterprise router's edge networks to the enterprise and may also 398 connect the enterprise to provider networks (see: Figure 1). 400 In addition to other interface types, VET nodes configure VET 401 interfaces that view all other VET nodes in an enterprise as single- 402 hop neighbors, where the enterprise can also appear as a single IP 403 hop within another enterprise. VET nodes configure a separate VET 404 interface for each distinct enterprise to which they connect, and 405 discover a list of EBRs for each VET interface that can be used for 406 forwarding packets to off-enterprise destinations. The following 407 sections present the Virtual Enterprise Traversal approach. 409 4. Autoconfiguration 411 EIRs, EBRs, EBGs and VET hosts configure themselves for operation as 412 specified in the following subsections: 414 4.1. Enterprise Interior Router (EIR) Autoconfiguration 416 EIRs configure enterprise-interior interfaces and engage in routing 417 protocols over those interfaces. 419 When an EIR joins an enterprise, it first configures a unique IPv6 420 link-local address on each enterprise-interior interface that 421 requires an IPv6 link-local capability and an IPv4 link-local address 422 on each enterprise-interior interface that requires an IPv4 link- 423 local capability. IPv6 link-local address generation mechanisms that 424 provide sufficient uniqueness include Cryptographically Generated 425 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 426 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 427 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 428 provide an IPv4 link-local address generation capability. 430 Next, the EIR configures a Routing Locator (RLOC) of the outer IP 431 protocol version on each of its enterprise-interior interfaces and 432 engages in any routing protocols on those interfaces. The EIR can 433 configure an RLOC via explicit management, DHCP autoconfiguration, 434 pseudo-random self-generation from a suitably large address pool, or 435 through an alternate autoconfiguration mechanism. In some enterprise 436 use cases (e.g., highly dynamic MANETs), assignment of RLOCs as 437 singleton addresses (i.e., as /32s for IPv4 and /128s for IPv6) may 438 be necessary to avoid multilink subnet issues. 440 EIRs that configure RLOCs using DHCP may require relay support from 441 other EIRs within the enterprise; the EIR can alternatively configure 442 both a DHCP client and relay that are connected, e.g., via a pair of 443 back-to-back connected ethernet interfaces, a tun/tap interface, a 444 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 445 do not already know the RLOC of a server relay requests to the 446 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 447 relays that do not already know the RLOC of a server relay requests 448 to the site-scoped IPv4 multicast group address 'All_DHCPv4_Servers' 449 (see: Section 6). DHCPv4 servers that delegate RLOCs join the 450 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 451 received for that group. 453 Self-generation of RLOCs for IPv6 can be from a large IPv6 local-use 454 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 455 generation of RLOCs for IPv4 can be from a large IPv4 private address 456 range (e.g., [RFC1918]). When self-generation is used alone, the EIR 457 must continuously monitor the RLOCs for uniqueness, e.g., by 458 monitoring the routing protocol, but care must be taken in the 459 interaction of this monitoring with existing mechanisms. 461 A combined approach using both DHCP and self-generation is also 462 possible in which the EIR first self-generates a temporary RLOC used 463 only for the purpose of procuring an actual RLOC taken from a 464 disjoint addressing range. The EIR then assigns the temporary RLOC 465 to an enterprise-interior interface, engages in the routing protocol 466 and performs a DHCP client/relay exchange using the temporary RLOC as 467 the address of the relay. When the DHCP server delegates an actual 468 RLOC, the EIR abandons the temporary RLOC, assigns the actual RLOC to 469 the enterprise-interior interface and re-engages in the routing 470 protocol. 472 4.2. Enterprise Border Router (EBR) Autoconfiguration 474 EBRs are EIRs that configure VET interfaces over distinct sets of 475 underlying enterprise-interior interfaces; an EBR can connect to 476 multiple enterprises, in which case it would configure multiple VET 477 interfaces. EBRs perform the following autoconfiguration operations: 479 4.2.1. VET Interface Autoconfiguration 481 VET interface autoconfiguration entails: 1) interface initialization, 482 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 483 address autoconfiguration. These functions are specified in the 484 following sections: 486 4.2.1.1. Interface Initialization 488 EBRs configure a VET interface over a set of underlying enterprise- 489 interior interfaces belonging to the same enterprise, where the VET 490 interface presents a Non-Broadcast, Multiple Access (NBMA) 491 abstraction in which all EBRs in the enterprise appear as single hop 492 neighbors through the use of IP-in-IP encapsulation. 494 When IPv6 and IPv4 are used as the inner/outer protocols 495 (respectively), the EBR autoconfigures an ISATAP link-local address 496 ([RFC5214], Section 6.2) on the VET interface to support packet 497 forwarding and operation of the IPv6 neighbor discovery protocol. 498 The ISATAP link-local address embeds an IPv4 RLOC assigned to an 499 underlying enterprise-interior interface, and need not be checked for 500 uniqueness since the IPv4 RLOC itself was already checked (see: 501 Section 4.1). Link-local address configuration for other inner/outer 502 IP protocol combinations is through administrative configuration or 503 through an unspecified alternate method. 505 After the EBR configures a VET interface, it can communicate with 506 other VET nodes as single-hop neighbors from the viewpoint of the 507 inner IP protocol. 509 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 510 Identification 512 The EBR next discovers a list of EBGs for each of its VET interfaces. 513 The list can be discovered through information conveyed in the 514 routing protocol and/or through the Potential Router List (PRL) 515 discovery mechanisms outlined in ([RFC5214], Section 8.3.2). In 516 multicast-capable enterprises, they can also listen for 517 advertisements on the 'rasadv' [RASADV] IPv4 multicast group address. 519 In particular, whether or not routing information is available the 520 EBR can discover the list of EBGs in the PRL by resolving an 521 identifying name for the PRL ('PRLNAME') using an enterprise local 522 name resolution service (e.g., an enterprise-local DNS service, LLMNR 523 [RFC4759], etc.). 'PRLNAME' is formed as 'hostname.domainname', 524 where 'hostname' is an enterprise-specific name string and 525 'domainname' is an enterprise-specific DNS suffix when such a suffix 526 is available. 528 The EBR discovers 'PRLNAME' through manual configuration, a DHCP 529 option, 'rasadv' protocol advertisements, link-layer information 530 (e.g., an IEEE 802.11 SSID) or through some other means specific to 531 the enterprise. In the absence of other information, the EBR sets 532 the 'hostname' component of 'PRLNAME' to "isatap" and sets the 533 'domainname' component only if an enterprise-specifc DNS suffix 534 "example.com" is known (e.g., as "isatap.example.com"). 536 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 537 resolving 'PRLNAME' to a list of IPv4 addresses through a name 538 service lookup. 'PRLNAME' as well as the RLOCs of EBGs and/or the IP 539 prefixes they aggregate serve as an identifier for the enterprise. 541 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration 543 EBRs can acquire Provider-Aggregated (PA) prefixes through 544 autoconfiguration exchanges with EBGs over VET interfaces. When IPv4 545 is used as the inner IP protocol, the EBR acquires PA prefixes via an 546 unspecified automated IPv4 prefix delegation exchange, explicit 547 management, etc. 549 When IPv6 is used as the inner IP protocol, the EBR acquires PA 550 prefixes via IPv6 Neighbor Discovery and DHCPv6 Prefix Delegation 551 exchanges. In particular, the EBR (acting as a requesting router) 552 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 553 obtain PA IPv6 prefixes from the server (acting as a delegating 554 router). 556 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 557 exchange [RFC3315]. For example, to perform the 2-message exchange 558 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 559 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 560 relay (see: Section 4.1). The relay then forwards the message over 561 the VET interface to the EBG. The forwarded Solicit message will 562 elicit a reply from the server containing PA IPv6 prefix delegations. 564 The EBR can propose a specific prefix to the DHCPv6 server per 565 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 566 available. The server will check the proposed prefix for consistency 567 and uniqueness, then return it in the reply to the EBR if it was able 568 to perform the delegation. 570 After the EBR receives PA prefix delegations, it can provision the 571 prefixes on its enterprise-edge interfaces as well as on other VET 572 interfaces for which it is configured as an EBG. 574 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration 576 Independent of any PA prefixes, EBRs can acquire and use Provider- 577 Independent (PI) prefixes that are either delegated by a registration 578 authority or self-configured by the EBR 579 [RFC4193][I-D.ietf-ipv6-ula-central]). 581 When an EBR acquires a PI prefix, it must also obtain credentials 582 (e.g., from a certification authority) that it can use to prove 583 prefix ownership through Secure Neighbor Discovery (SEND) [RFC3971] 584 messaging. 586 The minimum-sized PI prefix that an EBR may acquire is a /56. 588 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 590 EBGs are EBRs that connect child enterprises to a provider network 591 via ordinay provider-edge interfaces and/or VET interfaces configured 592 over parent enterprises. EBGs autoconfigure provider-edge interfaces 593 in a manner that is specific to its provider connections, and 594 autoconfigure VET interfaces as specified in Section 4.2.1. EBGs 595 that support PA prefix delegation also configure a DHCP relay/server. 597 For each VET interface on which it is configured as an EBG, the EBG 598 must arrange to add its enterprise-interior interface addresses 599 (i.e., its RLOCs) to the PRL (see: Section 4.2.1.2), and must 600 maintain these resource records in accordance with ([RFC5214], 601 Section 9). In particular, for each such VET interface the EBG adds 602 its RLOCs to name service resource records for 'PRLNAME'. 604 4.4. VET Host Autoconfiguration 606 Nodes that cannot be attached via an EBR's enterprise-edge interface 607 (e.g., nomadic laptops that connect to a home office via a Virtual 608 Private Network (VPN)) can instead be configured for operation as a 609 simple host connected to the VET interface. Such VET hosts perform 610 the same VET interface autoconfiguration procedures as specified for 611 EBRs in Section 4.2.1, but they configure their VET interfaces as 612 host interfaces (and not router interfaces). VET hosts can then send 613 packets to other hosts on the VET interface, or to off-enterprise 614 destinations via a next-hop EBR. 616 Note that a node may be configured as a host on some VET interfaces 617 and as an EBR/EBG on other VET interfaces. 619 5. Internetworking Operation 621 Following the autoconfiguration procedures specified in Section 4, 622 EIRs, EBRs, EBGs and VET hosts engage in normal internetworking 623 operations as discussed in the following sections: 625 5.1. Routing Protocol Participation 627 Following autoconfiguration, EIRs engage in any routing protocols 628 over their enterprise-interior interfaces and forward outer IP 629 packets within the enterprise as for any ordinary router. 631 EBRs can additionally engage in any inner IP routing protocols over 632 enterprise-edge and provider-edge interfaces, and can use those 633 interfaces for forwarding inner IP packets to off-enterprise 634 destinations. Note that these inner IP routing protocols are 635 separate and distinct from any enterprise-interior routing protocols. 637 5.2. PA Prefix Maintenance 639 When an EBR uses DHCP prefix delegation to obtain PA prefixes via an 640 EBG, the DHCP server ensures that the delegations are unique and that 641 the EBG's router function will forward IP packets over the VET 642 interface to the correct EBR. 644 The DHCP prefix delegations remain active as long as the EBR 645 continues to issue renewals over the VET interface before lease 646 lifetimes expire. The lease lifetime also keeps the delegation state 647 active even if communications between the EBR and DHCP server are 648 disrupted for a period of time (e.g., due to an enterprise network 649 partition) before being reestablished (e.g., due to an enterprise 650 network merge). 652 Additionnally, ordinary requesting routers on enterprise edge 653 interfaces can maintain PA prefix delegations exactly as specified in 654 [RFC3633]. 656 5.3. IPv6 EBG Discovery 658 EBGs follow the router and prefix discovery procedures specified in 659 ([RFC5214], Section 8.2). They send solicited RAs over VET 660 interfaces for which they are configured as gateways with default 661 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 662 with any other required options/parameters. EBGs must set the 'M' 663 flag in RAs to 0, since the use of DHCPv6 for address configuration 664 on VET interfaces is undefined. EBGs can also include PIOs with the 665 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 666 of an aggregated prefix from which it is willing to delegate longer 667 PA prefixes. 669 VET nodes follow the router and prefix discovery procedures specified 670 in ([RFC5214], Section 8.3). They discover EBGs within the 671 enterprise as specified in Section 4.2.1.2, then perform SEND- 672 protected RS/RA exchanges with the EBGs to establish and maintain 673 default routes. In particular the VET node sends SEND-protected 674 unicast RS messages to EBGs over its VET interface(s) to receive 675 SEND-protected RAs. When the VET node receives an RA, it configures 676 a default route based on the Router Lifetime. If the RA contains 677 Prefix Information Options (PIOs) with the 'A' and 'L' bits set to 1, 678 the VET node also autoconfigures IPv6 addresses from the advertised 679 prefixes using SLAAC and assigns them to the VET interface. 680 Thereafter, the VET accepts packets that are fowarded by EBGs for 681 which they have current default routing information. 683 5.4. IPv6 PI Prefix Registration 685 When an EBR discovers next-hop EBGs for the enterprise, it must 686 register its PI prefixes by sending SEND-protected RAs to a set of 687 one or more EBGs with Route information Options (RIOs) [RFC4191] that 688 contain the EBR's PI prefixes. Each RA must include the RLOC of an 689 EBG as the outer IP destination address and an ISATAP link-local 690 address derived from the RLOC as the inner IP destination address. 691 The RAs must also include a CGA link-local inner source address along 692 with a SEND signature that can be used to validate the CGA plus any 693 certificates needed to prove ownership of the PI prefixes. The EBR 694 additionally tracks the set of EBGs that it sends RAs to so that it 695 can send subsequent RAs to the same set. 697 When the EBG receives the RA, it uses SEND to authenticate the 698 message; if the authentication fails, the EBG discards the RA. 699 Otherwise, the EBG installs the PI prefixes with their respective 700 lifetimes in its Forwarding Information Base (FIB) and configures 701 them for both ingress filtering [RFC3704] and forwarding purposes. 702 In particular, the EBG configures the FIB entries as ingress filter 703 rules to accept packets received on the VET interface with a source 704 address taken from the PI prefixes. It also configures the FIB 705 entries to forward packets received on other interfaces with a 706 destination address taken from the PI prefixes to the EBR that 707 registered the prefixes on the VET interface. 709 The EBG then publishes the PI prefixes in the enterprise mapping 710 system. For enterprises that are managed under a cooperative 711 administrative authority, the EBG publishes the PI prefixes in the 712 enterprise-local name service [RFC1035] using a secure automated name 713 service update mechanism [RFC3007]. For VET interfaces configured 714 over enterprises that are managed in a distributed fashion, EBG 715 should instead respond directly to LLMNR [RFC4759] name service 716 queries. 718 The EBG publishes each /56 prefix taken from the PI prefixes as a 719 seperate FQDN that consists of a sequence of 14 nibbles in reverse 720 order (i.e., the same as in [RFC3596], Section 2.5) followed by the 721 string 'PRLNAME'. For example, when 'PRLNAME' is 722 "isatap.example.com", the EBG publishes the prefix '2001:DB8::/56' 723 as: 724 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. The EBG includes 725 the inner IPv6 CGA source address (e.g., in a DNS AAAA record) and 726 the outer IPv4 source address of the RA (e.g., in a DNS A resource 727 record) in each prefix publication. If the prefix was already 728 installed in the name service, the EBG instead adds the outer IPv4 729 source address (e.g., in an additional DNS AAAA record) to the pre- 730 existing publication. 732 After the EBG authenticates the RA and publishes the PI prefixes, it 733 next acts as an EBR on the VET interfaces configured over any of its 734 provider enterprises and "relays" the RA to the default routers 735 (i.e., EBGs) on those interfaces. The EBR tracks the set of EBGs 736 that it relays the RA to, and should relay subsequent RAs to the same 737 set of EBGs. Each relayed RA is formatted exactly as for the 738 original RA, except that it uses the EBR's own CGA as the inner 739 source address and an RLOC taken from the VET interface as the outer 740 IP source address. The RA authentication and PI prefix publication 741 recurses in this fashion and ends when a default mapping service for 742 the interdomain routing core is reached. (In the case of the global 743 Internet interdomain routing core, the 'PRLNAME' for the default 744 mapping service is "isatap.net".) 746 After the initial PI prefix registration, the EBR that owns the 747 prefix(es) must periodically send additional RAs to its set of EBGs 748 to refresh prefix lifetimes. As long as the EBGs have retained 749 sufficient state from a previous RA authentication as a means for 750 detecting spoofed packets, however, authentication of these 751 "keepalive" RAs is not required. 753 This procedure has a close analogy in the Teredo method of 754 maintaining state in network middleboxes through the periodic 755 transmission of "bubbles" [RFC4380]. 757 5.5. IPv6 Next-Hop EBR Discovery 759 VET nodes discover destination-specific next-hop EBRs within the 760 enterprise by querying the name service for the /56 IPv6 PI prefix 761 taken from a packet's destination address. For example, for the IPv6 762 destination address '2001:DB8:1:2::1' and 'PRLNAME' 763 "isatap.example.com" the VET node can lookup the domain name: 764 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. If the name 765 service lookup succeeds, it will return an IPv6 CGA address (e.g., in 766 a DNS AAAA record) and IPv4 addresses (e.g., in DNS A records) that 767 correspond to the RLOCs assigned to enterprise interior interfaces of 768 next-hop EBRs. 770 When a VET node forwards a packet to an EBG that has a mapping for 771 the destination, the EBG forwards the packet to a next-hop EBR on the 772 VET interface and returns an ICMPv6 Redirect [RFC4861]. If the 773 packet's source address is on-link on the VET interface, the EBG 774 returns an ordinary "router-to-host" redirect with the source address 775 of the packet as its destination. If the packet's source address is 776 not on-link, the EBG instead returns a "router-to-router" redirect 777 with the link-local ISATAP address of the previous-hop EBR as its 778 destination. The EBG also includes in the redirect one or more link- 779 layer address options that contain the IPv4 RLOC addresses of 780 potential next-hop EBRs, where the target link-layer address options 781 are formatted exactly as specified in [RFC2529]. 783 When a VET host receives an ordinay "router-to-host" redirect, it 784 processes the redirect exacly as specified in [RFC4861], Section 8. 785 When an EBR receives a "router-to-router" redirect, it discovers the 786 IPv4 RLOC addresses of potential next-hop EBRs by examining the 787 target link-layer address options included in the redirect. The EBR 788 then installs a FIB entry that contains the /56 prefix of the 789 original packet's destination and the list of IPv4 RLOCs of potential 790 next-hop EBRs. The EBR then enables the FIB entry for forwarding to 791 next-hop EBRs but DOES NOT enable it for ingress filtering acceptance 792 of packets from next-hop EBRs (i.e., the forwarding determination is 793 unidirectional). The EBR then sends RAs over the VET interface to 794 one or more of the potential next-hop EBRs with a link-local ISATAP 795 address that embeds a next-hop EBR IPv4 RLOC as the destination. The 796 RAs must include the EBR's CGA link-local address as the inner IPv6 797 source address along with a SEND signature. The RAs must also 798 include a Route Information Option (RIO) [RFC4191] that contains the 799 /56 PI prefix of the original packet's source address. 801 When a next-hop EBR receives the RA, it uses SEND to verify the CGA 802 then performs a name service lookup on the prefix in the RIO. If the 803 name service returns the correct CGA and RLOC information, the next- 804 hop EBR then installs the prefix in the RIO in its FIB and enables 805 the FIB entry for ingress filtering but DOES NOT enable it for 806 forwarding purposes. 808 After an EBR sends initial RAs following a redirect, it should send 809 periodic RAs to refresh the next-hop EBR's ingress filter prefix 810 lifetimes as long as traffic is flowing. 812 5.6. Forwarding Packets 814 VET nodes forward packets by consulting the FIB to determine a 815 specific EBR/EBG as the next-hop router on a VET interface. When 816 multiple next-hop routers are available, VET nodes can use default 817 router preferences, routing protocol information, traffic engineering 818 configurations, etc. to select the best exit router. When there is 819 no FIB information available, VET nodes can discover the next-hop 820 EBR/EBG through the mechanisms specified in Section 5.3 and 821 Section 5.5. 823 VET interfaces encapsulate inner IP packets in any mid-layer headers 824 followed by an outer IP header according to the specific 825 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 826 next submit the encapsulated packet to the outer IP forwarding engine 827 for transmission on an underlying enterprise-interior interface. 829 For forwarding to next-hop addresses over VET interfaces that use 830 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 831 address (i.e., the IPv4 RLOC of the next-hop EBR) through static 832 extraction of the IPv4 address embedded in the next-hop ISATAP 833 address. For other IP-in-IP encapsulations, determination of the 834 outer destination address is through administrative configuration or 835 through an unspecified alternate method. 837 5.7. SEAL Encapsulation 839 VET nodes that do not use IPsec encapsulation should use SEAL 840 encapsulation [I-D.templin-seal] in conjunction with packet 841 forwarding over VET interfaces to accommdate path MTU diversity, to 842 detect source address spoofing, and to monitor next-hop EBR 843 reachability. 845 In terms of security, when a VET node receives an ICMP message, it 846 can confirm that the packet-in-error within the ICMP message 847 corresponds to one of its recently-sent packets by examining the 848 SEAL_ID (i.e., the VET node's sequence number for a specific next-hop 849 EBR). Additionally, a next-hop EBR can track the SEAL_ID in packets 850 received from EBRs for which there is an ingress filter entry and 851 discard packets that have SEAL_ID values outside of the current 852 window. To maintain synchronization, the next-hop EBR resets its 853 cached SEAL_IDs for correspondent EBRs/EBGs whenever it receives a 854 fresh SEND-protected RA. 856 In terms of next-hop reachability, an EBR can set the SEAL 857 "Acknowledgement Requested" bit in messages to receive confirmation 858 that a next-hop EBR is reachable. Setting the "Acknowledgement 859 Requested" bit is also used as the method for maintaining the window 860 of outstanding SEAL_ID's. 862 5.8. Generating Errors 864 When an EBR receives a packet for which it has no longest-prefix- 865 match FIB entry for the source (i.e., an ingress filter entry), it 866 drops the packet and returns a SEAL-encapsulated ICMPv6 [RFC4443] 867 "Destination Unreachable; Source address failed ingress/egress 868 policy" message to the previous hop EBR subject to rate limiting. 870 When an EBR/EBG receives a packet for which there is no longest- 871 prefix-match FIB entry for the destination, it drops the packet and 872 returns a SEAL-encapsulated ICMPv6 "Destination Unreachable; No route 873 to destination" message to the previous hop EBR subject to rate 874 limiting. Additionally, when a VET node that is configured as an 875 ordinary EBR (i.e. and not an EBG) on the VET interface receives a 876 packet for which there is no longest-prefix-match FIB entry for the 877 destination that is more-specific than ::/0 (i.e., default), it must 878 drop the packet and return an ICMPv6 unreachable in order to prevent 879 looping. 881 5.9. Processing Errors 883 When an EBR receives an ICMPv6 "Destination Unreachable; Source 884 address failed ingress/egress policy" message from a next-hop EBR, it 885 should mark the longest-prefix-match FIB entry for the destination as 886 "forwarding suspended" for the RLOC taken from the source address of 887 the ICMPv6 message. The EBR should then allow subsequent packets to 888 flow through different RLOCs associated with the FIB entry until it 889 forwards a new SEND-protected RA to the suspended RLOC. If the EBR 890 receives excessive ICMPv6 ingress policy errors through multiple 891 RLOCs associated with the same FIB entry, it should delete the FIB 892 entry and allow subsequent packets to flow through a different route. 894 When a VET node receives an ICMPv6 "Destination Unreachable; No route 895 to destination" message from a next-hop EBR, and the node has a 896 longest-prefix-match FIB entry for the original packet's destination 897 that is more-specific than ::/0, the node discards the message and 898 deletes the FIB entry (i.e., to support graceful handling of mobility 899 events). If there is no FIB entry that is more-specific than ::/0, 900 the VET node instead forwards the ICMPv6 message to the source 901 address of the original packet, i.e., to inform the original source 902 that there is indeed no route to the final destination. 904 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 905 Unreachable; net / host unreachable" messages from an EIR indicating 906 that the path to a VET neighbor may be failing, but it should first 907 check the SEAL_ID or IPsec sequence number in the message before 908 accepting them. If a VET node detects that the path to a next-hop 909 EBR is failing, it should mark the longest-prefix-match FIB entry for 910 the destination as "forwarding suspended" for the RLOC destination 911 address of the ICMPv4 packet-in-error. If the EBR receives excessive 912 ICMPv4 unreachable errors through multiple RLOCs associated with the 913 same FIB entry, it should delete the FIB entry and allow subsequent 914 packets to flow through a different route. 916 5.10. Mobility and Multihoming Considerations 918 EBRs can retain their PI prefixes as they travel between distinct 919 enterprise networks as long as they register the prefixes with new 920 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 921 departure. Prefix registration with new EBGs is coordinated exactly 922 as specified in Section 5.4; prefix withdrawl from old EBGs is simply 923 through re-announcing the PI prefixes with zero lifetimes. 925 Since EBRs can move about independently of one another, stale FIB 926 entry state may be left in VET nodes when a neighboring EBR departs. 927 Additionally, EBRs can lose state for various reasons, e.g., power 928 failure, machine reboot, etc. For this reason, EBRs are advised to 929 set relatively short PI prefix lifetimes in RIO options, and to send 930 additional RAs to refresh lifetimes before they expire. (EBRs should 931 place conservative limits on the RAs they send to reduce congestion, 932 however.) 934 EBRs may register their PI prefixes with multiple EBGs for 935 multihoming purposes. EBRs should only forward packets via EBGs with 936 which it has registered its PI prefixes, since other EBGs will simply 937 drop the packets return ICMPv6 "Destination Unreachable; Source 938 address failed ingress/egress policy" messages subject to rate 939 limiting. 941 EBRs can also act as delegating routers to sub-delegate portions of 942 their PI prefixes to requesting routers on their enterprise edge 943 interfaces and on VET interfaces for which they are configured as 944 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 945 become the PA prefixes for downstream-dependent nodes. Downstream- 946 dependent nodes that travel with a mobile provider EBR can continue 947 to use addresses configured from PA prefixes; downstream-dependent 948 nodes that move away from their provider EBR must perform address/ 949 prefix renumbering when they assocate with a new provider. 951 5.11. Enterprise-Local Communications 953 When permitted by policy, end systems that configure the endpoints of 954 enterprise-local communications can avoid VET interface encapsulation 955 by directly invoking the outer IP protocol using RLOCs assigned to 956 their enterprise-interior interfaces. For example, when the outer 957 protocol is IPv4, end systems can use IPv4 RLOCs for enterprise-local 958 communications over their enterprise-interior interfaces without 959 using encapsulation. 961 5.12. Multicast 963 In multicast-capable deployments, EIRs provide an enterprise-wide 964 multicasting service such as Simplified Multicast Forwarding (SMF) 965 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 966 that outer IP multicast messages of site- or greater scope will be 967 propagated across the enterprise. For such deployments, VET nodes 968 can also provide an inner IP multicast/broadcast capability over 969 their VET interfaces through mapping of the inner IP multicast 970 address space to the outer IP multicast address space. 972 VET nodes encapsulate inner IP multicast messages sent over the VET 973 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 974 outer IP header with a site-scoped outer IP multicast address as the 975 destination. For the case of IPv6 and IPv4 as the inner/outer 976 protocols (respectively), [RFC2529] provides mappings from the IPv6 977 multicast address space to the IPv4 multicast address space. For 978 other IP-in-IP encapsulations, mappings are established through 979 administrative configuration or through an unspecified alternate 980 method. 982 For multicast-capable enterprises, use of the inner IP multicast 983 service for operating the ND protocol over the VET interface is 984 available but should be used sparingly to minimize enterprise-wide 985 flooding. 987 5.13. Service Discovery 989 VET nodes can peform enterprise-wide service discovery using a 990 suitable name-to-address resolution service. Examples of flooding- 991 based services include the use of LLMNR [RFC4759] over the VET 992 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 993 underlying enterprise-interior interface. More scalable and 994 efficient service discovery mechanisms are for further study. 996 5.14. Enterprise Partitioning 998 EBGs can physically partition an enterprise by configuring multiple 999 VET interfaces over multiple distinct sets of underlying interfaces. 1000 In that case, each partition (i.e., each VET interface) must 1001 configure its own distinct 'PRLNAME' (e.g., 1002 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1004 EBGs can logically partition an enterprise using a single VET 1005 interface by sending RAs with PIOs containing different IPv6 PA 1006 prefixes to group nodes into different logical partitions. EBGs can 1007 identify partitions, e.g., by examining IPv4 RLOC prefixes, observing 1008 the interfaces over which RSs are received, etc. In that case, a 1009 single 'PRLNAME' can cover all partitions. 1011 6. IANA Considerations 1013 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1014 DHCPv4 server discovery is requested. The allocation should be taken 1015 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1016 the IANA 'multicast-addresses' registry. 1018 7. Security Considerations 1020 Security considerations for MANETs are found in [RFC2501]. 1022 Security considerations with tunneling that apply also to VET are 1023 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1024 that the outer IP source address of a packet received on a VET 1025 interface is correct for the inner IP source address using the 1026 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1027 the ingress filtering mechanisms specified in this document. 1029 SEND [RFC3971] and SEAL Section 5.7 provide additional securing 1030 mitigations to defeat rogue routers and source address spoofing. 1032 Rogue routers can send bogus RA messages with spoofed RLOC source 1033 addresses that can consume network resources and cause EBGs to 1034 perform extra work. Nonetheless, EBGs should not "blacklist" such 1035 RLOCs, as that may result in a denial of service to the RLOCs' 1036 legitimate owners. 1038 8. Related Work 1040 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1041 automatic tunneling in [RFC2529]. This concept was later called: 1042 "Virtual Ethernet" and investigated by Quang Nguyen under the 1043 guidance of Dr. Lixia Zhang. 1045 Telcordia has proposed DHCP-related solutions for MANETs through the 1046 CECOM MOSAIC program. 1048 The Naval Research Lab (NRL) Information Technology Division uses 1049 DHCP in their MANET research testbeds. 1051 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 1052 pertaining to tunneling mechanisms. 1054 An automated IPv4 prefix delegation mechanism is proposed in 1055 [I-D.ietf-dhc-subnet-alloc]. 1057 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1059 Various proposals within the IETF have suggested similar mechanisms. 1061 9. Acknowledgements 1063 The following individuals gave direct and/or indirect input that was 1064 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Brian 1065 Carpenter, James Bound, Thomas Clausen, Joel Halpern, Bob Hinden, 1066 Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David 1067 Meyer, Thomas Narten, Pekka Nikander, Alexandru Petrescu, John 1068 Spence, Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela Vanderveen, 1069 Lixia Zhang and others in the IETF AUTOCONF and MANET working groups. 1070 Many others have provided guidance over the course of many years. 1072 10. Contributors 1074 The following individuals have contributed to this document: 1076 Eric Fleischman (eric.fleischman@boeing.com) 1077 Thomas Henderson (thomas.r.henderson@boeing.com) 1078 Steven Russert (steven.w.russert@boeing.com) 1079 Seung Yi (seung.yi@boeing.com) 1081 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1082 of the document. 1084 11. References 1085 11.1. Normative References 1087 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1088 September 1981. 1090 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1091 RFC 792, September 1981. 1093 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1094 converting network protocol addresses to 48.bit Ethernet 1095 address for transmission on Ethernet hardware", STD 37, 1096 RFC 826, November 1982. 1098 [RFC1035] Mockapetris, P., "Domain names - implementation and 1099 specification", STD 13, RFC 1035, November 1987. 1101 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1102 RFC 2131, March 1997. 1104 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1105 (IPv6) Specification", RFC 2460, December 1998. 1107 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1108 Update", RFC 3007, November 2000. 1110 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1111 and M. Carney, "Dynamic Host Configuration Protocol for 1112 IPv6 (DHCPv6)", RFC 3315, July 2003. 1114 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1115 "DNS Extensions to Support IP Version 6", RFC 3596, 1116 October 2003. 1118 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1119 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1120 December 2003. 1122 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1123 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1125 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1126 RFC 3972, March 2005. 1128 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1129 More-Specific Routes", RFC 4191, November 2005. 1131 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1132 Architecture", RFC 4291, February 2006. 1134 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1135 Message Protocol (ICMPv6) for the Internet Protocol 1136 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1138 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1139 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1140 September 2007. 1142 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1143 Address Autoconfiguration", RFC 4862, September 2007. 1145 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1146 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1147 March 2008. 1149 11.2. Informative References 1151 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1152 Switching Networks", May 1974. 1154 [I-D.cheshire-dnsext-multicastdns] 1155 Cheshire, S. and M. Krochmal, "Multicast DNS", 1156 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1157 September 2008. 1159 [I-D.clausen-manet-linktype] 1160 Clausen, T., "The MANET Link Type", 1161 draft-clausen-manet-linktype-00 (work in progress), 1162 October 2008. 1164 [I-D.ietf-autoconf-manetarch] 1165 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1166 Network Architecture", draft-ietf-autoconf-manetarch-07 1167 (work in progress), November 2007. 1169 [I-D.ietf-dhc-subnet-alloc] 1170 Johnson, R., "Subnet Allocation Option", 1171 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1172 July 2008. 1174 [I-D.ietf-ipv6-ula-central] 1175 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1176 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1177 progress), June 2007. 1179 [I-D.ietf-manet-smf] 1180 Macker, J. and S. Team, "Simplified Multicast Forwarding 1181 for MANET", draft-ietf-manet-smf-08 (work in progress), 1182 November 2008. 1184 [I-D.ietf-v6ops-tunnel-security-concerns] 1185 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1186 Concerns With IP Tunneling", 1187 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1188 progress), October 2008. 1190 [I-D.templin-seal] 1191 Templin, F., "The Subnetwork Encapsulation and Adaptation 1192 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1193 August 2008. 1195 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1196 July 1978. 1198 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1199 Protocol Specification", October 2008. 1201 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1202 Communication Layers", STD 3, RFC 1122, October 1989. 1204 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1205 Routing and Addressing Architecture", RFC 1753, 1206 December 1994. 1208 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1209 E. Lear, "Address Allocation for Private Internets", 1210 BCP 5, RFC 1918, February 1996. 1212 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1213 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1215 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1216 (MANET): Routing Protocol Performance Issues and 1217 Evaluation Considerations", RFC 2501, January 1999. 1219 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1220 Domains without Explicit Tunnels", RFC 2529, March 1999. 1222 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1223 February 2000. 1225 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1226 via IPv4 Clouds", RFC 3056, February 2001. 1228 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1229 Networks", BCP 84, RFC 3704, March 2004. 1231 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1232 RFC 3753, June 2004. 1234 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1235 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1236 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1237 RFC 3819, July 2004. 1239 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1240 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1241 May 2005. 1243 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1244 Addresses", RFC 4193, October 2005. 1246 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1247 Internet Protocol", RFC 4301, December 2005. 1249 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1250 Network Address Translations (NATs)", RFC 4380, 1251 February 2006. 1253 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1254 Indicator Parameter for the "tel" URI", RFC 4759, 1255 December 2006. 1257 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1258 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1259 Focus", RFC 4852, April 2007. 1261 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1262 June 2007. 1264 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1265 Extensions for Stateless Address Autoconfiguration in 1266 IPv6", RFC 4941, September 2007. 1268 Appendix A. Duplicate Address Detection (DAD) Considerations 1270 A-priori uniqueness determination (also known as "pre-service DAD") 1271 for an RLOC assigned on an enterprise-interior interface would 1272 require either flooding the entire enterprise or somehow discovering 1273 a link in the enterprise on which a node that configures a duplicate 1274 address is attached and performing a localized DAD exchange on that 1275 link. But, the control message overhead for such an enterprise-wide 1276 DAD would be substantial and prone to false-negatives due to packet 1277 loss and intermittent connectivity. An alternative to pre-service 1278 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1279 interfaces and employ a passive in-service DAD (e.g., one that 1280 monitors routing protocol messages for duplicate assignments). 1282 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1283 CGAs, IPv6 privacy addresses, etc. with very small probability of 1284 collision. Pseudo-random IPv4 RLOCs can be generated through random 1285 assignment from a suitably large IPv4 prefix space. 1287 Consistent operational practices can assure uniqueness for EBG- 1288 aggregated addresses/prefixes, while statistical properties for 1289 pseudo-random address self-generation can assure uniqueness for the 1290 RLOCs assigned on an EIR's enterprise-interior interfaces. Still, an 1291 RLOC delegation authority should be used when available, while a 1292 passive in-service DAD mechanism should be used to detect RLOC 1293 duplications when there is no RLOC delegation authority. 1295 Appendix B. Change Log 1297 (Note to RFC editor - this section to be removed before publication 1298 as an RFC.) 1300 Changes from -26 to 27: 1302 o Introduced new model for PI prefix management. 1304 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1305 "isado"?) 1307 Changes from -25 to 26: 1309 o Clarifications on Router Discovery and Ingress FIltering. 1311 o Mechanisms for detecting locator liveness 1313 o Mechanisms for avoiding state synchonization requirements. 1315 Changes from -23 to 24: 1317 o Clarifications on router discovery. 1319 Changes from -22 to 23: 1321 o Clarifications on prefix mapping. 1323 Changes from -21 to 22: 1325 o Using SEAL to secure VET 1327 Changes from -20 to 21: 1329 o Enterprise partitioning. 1331 o Mapping and name service management. 1333 Changes from -18 to 20: 1335 o Added support for simple hosts. 1337 o Added EBG name service maintenace procedures 1339 o Added router and prefix maintenace procedures 1341 Changes from -17 to 18: 1343 o adjusted section headings to group autoconf operations under EIR/ 1344 EBR/EBG. 1346 o clarified M/O bits 1348 o clarified EBG roles 1350 Changes from -15 to 17: 1352 o title change to "Virtual Enterprise Traversal (VET)". 1354 o changed document focus from MANET-centric to the much-broader 1355 Enterprise-centric, where "Enterprise" is understood to also cover 1356 a wide range of MANET types. 1358 Changes from -14 to 15: 1360 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1362 o Address review comments 1364 Changes from -12 to 14: 1366 o title change to "The MANET Virtual Ethernet Abstraction". 1368 o Minor section rearrangement. 1370 o Clartifications on portable and self-configured prefixes. 1372 o Clarifications on DHCPv6 prefix delegation procedures. 1374 Changes from -11 to 12: 1376 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1378 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1379 delegation mechanism. 1381 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1383 o fixed editorials based on comments received. 1385 Changes from -10 to 11: 1387 o removed the transparent/opaque VET portal abstractions. 1389 o removed routing header as an option for MANET exit router 1390 selection. 1392 o included IPv6 SLAAC as an endorsed address configuration mechanism 1393 for the VET interface. 1395 Changes from -08 to -09: 1397 o Introduced the term "VET". 1399 o Changed address delegation language to speak of "MNBR-aggregated" 1400 instead of global/local. 1402 o Updated figures 1-3. 1404 o Explained why a MANET interface is "neutral". 1406 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1407 DHCPv4 servers; not relays. 1409 Changes from -07 to -08: 1411 o changed terms "unenhanced" and "enhanced" to "transparent" and 1412 "opaque". 1414 o revised MANET Router diagram. 1416 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1417 interface. 1419 o changed abbreviations to "MNR" and "MNBR". 1421 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1423 o rearranged Section 3.1. 1425 o various minor text cleanups 1427 Changes from -06 to -07: 1429 o added MANET Router diagram. 1431 o added new references 1433 o various minor text cleanups 1435 Changed from -05 to -06: 1437 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1439 o minor changes to preserve generality 1441 Changed from -04 to -05: 1443 o introduced conceptual "virtual ethernet" model. 1445 o support "raw" and "cooked" modes as equivalent access methods on 1446 the virutal ethernet. 1448 Changed from -03 to -04: 1450 o introduced conceptual "imaginary shared link" as a representation 1451 for a MANET. 1453 o discussion of autonomous system and site abstractions for MANETs 1455 o discussion of autoconfiguration of CGAs 1457 o new appendix on IPv6 StateLess Address AutoConfiguration 1459 Changes from -02 to -03: 1461 o updated terminology based on RFC2461 "asymmetric reachability" 1462 link type; IETF67 MANET Autoconf wg discussions. 1464 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1465 Address Detection 1467 o relaxed DHCP server deployment considerations allow DHCP servers 1468 within the MANET itself 1470 Changes from -01 to -02: 1472 o minor updates for consistency with recent developments 1474 Changes from -00 to -01: 1476 o new text on DHCPv6 prefix delegation and multilink subnet 1477 considerations. 1479 o various editorial changes 1481 Author's Address 1483 Fred L. Templin (editor) 1484 Boeing Research and Technology 1485 P.O. Box 3707 MC 7L-49 1486 Seattle, WA 98124 1487 USA 1489 Email: fltemplin@acm.org