idnits 2.17.1 draft-templin-autoconf-dhcp-28.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 19, 2009) is 5573 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 1141, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1246, 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 19, 2009 5 Expires: July 23, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-28.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 23, 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 . . . . 10 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 . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . 22 82 5.14. Enterprise Partitioning . . . . . . . . . . . . . . . . . 22 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 . . 28 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 EBGs provide packet forwarding, relaying and mapping services on 254 behalf of EBRs and ordinary VET hosts within the enterprise. A 255 "default mapper" [I-D.jen-apt] is a special case of an EBG that 256 performs all EBG services except forwarding packets to provider 257 networks ("default mappers" therefore must configure a default 258 route via a fully-qualified EBG). 260 enterprise-interior interface 261 a EIR's attachment to a link within an enterprise. Packets sent 262 over enterprise-interior interfaces may be forwarded over multiple 263 additional enterprise-interior interfaces within the enterprise 264 before they are forwarded via an enterprise-edge interface, 265 provider-edge interface or a VET interface configured over a 266 different enterprise. 268 enterprise-edge interface 269 an EBR's attachment to a link (e.g., an ethernet, a wireless 270 personal area network, etc.) on an arbitrarily-complex edge 271 network that the EBR connects to an enterprise and/or to provider 272 networks. 274 internal-virtual interface 275 a virtual interface that is a special case of either an 276 enterprise-edge or an enterprise-interior interface. Internal- 277 virtual interfaces that are also enterprise-edge interfaces are 278 often loopback interfaces of some form. Internal-virtual 279 interfaces that are also enterprise-interior interfaces are often 280 tunnel interfaces of some form configured over another enterprise- 281 interior interface. 283 provider-edge interface 284 an EBR's attachment to the Internet, or to a provider network 285 outside of the enterprise via which the Internet can be reached. 287 Enterprise Local Address (ELA) 288 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 289 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 290 is assigned to an enterprise-interior interface and unique within 291 the enterprise. ELAs are used as identifiers for operating the 292 routing protocol and/or locators for packet forwarding within the 293 scope of the enterprise. ELAs are used as the *outer* IP 294 addresses during encapsulation, and can also be used as addresses 295 for enterprise-internal communications that do not require 296 encapsulation. 298 Provider-Independent (PI) prefix 299 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 300 that is routable within a limited scope and may also appear in a 301 global mapping table. PI prefixes that can appear in a global 302 mapping table are typically delegated to an EBR by a registry, but 303 are not aggregated by a provider network. Local-use IPv6 and IPv4 304 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of 305 a PI prefix, but these typically do not appear in a global mapping 306 table. 308 Provider Aggregated (PA) prefix 309 an IPv6 or IPv4 prefix that is either derived from a PI prefix or 310 delegated directly to a provider network by a registry. 312 Virtual Enterprise Traversal (VET) 313 an abstraction that uses IP-in-IP encapsulation to span a multi- 314 link enterprise in a single (inner) IP hop. 316 VET interface 317 an EBR's Non-Broadcast, Multiple Access (NBMA) interface used for 318 Virtual Enterprise Traversal. The EBR configures a VET interface 319 over a set of underlying enterprise-interior interface(s) 320 belonging to the same enterprise. When there are multiple 321 distinct enterprises (each with their own distinct set of 322 enterprise-interior interfaces), the EBR configures a separate VET 323 interface over each set of enterprise-interior interfaces, i.e., 324 the EBR configures multiple VET interfaces. 326 The VET interface encapsulates each inner IP packet in any mid- 327 layer headers plus an outer IP header then forwards it on an 328 underlying enterprise-interior interface such that the TTL/Hop 329 Limit in the inner header is not decremented as the packet 330 traverses the enterprise. The VET interface therefore presents an 331 automatic tunneling abstraction that represents the enterprise as 332 a single IP hop. 334 VET host 335 any node (host or router) that configures a VET interface for host 336 operation only. Note that a single node may configure some of its 337 VET interfaces as host interfaces and others as router interfaces. 339 VET node 340 any node that configures and uses a VET interface. 342 The following additional acronyms are used throughout the document: 344 CGA - Cryptographically Generated Address 345 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 346 FIB - Forwarding Information Base 347 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 348 NBMA - Non-Broadcast, Multiple Access 349 ND - Neighbor Discovery 350 PA - Provider Aggregated 351 PI - Provider Independent 352 PIO - Prefix Information Option 353 PRL - Potential Router List 354 PRLNAME - Identifying name for the PRL (default is "isatap") 355 RIO - Route Information Option 356 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 357 SEAL - Subnetwork Encapsulation and Adaptation Layer 358 SLAAC - IPv6 StateLess Address AutoConfiguation 360 3. Enterprise Characteristics 362 Enterprises consist of links that are connected by enterprise routers 363 as depicted in Figure 1. All enterprise routers are also Enterprise 364 Interior Routers (EIRs), and typically participate in a routing 365 protocol over enterprise-interior interfaces to discover routes that 366 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 367 Border Routers (EBRs) are EIRs that connect edge networks and/or join 368 multiple enterprises together, while Enterprise Border Gateways 369 (EBGs) are EBRs that either directly or indirectly connect 370 enterprises to provider networks. A "default mapper" is a special 371 case of an EBG that performs all EBG services except forwarding 372 packets to provider networks. 374 An enterprise may be as simple as a small collection of enterprise 375 routers (and their attached edge networks); an enterprise may also 376 contain other enterprises and/or be a subnetwork of a larger 377 enterprise. An enterprise may further encompass a set of branch 378 offices and/or nomadic hosts connected to a home office over one or 379 several service providers, e.g., through Virtual Private Network 380 (VPN) tunnels. 382 Enterprises that comprise link types with sufficiently similar 383 properties (e.g., Layer-2 (L2) address formats, maximum transmission 384 units (MTUs), etc.) can configure a sub-IP layer routing service such 385 that IP sees the enterprise as an ordinary shared link the same as 386 for a (bridged) campus LAN. In that case, a single IP hop is 387 sufficient to traverse the enterprise without IP layer encapsulation. 389 Enterprises that comprise link types with diverse properties and/or 390 configure multiple IP subnets must also provide a routing service 391 that operates as an IP layer mechanism. In that case, multiple IP 392 hops may be necessary to traverse the enterprise such that specific 393 autoconfiguration procedures are necessary to avoid multilink subnet 394 issues [RFC4903]. In particular, we describe herein the use of IP- 395 in-IP encapsulation to span the enterprise in a single (inner) IP hop 396 in order to avoid the multilink subnet issues that arise when 397 enterprise-interior interfaces are used directly by applications. 399 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 400 both a host function and router function. The host function supports 401 global-scoped communications over any of the enterprise router's non- 402 enterprise-interior interfaces according to the weak end system model 403 [RFC1122] and also supports enterprise-local-scoped communications 404 over its enterprise-interior interfaces. The router function engages 405 in the enterprise-interior routing protocol, connects any of the 406 enterprise router's edge networks to the enterprise and may also 407 connect the enterprise to provider networks (see: Figure 1). 409 In addition to other interface types, VET nodes configure VET 410 interfaces that view all other VET nodes in an enterprise as single- 411 hop neighbors, where the enterprise can also appear as a single IP 412 hop within another enterprise. VET nodes configure a separate VET 413 interface for each distinct enterprise to which they connect, and 414 discover a list of EBRs for each VET interface that can be used for 415 forwarding packets to off-enterprise destinations. The following 416 sections present the Virtual Enterprise Traversal approach. 418 4. Autoconfiguration 420 EIRs, EBRs, EBGs, and VET hosts configure themselves for operation as 421 specified in the following subsections: 423 4.1. Enterprise Interior Router (EIR) Autoconfiguration 425 EIRs configure enterprise-interior interfaces and engage in routing 426 protocols over those interfaces. 428 When an EIR joins an enterprise, it first configures a unique IPv6 429 link-local address on each enterprise-interior interface that 430 requires an IPv6 link-local capability and an IPv4 link-local address 431 on each enterprise-interior interface that requires an IPv4 link- 432 local capability. IPv6 link-local address generation mechanisms that 433 provide sufficient uniqueness include Cryptographically Generated 434 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 435 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 436 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 437 provide an IPv4 link-local address generation capability. 439 Next, the EIR configures an Enterprise Local Address (ELA) of the 440 outer IP protocol version on each of its enterprise-interior 441 interfaces and engages in any routing protocols on those interfaces. 442 The EIR can configure an ELA via explicit management, DHCP 443 autoconfiguration, pseudo-random self-generation from a suitably 444 large address pool, or through an alternate autoconfiguration 445 mechanism. In some enterprise use cases (e.g., highly dynamic 446 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 447 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 448 issues. 450 EIRs that configure ELAs using DHCP may require relay support from 451 other EIRs within the enterprise; the EIR can alternatively configure 452 both a DHCP client and relay that are connected, e.g., via a pair of 453 back-to-back connected ethernet interfaces, a tun/tap interface, a 454 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 455 do not already know the ELA of a server relay requests to the 456 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 457 relays that do not already know the ELA of a server relay requests to 458 the site-scoped IPv4 multicast group address 'All_DHCPv4_Servers' 459 (see: Section 6). DHCPv4 servers that delegate ELAs join the 460 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 461 received for that group. 463 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 464 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 465 generation of ELAs for IPv4 can be from a large IPv4 private address 466 range (e.g., [RFC1918]). When self-generation is used alone, the EIR 467 must continuously monitor the ELAs for uniqueness, e.g., by 468 monitoring the routing protocol, but care must be taken in the 469 interaction of this monitoring with existing mechanisms. 471 A combined approach using both DHCP and self-generation is also 472 possible in which the EIR first self-generates a temporary ELA used 473 only for the purpose of procuring an actual ELA taken from a disjoint 474 addressing range. The EIR then assigns the temporary ELA to an 475 enterprise-interior interface, engages in the routing protocol and 476 performs a DHCP client/relay exchange using the temporary ELA as the 477 address of the relay. When the DHCP server delegates an actual ELA, 478 the EIR abandons the temporary ELA, assigns the actual ELA to the 479 enterprise-interior interface and re-engages in the routing protocol. 481 4.2. Enterprise Border Router (EBR) Autoconfiguration 483 EBRs are EIRs that configure VET interfaces over distinct sets of 484 underlying enterprise-interior interfaces; an EBR can connect to 485 multiple enterprises, in which case it would configure multiple VET 486 interfaces. EBRs perform the following autoconfiguration operations: 488 4.2.1. VET Interface Autoconfiguration 490 VET interface autoconfiguration entails: 1) interface initialization, 491 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 492 address autoconfiguration. These functions are specified in the 493 following sections: 495 4.2.1.1. Interface Initialization 497 EBRs configure a VET interface over a set of underlying enterprise- 498 interior interfaces belonging to the same enterprise, where the VET 499 interface presents a Non-Broadcast, Multiple Access (NBMA) 500 abstraction in which all EBRs in the enterprise appear as single hop 501 neighbors through the use of IP-in-IP encapsulation. 503 When IPv6 and IPv4 are used as the inner/outer protocols 504 (respectively), the EBR autoconfigures an ISATAP link-local address 505 ([RFC5214], Section 6.2) on the VET interface to support packet 506 forwarding and operation of the IPv6 neighbor discovery protocol. 507 The ISATAP link-local address embeds an IPv4 ELA assigned to an 508 underlying enterprise-interior interface, and need not be checked for 509 uniqueness since the IPv4 ELA itself was already checked (see: 510 Section 4.1). Link-local address configuration for other inner/outer 511 IP protocol combinations is through administrative configuration or 512 through an unspecified alternate method. 514 After the EBR configures a VET interface, it can communicate with 515 other VET nodes as single-hop neighbors from the viewpoint of the 516 inner IP protocol. 518 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 519 Identification 521 The EBR next discovers a list of EBGs for each of its VET interfaces. 522 The list can be discovered through information conveyed in the 523 routing protocol and/or through the Potential Router List (PRL) 524 discovery mechanisms outlined in ([RFC5214], Section 8.3.2). In 525 multicast-capable enterprises, they can also listen for 526 advertisements on the 'rasadv' [RASADV] IPv4 multicast group address. 528 In particular, whether or not routing information is available the 529 EBR can discover the list of EBGs in the PRL by resolving an 530 identifying name for the PRL ('PRLNAME') using an enterprise local 531 name resolution service (e.g., an enterprise-local DNS service, LLMNR 532 [RFC4759], etc.). 'PRLNAME' is formed as 'hostname.domainname', 533 where 'hostname' is an enterprise-specific name string and 534 'domainname' is an enterprise-specific DNS suffix when such a suffix 535 is available. 537 The EBR discovers 'PRLNAME' through manual configuration, a DHCP 538 option, 'rasadv' protocol advertisements, link-layer information 539 (e.g., an IEEE 802.11 SSID) or through some other means specific to 540 the enterprise. In the absence of other information, the EBR sets 541 the 'hostname' component of 'PRLNAME' to "isatap" and sets the 542 'domainname' component only if an enterprise-specifc DNS suffix 543 "example.com" is known (e.g., as "isatap.example.com"). 545 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 546 resolving 'PRLNAME' to a list of IPv4 addresses through a name 547 service lookup. 'PRLNAME' as well as the ELAs of EBGs and/or the IP 548 prefixes they aggregate serve as an identifier for the enterprise. 550 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration 552 EBRs can acquire Provider-Aggregated (PA) prefixes through 553 autoconfiguration exchanges with EBGs over VET interfaces. When IPv4 554 is used as the inner IP protocol, the EBR acquires PA prefixes via an 555 unspecified automated IPv4 prefix delegation exchange, explicit 556 management, etc. 558 When IPv6 is used as the inner IP protocol, the EBR acquires PA 559 prefixes via IPv6 Neighbor Discovery and DHCPv6 Prefix Delegation 560 exchanges. In particular, the EBR (acting as a requesting router) 561 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 562 obtain PA IPv6 prefixes from the server (acting as a delegating 563 router). 565 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 566 exchange [RFC3315]. For example, to perform the 2-message exchange 567 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 568 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 569 relay (see: Section 4.1). The relay then forwards the message over 570 the VET interface to the EBG. The forwarded Solicit message will 571 elicit a reply from the server containing PA IPv6 prefix delegations. 573 The EBR can propose a specific prefix to the DHCPv6 server per 574 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 575 available. The server will check the proposed prefix for consistency 576 and uniqueness, then return it in the reply to the EBR if it was able 577 to perform the delegation. 579 After the EBR receives PA prefix delegations, it can provision the 580 prefixes on its enterprise-edge interfaces as well as on other VET 581 interfaces for which it is configured as an EBG. 583 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration 585 Independent of any PA prefixes, EBRs can acquire and use Provider- 586 Independent (PI) prefixes that are either delegated by a registration 587 authority or self-configured by the EBR 588 [RFC4193][I-D.ietf-ipv6-ula-central]). 590 When an EBR acquires a PI prefix, it must also obtain credentials 591 (e.g., from a certification authority) that it can use to prove 592 prefix ownership through Secure Neighbor Discovery (SEND) [RFC3971] 593 messaging. 595 The minimum-sized PI prefix that an EBR may acquire is a /56. 597 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 599 EBGs are EBRs that connect child enterprises to a provider network 600 via ordinay provider-edge interfaces and/or VET interfaces configured 601 over parent enterprises. EBGs autoconfigure provider-edge interfaces 602 in a manner that is specific to their provider connections, and 603 autoconfigure VET interfaces as specified in Section 4.2.1. EBGs 604 that support PA prefix delegation also configure a DHCP relay/server. 606 For each VET interface on which it is configured as an EBG, the EBG 607 must arrange to add its enterprise-interior interface addresses 608 (i.e., its ELAs) to the PRL (see: Section 4.2.1.2), and must maintain 609 these resource records in accordance with ([RFC5214], Section 9). In 610 particular, for each such VET interface the EBG adds its ELAs to name 611 service resource records for 'PRLNAME'. 613 4.4. VET Host Autoconfiguration 615 Nodes that cannot be attached via an EBR's enterprise-edge interface 616 (e.g., nomadic laptops that connect to a home office via a Virtual 617 Private Network (VPN)) can instead be configured for operation as a 618 simple host connected to the VET interface. Such VET hosts perform 619 the same VET interface autoconfiguration procedures as specified for 620 EBRs in Section 4.2.1, but they configure their VET interfaces as 621 host interfaces (and not router interfaces). VET hosts can then send 622 packets to other hosts on the VET interface, or to off-enterprise 623 destinations via a next-hop EBR. 625 Note that a node may be configured as a host on some VET interfaces 626 and as an EBR/EBG on other VET interfaces. 628 5. Internetworking Operation 630 Following the autoconfiguration procedures specified in Section 4, 631 EIRs, EBRs, EBGs and VET hosts engage in normal internetworking 632 operations as discussed in the following sections: 634 5.1. Routing Protocol Participation 636 Following autoconfiguration, EIRs engage in any routing protocols 637 over their enterprise-interior interfaces and forward outer IP 638 packets within the enterprise as for any ordinary router. 640 EBRs can additionally engage in any inner IP routing protocols over 641 enterprise-edge and provider-edge interfaces, and can use those 642 interfaces for forwarding inner IP packets to off-enterprise 643 destinations. Note that these inner IP routing protocols are 644 separate and distinct from any enterprise-interior routing protocols. 646 5.2. PA Prefix Maintenance 648 When an EBR uses DHCP prefix delegation to obtain PA prefixes via an 649 EBG, the DHCP server ensures that the delegations are unique and that 650 the EBG's router function will forward IP packets over the VET 651 interface to the correct EBR. 653 The DHCP prefix delegations remain active as long as the EBR 654 continues to issue renewals over the VET interface before lease 655 lifetimes expire. The lease lifetime also keeps the delegation state 656 active even if communications between the EBR and DHCP server are 657 disrupted for a period of time (e.g., due to an enterprise network 658 partition) before being reestablished (e.g., due to an enterprise 659 network merge). 661 Additionnally, ordinary requesting routers on enterprise edge 662 interfaces can maintain PA prefix delegations exactly as specified in 663 [RFC3633]. 665 5.3. IPv6 EBG Discovery 667 EBGs follow the router and prefix discovery procedures specified in 668 ([RFC5214], Section 8.2). They send solicited RAs over VET 669 interfaces for which they are configured as gateways with default 670 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 671 with any other required options/parameters. EBGs must set the 'M' 672 flag in RAs to 0, since the use of DHCPv6 for address configuration 673 on VET interfaces is undefined. EBGs can also include PIOs with the 674 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 675 of an aggregated prefix from which it is willing to delegate longer 676 PA prefixes. 678 VET nodes follow the router and prefix discovery procedures specified 679 in ([RFC5214], Section 8.3). They discover EBGs within the 680 enterprise as specified in Section 4.2.1.2, then perform SEND- 681 protected RS/RA exchanges with the EBGs to establish and maintain 682 default routes. In particular the VET node sends SEND-protected 683 unicast RS messages to EBGs over its VET interface(s) to receive 684 SEND-protected RAs. When the VET node receives an RA, it configures 685 a default route based on the Router Lifetime. If the RA contains 686 Prefix Information Options (PIOs) with the 'A' and 'L' bits set to 1, 687 the VET node also autoconfigures IPv6 addresses from the advertised 688 prefixes using SLAAC and assigns them to the VET interface. 689 Thereafter, the VET accepts packets that are fowarded by EBGs for 690 which they have current default routing information. 692 5.4. IPv6 PI Prefix Registration 694 When an EBR discovers next-hop EBGs for the enterprise, it must 695 register its PI prefixes by sending SEND-protected RAs to a set of 696 one or more EBGs with Route information Options (RIOs) [RFC4191] that 697 contain the EBR's PI prefixes. Each RA must include the ELA of an 698 EBG as the outer IP destination address and an ISATAP link-local 699 address derived from the ELA as the inner IP destination address. 700 The RAs must also include a CGA link-local inner source address along 701 with a SEND signature that can be used to validate the CGA plus any 702 certificates needed to prove ownership of the PI prefixes. The EBR 703 additionally tracks the set of EBGs that it sends RAs to so that it 704 can send subsequent RAs to the same set. 706 When the EBG receives the RA, it uses SEND to authenticate the 707 message; if the authentication fails, the EBG discards the RA. 708 Otherwise, the EBG installs the PI prefixes with their respective 709 lifetimes in its Forwarding Information Base (FIB) and configures 710 them for both ingress filtering [RFC3704] and forwarding purposes. 711 In particular, the EBG configures the FIB entries as ingress filter 712 rules to accept packets received on the VET interface with a source 713 address taken from the PI prefixes. It also configures the FIB 714 entries to forward packets received on other interfaces with a 715 destination address taken from the PI prefixes to the EBR that 716 registered the prefixes on the VET interface. 718 The EBG then publishes the PI prefixes in the enterprise mapping 719 system. For enterprises that are managed under a cooperative 720 administrative authority, the EBG publishes the PI prefixes in the 721 enterprise-local name service [RFC1035] using a secure automated name 722 service update mechanism [RFC3007]. For VET interfaces configured 723 over enterprises that are managed in a distributed fashion, EBG 724 should instead respond directly to LLMNR [RFC4759] name service 725 queries. 727 The EBG publishes each /56 prefix taken from the PI prefixes as a 728 seperate FQDN that consists of a sequence of 14 nibbles in reverse 729 order (i.e., the same as in [RFC3596], Section 2.5) followed by the 730 string 'PRLNAME'. For example, when 'PRLNAME' is 731 "isatap.example.com", the EBG publishes the prefix '2001:DB8::/56' 732 as: 733 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. The EBG includes 734 the inner IPv6 CGA source address (e.g., in a DNS AAAA record) and 735 the outer IPv4 source address of the RA (e.g., in a DNS A resource 736 record) in each prefix publication. If the prefix was already 737 installed in the name service, the EBG instead adds the outer IPv4 738 source address (e.g., in an additional DNS AAAA record) to the pre- 739 existing publication. 741 After the EBG authenticates the RA and publishes the PI prefixes, it 742 next acts as an EBR on the VET interfaces configured over any of its 743 provider enterprises and "relays" the RA to the default routers 744 (i.e., EBGs) on those interfaces. The EBR tracks the set of EBGs 745 that it relays the RA to, and should relay subsequent RAs to the same 746 set of EBGs. Each relayed RA is formatted exactly as for the 747 original RA, except that it uses the EBR's own CGA as the inner 748 source address and an ELA taken from the VET interface as the outer 749 IP source address. The RA authentication and PI prefix publication 750 recurses in this fashion and ends when a default mapping service for 751 the interdomain routing core is reached. (In the case of the global 752 Internet interdomain routing core, the 'PRLNAME' for the default 753 mapping service is "isatap.net".) 755 After the initial PI prefix registration, the EBR that owns the 756 prefix(es) must periodically send additional RAs to its set of EBGs 757 to refresh prefix lifetimes. As long as the EBGs have retained 758 sufficient state from a previous RA authentication as a means for 759 detecting spoofed packets, however, authentication of these 760 "keepalive" RAs is not required. 762 This procedure has a close analogy in the Teredo method of 763 maintaining state in network middleboxes through the periodic 764 transmission of "bubbles" [RFC4380]. 766 5.5. IPv6 Next-Hop EBR Discovery 768 VET nodes discover destination-specific next-hop EBRs within the 769 enterprise by querying the name service for the /56 IPv6 PI prefix 770 taken from a packet's destination address. For example, for the IPv6 771 destination address '2001:DB8:1:2::1' and 'PRLNAME' 772 "isatap.example.com" the VET node can lookup the domain name: 773 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. If the name 774 service lookup succeeds, it will return an IPv6 CGA address (e.g., in 775 a DNS AAAA record) and IPv4 addresses (e.g., in DNS A records) that 776 correspond to the ELAs assigned to enterprise interior interfaces of 777 next-hop EBRs. 779 When a VET node forwards a packet to an EBG that has a mapping for 780 the destination, the EBG forwards the packet to a next-hop EBR on the 781 VET interface and returns an ICMPv6 Redirect [RFC4861]. If the 782 packet's source address is on-link on the VET interface, the EBG 783 returns an ordinary "router-to-host" redirect with the source address 784 of the packet as its destination. If the packet's source address is 785 not on-link, the EBG instead returns a "router-to-router" redirect 786 with the link-local ISATAP address of the previous-hop EBR as its 787 destination. The EBG also includes in the redirect one or more link- 788 layer address options that contain the IPv4 ELA addresses of 789 potential next-hop EBRs, where the target link-layer address options 790 are formatted exactly as specified in [RFC2529]. 792 When a VET host receives an ordinay "router-to-host" redirect, it 793 processes the redirect exacly as specified in [RFC4861], Section 8. 794 When an EBR receives a "router-to-router" redirect, it discovers the 795 IPv4 ELA addresses of potential next-hop EBRs by examining the target 796 link-layer address options included in the redirect. The EBR then 797 installs a FIB entry that contains the /56 prefix of the original 798 packet's destination and the list of IPv4 ELAs of potential next-hop 799 EBRs. The EBR then enables the FIB entry for forwarding to next-hop 800 EBRs but DOES NOT enable it for ingress filtering acceptance of 801 packets from next-hop EBRs (i.e., the forwarding determination is 802 unidirectional). The EBR then sends RAs over the VET interface to 803 one or more of the potential next-hop EBRs with a link-local ISATAP 804 address that embeds a next-hop EBR IPv4 ELA as the destination. The 805 RAs must include the EBR's CGA link-local address as the inner IPv6 806 source address along with a SEND signature. The RAs must also 807 include a Route Information Option (RIO) [RFC4191] that contains the 808 /56 PI prefix of the original packet's source address. 810 When a next-hop EBR receives the RA, it uses SEND to verify the CGA 811 then performs a name service lookup on the prefix in the RIO. If the 812 name service returns the correct CGA and ELA information, the next- 813 hop EBR then installs the prefix in the RIO in its FIB and enables 814 the FIB entry for ingress filtering but DOES NOT enable it for 815 forwarding purposes. 817 After an EBR sends initial RAs following a redirect, it should send 818 periodic RAs to refresh the next-hop EBR's ingress filter prefix 819 lifetimes as long as traffic is flowing. 821 5.6. Forwarding Packets 823 VET nodes forward packets by consulting the FIB to determine a 824 specific EBR/EBG as the next-hop router on a VET interface. When 825 multiple next-hop routers are available, VET nodes can use default 826 router preferences, routing protocol information, traffic engineering 827 configurations, etc. to select the best exit router. When there is 828 no FIB information available, VET nodes can discover the next-hop 829 EBR/EBG through the mechanisms specified in Section 5.3 and 830 Section 5.5. 832 VET interfaces encapsulate inner IP packets in any mid-layer headers 833 followed by an outer IP header according to the specific 834 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 835 next submit the encapsulated packet to the outer IP forwarding engine 836 for transmission on an underlying enterprise-interior interface. 838 For forwarding to next-hop addresses over VET interfaces that use 839 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 840 address (i.e., the IPv4 ELA of the next-hop EBR) through static 841 extraction of the IPv4 address embedded in the next-hop ISATAP 842 address. For other IP-in-IP encapsulations, determination of the 843 outer destination address is through administrative configuration or 844 through an unspecified alternate method. 846 5.7. SEAL Encapsulation 848 VET nodes that do not use IPsec encapsulation should use SEAL 849 encapsulation [I-D.templin-seal] in conjunction with packet 850 forwarding over VET interfaces to accommdate path MTU diversity, to 851 detect source address spoofing, and to monitor next-hop EBR 852 reachability. 854 In terms of security, when a VET node receives an ICMP message, it 855 can confirm that the packet-in-error within the ICMP message 856 corresponds to one of its recently-sent packets by examining the 857 SEAL_ID (i.e., the VET node's sequence number for a specific next-hop 858 EBR). Additionally, a next-hop EBR can track the SEAL_ID in packets 859 received from EBRs for which there is an ingress filter entry and 860 discard packets that have SEAL_ID values outside of the current 861 window. To maintain synchronization, the next-hop EBR resets its 862 cached SEAL_IDs for correspondent EBRs/EBGs whenever it receives a 863 fresh SEND-protected RA. 865 In terms of next-hop reachability, an EBR can set the SEAL 866 "Acknowledgement Requested" bit in messages to receive confirmation 867 that a next-hop EBR is reachable. Setting the "Acknowledgement 868 Requested" bit is also used as the method for maintaining the window 869 of outstanding SEAL_ID's. 871 5.8. Generating Errors 873 When an EBR receives a packet for which it has no longest-prefix- 874 match FIB entry for the source (i.e., an ingress filter entry), it 875 drops the packet and returns a SEAL-encapsulated ICMPv6 [RFC4443] 876 "Destination Unreachable; Source address failed ingress/egress 877 policy" message to the previous hop EBR subject to rate limiting. 879 When an EBR/EBG receives a packet for which there is no longest- 880 prefix-match FIB entry for the destination, it drops the packet and 881 returns a SEAL-encapsulated ICMPv6 "Destination Unreachable; No route 882 to destination" message to the previous hop EBR subject to rate 883 limiting. Additionally, when a VET node that is configured as an 884 ordinary EBR (i.e. and not an EBG) on the VET interface receives a 885 packet for which there is no longest-prefix-match FIB entry for the 886 destination that is more-specific than ::/0 (i.e., default), it must 887 drop the packet and return an ICMPv6 unreachable in order to prevent 888 looping. 890 5.9. Processing Errors 892 When an EBR receives an ICMPv6 "Destination Unreachable; Source 893 address failed ingress/egress policy" message from a next-hop EBR, it 894 should mark the longest-prefix-match FIB entry for the destination as 895 "forwarding suspended" for the ELA taken from the source address of 896 the ICMPv6 message. The EBR should then allow subsequent packets to 897 flow through different ELAs associated with the FIB entry until it 898 forwards a new SEND-protected RA to the suspended ELA. If the EBR 899 receives excessive ICMPv6 ingress policy errors through multiple ELAs 900 associated with the same FIB entry, it should delete the FIB entry 901 and allow subsequent packets to flow through a different route. 903 When a VET node receives an ICMPv6 "Destination Unreachable; No route 904 to destination" message from a next-hop EBR, and the node has a 905 longest-prefix-match FIB entry for the original packet's destination 906 that is more-specific than ::/0, the node discards the message and 907 deletes the FIB entry (i.e., to support graceful handling of mobility 908 events). If there is no FIB entry that is more-specific than ::/0, 909 the VET node instead forwards the ICMPv6 message to the source 910 address of the original packet, i.e., to inform the original source 911 that there is indeed no route to the final destination. 913 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 914 Unreachable; net / host unreachable" messages from an EIR indicating 915 that the path to a VET neighbor may be failing, but it should first 916 check the SEAL_ID or IPsec sequence number in the message before 917 accepting them. If a VET node detects that the path to a next-hop 918 EBR is failing, it should mark the longest-prefix-match FIB entry for 919 the destination as "forwarding suspended" for the ELA destination 920 address of the ICMPv4 packet-in-error. If the EBR receives excessive 921 ICMPv4 unreachable errors through multiple ELAs associated with the 922 same FIB entry, it should delete the FIB entry and allow subsequent 923 packets to flow through a different route. 925 5.10. Mobility and Multihoming Considerations 927 EBRs can retain their PI prefixes as they travel between distinct 928 enterprise networks as long as they register the prefixes with new 929 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 930 departure. Prefix registration with new EBGs is coordinated exactly 931 as specified in Section 5.4; prefix withdrawl from old EBGs is simply 932 through re-announcing the PI prefixes with zero lifetimes. 934 Since EBRs can move about independently of one another, stale FIB 935 entry state may be left in VET nodes when a neighboring EBR departs. 936 Additionally, EBRs can lose state for various reasons, e.g., power 937 failure, machine reboot, etc. For this reason, EBRs are advised to 938 set relatively short PI prefix lifetimes in RIO options, and to send 939 additional RAs to refresh lifetimes before they expire. (EBRs should 940 place conservative limits on the RAs they send to reduce congestion, 941 however.) 943 EBRs may register their PI prefixes with multiple EBGs for 944 multihoming purposes. EBRs should only forward packets via EBGs with 945 which it has registered its PI prefixes, since other EBGs will simply 946 drop the packets return ICMPv6 "Destination Unreachable; Source 947 address failed ingress/egress policy" messages subject to rate 948 limiting. 950 EBRs can also act as delegating routers to sub-delegate portions of 951 their PI prefixes to requesting routers on their enterprise edge 952 interfaces and on VET interfaces for which they are configured as 953 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 954 become the PA prefixes for downstream-dependent nodes. Downstream- 955 dependent nodes that travel with a mobile provider EBR can continue 956 to use addresses configured from PA prefixes; downstream-dependent 957 nodes that move away from their provider EBR must perform address/ 958 prefix renumbering when they assocate with a new provider. 960 5.11. Enterprise-Local Communications 962 When permitted by policy, end systems that configure the endpoints of 963 enterprise-local communications can avoid VET interface encapsulation 964 by directly invoking the outer IP protocol using ELAs assigned to 965 their enterprise-interior interfaces. For example, when the outer 966 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 967 communications over their enterprise-interior interfaces without 968 using encapsulation. 970 5.12. Multicast 972 In multicast-capable deployments, EIRs provide an enterprise-wide 973 multicasting service such as Simplified Multicast Forwarding (SMF) 974 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 975 that outer IP multicast messages of site- or greater scope will be 976 propagated across the enterprise. For such deployments, VET nodes 977 can also provide an inner IP multicast/broadcast capability over 978 their VET interfaces through mapping of the inner IP multicast 979 address space to the outer IP multicast address space. 981 VET nodes encapsulate inner IP multicast messages sent over the VET 982 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 983 outer IP header with a site-scoped outer IP multicast address as the 984 destination. For the case of IPv6 and IPv4 as the inner/outer 985 protocols (respectively), [RFC2529] provides mappings from the IPv6 986 multicast address space to the IPv4 multicast address space. For 987 other IP-in-IP encapsulations, mappings are established through 988 administrative configuration or through an unspecified alternate 989 method. 991 For multicast-capable enterprises, use of the inner IP multicast 992 service for operating the ND protocol over the VET interface is 993 available but should be used sparingly to minimize enterprise-wide 994 flooding. 996 5.13. Service Discovery 998 VET nodes can peform enterprise-wide service discovery using a 999 suitable name-to-address resolution service. Examples of flooding- 1000 based services include the use of LLMNR [RFC4759] over the VET 1001 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1002 underlying enterprise-interior interface. More scalable and 1003 efficient service discovery mechanisms are for further study. 1005 5.14. Enterprise Partitioning 1007 EBGs can physically partition an enterprise by configuring multiple 1008 VET interfaces over multiple distinct sets of underlying interfaces. 1009 In that case, each partition (i.e., each VET interface) must 1010 configure its own distinct 'PRLNAME' (e.g., 1011 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1013 EBGs can logically partition an enterprise using a single VET 1014 interface by sending RAs with PIOs containing different IPv6 PA 1015 prefixes to group nodes into different logical partitions. EBGs can 1016 identify partitions, e.g., by examining IPv4 ELA prefixes, observing 1017 the interfaces over which RSs are received, etc. In that case, a 1018 single 'PRLNAME' can cover all partitions. 1020 6. IANA Considerations 1022 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1023 DHCPv4 server discovery is requested. The allocation should be taken 1024 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1025 the IANA 'multicast-addresses' registry. 1027 7. Security Considerations 1029 Security considerations for MANETs are found in [RFC2501]. 1031 Security considerations with tunneling that apply also to VET are 1032 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1033 that the outer IP source address of a packet received on a VET 1034 interface is correct for the inner IP source address using the 1035 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1036 the ingress filtering mechanisms specified in this document. 1038 SEND [RFC3971] and SEAL Section 5.7 provide additional securing 1039 mitigations to defeat rogue routers and source address spoofing. 1041 Rogue routers can send bogus RA messages with spoofed ELA source 1042 addresses that can consume network resources and cause EBGs to 1043 perform extra work. Nonetheless, EBGs should not "blacklist" such 1044 ELAs, as that may result in a denial of service to the ELAs' 1045 legitimate owners. 1047 8. Related Work 1049 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1050 automatic tunneling in [RFC2529]. This concept was later called: 1051 "Virtual Ethernet" and investigated by Quang Nguyen under the 1052 guidance of Dr. Lixia Zhang. 1054 Telcordia has proposed DHCP-related solutions for MANETs through the 1055 CECOM MOSAIC program. 1057 The Naval Research Lab (NRL) Information Technology Division uses 1058 DHCP in their MANET research testbeds. 1060 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 1061 pertaining to tunneling mechanisms. 1063 An automated IPv4 prefix delegation mechanism is proposed in 1064 [I-D.ietf-dhc-subnet-alloc]. 1066 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1068 Various proposals within the IETF have suggested similar mechanisms. 1070 9. Acknowledgements 1072 The following individuals gave direct and/or indirect input that was 1073 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Brian 1074 Carpenter, James Bound, Thomas Clausen, Joel Halpern, Bob Hinden, 1075 Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David 1076 Meyer, Thomas Narten, Pekka Nikander, Alexandru Petrescu, John 1077 Spence, Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela Vanderveen, 1078 Lixia Zhang and others in the IETF AUTOCONF and MANET working groups. 1079 Many others have provided guidance over the course of many years. 1081 10. Contributors 1083 The following individuals have contributed to this document: 1085 Eric Fleischman (eric.fleischman@boeing.com) 1086 Thomas Henderson (thomas.r.henderson@boeing.com) 1087 Steven Russert (steven.w.russert@boeing.com) 1088 Seung Yi (seung.yi@boeing.com) 1090 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1091 of the document. 1093 11. References 1095 11.1. Normative References 1097 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1098 September 1981. 1100 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1101 RFC 792, September 1981. 1103 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1104 converting network protocol addresses to 48.bit Ethernet 1105 address for transmission on Ethernet hardware", STD 37, 1106 RFC 826, November 1982. 1108 [RFC1035] Mockapetris, P., "Domain names - implementation and 1109 specification", STD 13, RFC 1035, November 1987. 1111 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1112 RFC 2131, March 1997. 1114 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1115 (IPv6) Specification", RFC 2460, December 1998. 1117 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1118 Update", RFC 3007, November 2000. 1120 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1121 and M. Carney, "Dynamic Host Configuration Protocol for 1122 IPv6 (DHCPv6)", RFC 3315, July 2003. 1124 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1125 "DNS Extensions to Support IP Version 6", RFC 3596, 1126 October 2003. 1128 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1129 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1130 December 2003. 1132 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1133 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1135 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1136 RFC 3972, March 2005. 1138 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1139 More-Specific Routes", RFC 4191, November 2005. 1141 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1142 Architecture", RFC 4291, February 2006. 1144 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1145 Message Protocol (ICMPv6) for the Internet Protocol 1146 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1148 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1149 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1150 September 2007. 1152 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1153 Address Autoconfiguration", RFC 4862, September 2007. 1155 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1156 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1157 March 2008. 1159 11.2. Informative References 1161 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1162 Switching Networks", May 1974. 1164 [I-D.cheshire-dnsext-multicastdns] 1165 Cheshire, S. and M. Krochmal, "Multicast DNS", 1166 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1167 September 2008. 1169 [I-D.clausen-manet-linktype] 1170 Clausen, T., "The MANET Link Type", 1171 draft-clausen-manet-linktype-00 (work in progress), 1172 October 2008. 1174 [I-D.ietf-autoconf-manetarch] 1175 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1176 Network Architecture", draft-ietf-autoconf-manetarch-07 1177 (work in progress), November 2007. 1179 [I-D.ietf-dhc-subnet-alloc] 1180 Johnson, R., "Subnet Allocation Option", 1181 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1182 July 2008. 1184 [I-D.ietf-ipv6-ula-central] 1185 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1186 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1187 progress), June 2007. 1189 [I-D.ietf-manet-smf] 1190 Macker, J. and S. Team, "Simplified Multicast Forwarding 1191 for MANET", draft-ietf-manet-smf-08 (work in progress), 1192 November 2008. 1194 [I-D.ietf-v6ops-tunnel-security-concerns] 1195 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1196 Concerns With IP Tunneling", 1197 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1198 progress), October 2008. 1200 [I-D.jen-apt] 1201 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1202 L. Zhang, "APT: A Practical Transit Mapping Service", 1203 draft-jen-apt-01 (work in progress), November 2007. 1205 [I-D.templin-seal] 1206 Templin, F., "The Subnetwork Encapsulation and Adaptation 1207 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1208 August 2008. 1210 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1211 July 1978. 1213 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1214 Protocol Specification", October 2008. 1216 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1217 Communication Layers", STD 3, RFC 1122, October 1989. 1219 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1220 Routing and Addressing Architecture", RFC 1753, 1221 December 1994. 1223 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1224 E. Lear, "Address Allocation for Private Internets", 1225 BCP 5, RFC 1918, February 1996. 1227 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1228 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1230 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1231 (MANET): Routing Protocol Performance Issues and 1232 Evaluation Considerations", RFC 2501, January 1999. 1234 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1235 Domains without Explicit Tunnels", RFC 2529, March 1999. 1237 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1238 February 2000. 1240 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1241 via IPv4 Clouds", RFC 3056, February 2001. 1243 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1244 Networks", BCP 84, RFC 3704, March 2004. 1246 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1247 RFC 3753, June 2004. 1249 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1250 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1251 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1252 RFC 3819, July 2004. 1254 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1255 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1256 May 2005. 1258 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1259 Addresses", RFC 4193, October 2005. 1261 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1262 Internet Protocol", RFC 4301, December 2005. 1264 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1265 Network Address Translations (NATs)", RFC 4380, 1266 February 2006. 1268 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1269 Indicator Parameter for the "tel" URI", RFC 4759, 1270 December 2006. 1272 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1273 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1274 Focus", RFC 4852, April 2007. 1276 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1277 June 2007. 1279 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1280 Extensions for Stateless Address Autoconfiguration in 1281 IPv6", RFC 4941, September 2007. 1283 Appendix A. Duplicate Address Detection (DAD) Considerations 1285 A-priori uniqueness determination (also known as "pre-service DAD") 1286 for an ELA assigned on an enterprise-interior interface would require 1287 either flooding the entire enterprise or somehow discovering a link 1288 in the enterprise on which a node that configures a duplicate address 1289 is attached and performing a localized DAD exchange on that link. 1290 But, the control message overhead for such an enterprise-wide DAD 1291 would be substantial and prone to false-negatives due to packet loss 1292 and intermittent connectivity. An alternative to pre-service DAD is 1293 to autoconfigure pseudo-random ELAs on enterprise-interior interfaces 1294 and employ a passive in-service DAD (e.g., one that monitors routing 1295 protocol messages for duplicate assignments). 1297 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1298 CGAs, IPv6 privacy addresses, etc. with very small probability of 1299 collision. Pseudo-random IPv4 ELAs can be generated through random 1300 assignment from a suitably large IPv4 prefix space. 1302 Consistent operational practices can assure uniqueness for EBG- 1303 aggregated addresses/prefixes, while statistical properties for 1304 pseudo-random address self-generation can assure uniqueness for the 1305 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 1306 ELA delegation authority should be used when available, while a 1307 passive in-service DAD mechanism should be used to detect ELA 1308 duplications when there is no ELA delegation authority. 1310 Appendix B. Change Log 1312 (Note to RFC editor - this section to be removed before publication 1313 as an RFC.) 1315 Changes from -27 to 28: 1317 o Introduced concept of a default mapper. 1319 Changes from -26 to 27: 1321 o Introduced new model for PI prefix management. 1323 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1324 "isado"?) 1326 Changes from -25 to 26: 1328 o Clarifications on Router Discovery and Ingress FIltering. 1330 o Mechanisms for detecting locator liveness 1332 o Mechanisms for avoiding state synchonization requirements. 1334 Changes from -23 to 24: 1336 o Clarifications on router discovery. 1338 Changes from -22 to 23: 1340 o Clarifications on prefix mapping. 1342 Changes from -21 to 22: 1344 o Using SEAL to secure VET 1346 Changes from -20 to 21: 1348 o Enterprise partitioning. 1350 o Mapping and name service management. 1352 Changes from -18 to 20: 1354 o Added support for simple hosts. 1356 o Added EBG name service maintenace procedures 1358 o Added router and prefix maintenace procedures 1360 Changes from -17 to 18: 1362 o adjusted section headings to group autoconf operations under EIR/ 1363 EBR/EBG. 1365 o clarified M/O bits 1367 o clarified EBG roles 1369 Changes from -15 to 17: 1371 o title change to "Virtual Enterprise Traversal (VET)". 1373 o changed document focus from MANET-centric to the much-broader 1374 Enterprise-centric, where "Enterprise" is understood to also cover 1375 a wide range of MANET types. 1377 Changes from -14 to 15: 1379 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1381 o Address review comments 1383 Changes from -12 to 14: 1385 o title change to "The MANET Virtual Ethernet Abstraction". 1387 o Minor section rearrangement. 1389 o Clartifications on portable and self-configured prefixes. 1391 o Clarifications on DHCPv6 prefix delegation procedures. 1393 Changes from -11 to 12: 1395 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1397 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1398 delegation mechanism. 1400 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1402 o fixed editorials based on comments received. 1404 Changes from -10 to 11: 1406 o removed the transparent/opaque VET portal abstractions. 1408 o removed routing header as an option for MANET exit router 1409 selection. 1411 o included IPv6 SLAAC as an endorsed address configuration mechanism 1412 for the VET interface. 1414 Changes from -08 to -09: 1416 o Introduced the term "VET". 1418 o Changed address delegation language to speak of "MNBR-aggregated" 1419 instead of global/local. 1421 o Updated figures 1-3. 1423 o Explained why a MANET interface is "neutral". 1425 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1426 DHCPv4 servers; not relays. 1428 Changes from -07 to -08: 1430 o changed terms "unenhanced" and "enhanced" to "transparent" and 1431 "opaque". 1433 o revised MANET Router diagram. 1435 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1436 interface. 1438 o changed abbreviations to "MNR" and "MNBR". 1440 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1442 o rearranged Section 3.1. 1444 o various minor text cleanups 1446 Changes from -06 to -07: 1448 o added MANET Router diagram. 1450 o added new references 1452 o various minor text cleanups 1454 Changed from -05 to -06: 1456 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1458 o minor changes to preserve generality 1460 Changed from -04 to -05: 1462 o introduced conceptual "virtual ethernet" model. 1464 o support "raw" and "cooked" modes as equivalent access methods on 1465 the virutal ethernet. 1467 Changed from -03 to -04: 1469 o introduced conceptual "imaginary shared link" as a representation 1470 for a MANET. 1472 o discussion of autonomous system and site abstractions for MANETs 1474 o discussion of autoconfiguration of CGAs 1476 o new appendix on IPv6 StateLess Address AutoConfiguration 1478 Changes from -02 to -03: 1480 o updated terminology based on RFC2461 "asymmetric reachability" 1481 link type; IETF67 MANET Autoconf wg discussions. 1483 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1484 Address Detection 1486 o relaxed DHCP server deployment considerations allow DHCP servers 1487 within the MANET itself 1489 Changes from -01 to -02: 1491 o minor updates for consistency with recent developments 1493 Changes from -00 to -01: 1495 o new text on DHCPv6 prefix delegation and multilink subnet 1496 considerations. 1498 o various editorial changes 1500 Author's Address 1502 Fred L. Templin (editor) 1503 Boeing Research and Technology 1504 P.O. Box 3707 MC 7L-49 1505 Seattle, WA 98124 1506 USA 1508 Email: fltemplin@acm.org