idnits 2.17.1 draft-templin-autoconf-dhcp-33.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 (February 4, 2009) is 5554 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 186, but not defined == Unused Reference: 'RFC4291' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1353, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1359, 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 (-05) exists of draft-ietf-csi-proxy-send-00 == 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 (~~), 12 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 February 4, 2009 5 Expires: August 8, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-33.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 August 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 9 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 12 64 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration . . 13 65 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration . . 14 66 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 14 67 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 14 68 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 15 69 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 15 70 5.2. PA Prefix Maintenance . . . . . . . . . . . . . . . . . . 15 71 5.3. IPv6 Border Router Discovery and PI Prefix Maintenance . . 15 72 5.3.1. IPv6 EBG Discovery . . . . . . . . . . . . . . . . . . 15 73 5.3.2. IPv6 PI Prefix Registration . . . . . . . . . . . . . 16 74 5.3.3. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . 18 75 5.4. IPv4 Border Router Discovery and PI Prefix Maintenace . . 19 76 5.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . . 19 77 5.6. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 20 78 5.7. Generating Errors . . . . . . . . . . . . . . . . . . . . 21 79 5.8. Processing Errors . . . . . . . . . . . . . . . . . . . . 21 80 5.9. Mobility and Multihoming Considerations . . . . . . . . . 22 81 5.10. Enterprise-Local Communications . . . . . . . . . . . . . 23 82 5.11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.12. Service Discovery . . . . . . . . . . . . . . . . . . . . 24 84 5.13. Enterprise Partitioning . . . . . . . . . . . . . . . . . 24 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 93 Appendix A. Duplicate Address Detection (DAD) Considerations . . 31 94 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 31 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 97 1. Introduction 99 Enterprise networks [RFC4852] connect routers over various link types 100 (see: [RFC4861], Section 2.2). The term "enterprise network" in this 101 context extends to a wide variety of use cases and deployment 102 scenarios. For example, an "enterprise" can be as small as a SOHO 103 network, as complex as a multi-organizational and/or multi-national 104 corporation, or as large as the global Internet itself. Certain 105 Mobile Ad-hoc Networks (MANETs) [RFC2501] can be considered as a 106 challenging example of an enterprise network, in that their 107 topologies may change dynamically over time and that they may employ 108 little/no active management by a centralized network administrative 109 authority. These specialized characteristics for MANETs require 110 careful consideration, but the same principles apply equally to other 111 enterprise network scenarios. 113 This document specifies a Virtual Enterprise Traversal (VET) 114 abstraction for autoconfiguration and internetworking operation, 115 where addresses of different scopes may be assigned on various types 116 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 117 [RFC2460] are discussed within this context. The use of standard 118 DHCP [RFC2131][RFC3315] and neighbor discovery 119 [RFC0826][RFC1256][RFC4861] mechanisms is assumed unless otherwise 120 specified. 122 Provider-edge Interfaces 123 x x x 124 | | | 125 +--------------------+---+--------+----------+ E 126 | | | | | n 127 | I | | .... | | t 128 | n +---+---+--------+---+ | e 129 | t | +--------+ /| | r 130 | e I x----+ | Host | I /*+------+--< p I 131 | r n | |Function| n|**| | r n 132 | n t | +--------+ t|**| | i t 133 | a e x----+ V e|**+------+--< s e 134 | l r . | E r|**| . | e r 135 | f . | T f|**| . | f 136 | V a . | +--------+ a|**| . | I a 137 | i c . | | Router | c|**| . | n c 138 | r e x----+ |Function| e \*+------+--< t e 139 | t s | +--------+ \| | e s 140 | u +---+---+--------+---+ | r 141 | a | | .... | | i 142 | l | | | | o 143 +--------------------+---+--------+----------+ r 144 | | | 145 x x x 146 Enterprise-edge Interfaces 148 Figure 1: Enterprise Router Architecture 150 Figure 1 above depicts the architectural model for an enterprise 151 router. As shown in the figure, an enterprise router may have a 152 variety of interface types including enterprise-edge, enterprise- 153 interior, provider-edge, internal-virtual, as well as VET interfaces 154 used for encapsulation of inner IP packets within outer IP headers. 155 The different types of interfaces are defined, and the 156 autoconfiguration mechanisms used for each type are specified. This 157 architecture applies equally for MANET routers, in which enterprise- 158 interior interfaces correspond to the wireless multihop radio 159 interfaces typically associated with MANETs. Out of scope for this 160 document is the autoconfiguration of provider interfaces, which must 161 be coordinated in a manner specific to the service provider's 162 network. 164 Enterprise routers must have a means for supporting both Provider- 165 Independent (PI) and Provider-Aggregated (PA) IP prefixes for global- 166 scope communications. This is especially true for enterprise 167 scenarios that involve mobility and multihoming. Ingress filtering 168 for multi-homed sites, adaptation based on authenticated ICMP 169 feedback from on-path routers, effective tunnel path MTU mitigations 170 and routing scaling suppression are also required in many enterprise 171 network scenarios. The VET specification provides a comprehensive 172 solution that addresses these issues and more. 174 VET represents a functional superset of 6over4 [RFC2529] and ISATAP 175 [RFC5214], and further supports additional encapsulations such as 176 IPsec [RFC4301], SEAL [I-D.templin-seal], etc. As a result, VET 177 provides a map-and-encaps architecture using IP-in-IP tunneling based 178 on both forwarding table and mapping service lookups (defined 179 herein). 181 The VET principles can be either directly or indirectly traced to the 182 deliberations of the ROAD group in January 1992, and also to still 183 earlier works including NIMROD [RFC1753], the Catenet model for 184 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 185 the high-level architectural aspects of the ROAD group deliberations 186 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 187 IPNG". 189 VET is related to the present-day activites of the IETF autoconf, 190 dhc, ipv6, manet and v6ops working groups, as well as the IRTF rrg 191 working group. 193 2. Terminology 195 The mechanisms within this document build upon the fundamental 196 principles of IP-within-IP encapsulation. The terms "inner" and 197 "outer" are used to respectively refer to the innermost IP {address, 198 protocol, header, packet, etc.} *before* encapsulation, and the 199 outermost IP {address, protocol, header, packet, etc.} *after* 200 encapsulation. VET also allows for inclusion of "mid-layer" 201 encapsulations between the inner and outer layers, including IPSec 202 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 203 [I-D.templin-seal], etc. 205 The terminology in the normative references apply; the following 206 terms are defined within the scope of this document: 208 subnetwork 209 the same as defined in [RFC3819]. 211 enterprise 212 the same as defined in [RFC4852]. 214 site 215 a logical and/or physical grouping of interfaces that connect a 216 topological area less than or equal to an enterprise in scope. A 217 site within an enterprise can in some sense be considered as an 218 enterprise unto itself. 220 Mobile Ad-hoc Network (MANET) 221 a connected topology of mobile or fixed routers that maintain a 222 routing structure among themselves over dynamic links, where a 223 wide variety of MANETs share common properties with enterprise 224 networks. Characteristics of MANETs are defined in [RFC2501], 225 Section 3. 227 enterprise/site/MANET 228 throughout the remainder of this document, the term "enterprise" 229 is used to collectively refer to any of enterprise/site/MANET, 230 i.e., the VET mechanisms and operational principles apply equally 231 to enterprises, sites and MANETs. 233 enterprise router 234 an Enterprise Interior Router, Enterprise Border Router, or 235 Enterprise Border Gateway. As depicted in Figure 1, an enterprise 236 router comprises a router function, a host function, one or more 237 enterprise-interior interfaces and zero or more internal virtual, 238 enterprise-edge, provider-edge and VET interfaces. 240 Enterprise Interior Router (EIR) 241 a fixed or mobile enterprise router that forwards packets over one 242 or more sets of enterprise-interior interface, where each set 243 connects to a distinct enterprise. 245 Enterprise Border Router (EBR) 246 an EIR that connects edge networks to the enterprise, and/or 247 connects multiple enterprises together. An EBR configures a 248 seperate VET interface over each set of enterprise-interior 249 interfaces that connect the EBR to each distinct enterprise. In 250 particular, an EBR may configure mulitple VET interfaces - one for 251 each distinct enterprise. All EBRs are also EIRs. 253 Enterprise Border Gateway (EBG) 254 an EBR that connects VET interfaces configued over child 255 enterprises to a provider network - either directly via a 256 provider-edge interface, or indirectly via another VET interface 257 configured over a parent enterprise. EBRs may act as EBGs on some 258 VET interfaces and as ordinary EBRs on other VET interfaces. All 259 EBGs are also EBRs. 261 EBGs provide packet forwarding, relaying and mapping services on 262 behalf of EBRs and ordinary VET hosts within the enterprise. A 263 "default mapper" [I-D.jen-apt] is a special case of an EBG that 264 performs all EBG services except forwarding packets to provider 265 networks. Default mappers must therefore configure a default 266 route via a fully-qualified EBG. 268 enterprise-interior interface 269 a EIR's attachment to a link within an enterprise. Packets sent 270 over enterprise-interior interfaces may be forwarded over multiple 271 additional enterprise-interior interfaces within the enterprise 272 before they are forwarded via an enterprise-edge interface, 273 provider-edge interface or a VET interface configured over a 274 different enterprise. 276 enterprise-edge interface 277 an EBR's attachment to a link (e.g., an ethernet, a wireless 278 personal area network, etc.) on an arbitrarily-complex edge 279 network that the EBR connects to an enterprise and/or to provider 280 networks. 282 internal-virtual interface 283 a virtual interface that is a special case of either an 284 enterprise-edge or an enterprise-interior interface. Internal- 285 virtual interfaces that are also enterprise-edge interfaces are 286 often loopback interfaces of some form. Internal-virtual 287 interfaces that are also enterprise-interior interfaces are often 288 tunnel interfaces of some form configured over another enterprise- 289 interior interface. 291 provider-edge interface 292 an EBR's attachment to the Internet, or to a provider network 293 outside of the enterprise via which the Internet can be reached. 295 Enterprise Local Address (ELA) 296 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 297 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 298 is assigned to an enterprise-interior interface and unique within 299 the enterprise. ELAs are used as identifiers for operating the 300 routing protocol and/or locators for packet forwarding within the 301 scope of the enterprise. ELAs are used as the *outer* IP 302 addresses during encapsulation, and can also be used as addresses 303 for enterprise-internal communications that do not require 304 encapsulation. 306 Provider-Independent (PI) prefix 307 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 308 that is routable within a limited scope and may also appear in a 309 global mapping table. PI prefixes that can appear in a global 310 mapping table are typically delegated to an EBR by a registry, but 311 are not aggregated by a provider network. Local-use IPv6 and IPv4 312 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of 313 a PI prefix, but these typically do not appear in a global mapping 314 table. 316 Provider Aggregated (PA) prefix 317 an IPv6 or IPv4 prefix that is either derived from a PI prefix or 318 delegated directly to a provider network by a registry. 320 Virtual Enterprise Traversal (VET) 321 an abstraction that uses IP-in-IP encapsulation to span a multi- 322 link enterprise in a single (inner) IP hop. 324 VET interface 325 an EBR's Non-Broadcast, Multiple Access (NBMA) interface used for 326 Virtual Enterprise Traversal. The EBR configures a VET interface 327 over a set of underlying enterprise-interior interface(s) 328 belonging to the same enterprise. When there are multiple 329 distinct enterprises (each with their own distinct set of 330 enterprise-interior interfaces), the EBR configures a separate VET 331 interface over each set of enterprise-interior interfaces, i.e., 332 the EBR configures multiple VET interfaces. 334 The VET interface encapsulates each inner IP packet in any mid- 335 layer headers plus an outer IP header then forwards it on an 336 underlying enterprise-interior interface such that the TTL/Hop 337 Limit in the inner header is not decremented as the packet 338 traverses the enterprise. The VET interface therefore presents an 339 automatic tunneling abstraction that represents the enterprise as 340 a single IP hop. 342 VET host 343 any node (host or router) that configures a VET interface for host 344 operation only. Note that a single node may configure some of its 345 VET interfaces as host interfaces and others as router interfaces. 347 VET node 348 any node that configures and uses a VET interface. 350 The following additional acronyms are used throughout the document: 352 CGA - Cryptographically Generated Address 353 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 354 FIB - Forwarding Information Base 355 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 356 NBMA - Non-Broadcast, Multiple Access 357 ND - Neighbor Discovery 358 PA - Provider Aggregated 359 PI - Provider Independent 360 PIO - Prefix Information Option 361 PRL - Potential Router List 362 PRLNAME - Identifying name for the PRL (default is "isatap") 363 RIO - Route Information Option 364 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 365 SEAL - Subnetwork Encapsulation and Adaptation Layer 366 SLAAC - IPv6 StateLess Address AutoConfiguation 368 3. Enterprise Characteristics 370 Enterprises consist of links that are connected by enterprise routers 371 as depicted in Figure 1. All enterprise routers are also Enterprise 372 Interior Routers (EIRs), and typically participate in a routing 373 protocol over enterprise-interior interfaces to discover routes that 374 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 375 Border Routers (EBRs) are EIRs that connect edge networks and/or join 376 multiple enterprises together, while Enterprise Border Gateways 377 (EBGs) are EBRs that either directly or indirectly connect 378 enterprises to provider networks. A "default mapper" is a special 379 case of an EBG that performs all EBG services except forwarding 380 packets to provider networks. 382 An enterprise may be as simple as a small collection of enterprise 383 routers (and their attached edge networks); an enterprise may also 384 contain other enterprises and/or be a subnetwork of a larger 385 enterprise. An enterprise may further encompass a set of branch 386 offices and/or nomadic hosts connected to a home office over one or 387 several service providers, e.g., through Virtual Private Network 388 (VPN) tunnels. 390 Enterprises that comprise link types with sufficiently similar 391 properties (e.g., Layer-2 (L2) address formats, maximum transmission 392 units (MTUs), etc.) can configure a sub-IP layer routing service such 393 that IP sees the enterprise as an ordinary shared link the same as 394 for a (bridged) campus LAN. In that case, a single IP hop is 395 sufficient to traverse the enterprise without IP layer encapsulation. 397 Enterprises that comprise link types with diverse properties and/or 398 configure multiple IP subnets must also provide a routing service 399 that operates as an IP layer mechanism. In that case, multiple IP 400 hops may be necessary to traverse the enterprise such that specific 401 autoconfiguration procedures are necessary to avoid multilink subnet 402 issues [RFC4903]. In particular, we describe herein the use of IP- 403 in-IP encapsulation to span the enterprise in a single (inner) IP hop 404 in order to avoid the multilink subnet issues that arise when 405 enterprise-interior interfaces are used directly by applications. 407 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 408 both a host function and router function. The host function supports 409 global-scoped communications over any of the enterprise router's non- 410 enterprise-interior interfaces according to the weak end system model 411 [RFC1122] and also supports enterprise-local-scoped communications 412 over its enterprise-interior interfaces. The router function engages 413 in the enterprise-interior routing protocol, connects any of the 414 enterprise router's edge networks to the enterprise and may also 415 connect the enterprise to provider networks (see: Figure 1). 417 In addition to other interface types, VET nodes configure VET 418 interfaces that view all other VET nodes in an enterprise as single- 419 hop neighbors, where the enterprise can also appear as a single IP 420 hop within another enterprise. VET nodes configure a separate VET 421 interface for each distinct enterprise to which they connect, and 422 discover a list of EBRs for each VET interface that can be used for 423 forwarding packets to off-enterprise destinations. The following 424 sections present the Virtual Enterprise Traversal approach. 426 4. Autoconfiguration 428 EIRs, EBRs, EBGs, and VET hosts configure themselves for operation as 429 specified in the following subsections: 431 4.1. Enterprise Interior Router (EIR) Autoconfiguration 433 EIRs configure enterprise-interior interfaces and engage in routing 434 protocols over those interfaces. 436 When an EIR joins an enterprise, it first configures a unique IPv6 437 link-local address on each enterprise-interior interface that 438 requires an IPv6 link-local capability and an IPv4 link-local address 439 on each enterprise-interior interface that requires an IPv4 link- 440 local capability. IPv6 link-local address generation mechanisms that 441 provide sufficient uniqueness include Cryptographically Generated 442 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 443 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 444 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 445 provide an IPv4 link-local address generation capability. 447 Next, the EIR configures an Enterprise Local Address (ELA) of the 448 outer IP protocol version on each of its enterprise-interior 449 interfaces and engages in any routing protocols on those interfaces. 450 The EIR can configure an ELA via explicit management, DHCP 451 autoconfiguration, pseudo-random self-generation from a suitably 452 large address pool, or through an alternate autoconfiguration 453 mechanism. In some enterprise use cases (e.g., highly dynamic 454 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 455 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 456 issues. 458 EIRs that configure ELAs using DHCP may require relay support from 459 other EIRs within the enterprise; the EIR can alternatively configure 460 both a DHCP client and relay that are connected, e.g., via a pair of 461 back-to-back connected ethernet interfaces, a tun/tap interface, a 462 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 463 do not already know the ELA of a server relay requests to the 464 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 465 relays that do not already know the ELA of a server relay requests to 466 the site-scoped IPv4 multicast group address 'All_DHCPv4_Servers' 467 (see: Section 6). DHCPv4 servers that delegate ELAs join the 468 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 469 received for that group. 471 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 472 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 473 generation of ELAs for IPv4 can be from a large IPv4 private address 474 range (e.g., [RFC1918]). When self-generation is used alone, the EIR 475 must continuously monitor the ELAs for uniqueness, e.g., by 476 monitoring the routing protocol, but care must be taken in the 477 interaction of this monitoring with existing mechanisms. 479 A combined approach using both DHCP and self-generation is also 480 possible in which the EIR first self-generates a temporary ELA used 481 only for the purpose of procuring an actual ELA taken from a disjoint 482 addressing range. The EIR then assigns the temporary ELA to an 483 enterprise-interior interface, engages in the routing protocol and 484 performs a DHCP client/relay exchange using the temporary ELA as the 485 address of the relay. When the DHCP server delegates an actual ELA, 486 the EIR abandons the temporary ELA, assigns the actual ELA to the 487 enterprise-interior interface and re-engages in the routing protocol. 489 4.2. Enterprise Border Router (EBR) Autoconfiguration 491 EBRs are EIRs that configure VET interfaces over distinct sets of 492 underlying enterprise-interior interfaces; an EBR can connect to 493 multiple enterprises, in which case it would configure multiple VET 494 interfaces. EBRs perform the following autoconfiguration operations: 496 4.2.1. VET Interface Autoconfiguration 498 VET interface autoconfiguration entails: 1) interface initialization, 499 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 500 address autoconfiguration. These functions are specified in the 501 following sections: 503 4.2.1.1. Interface Initialization 505 EBRs configure a VET interface over a set of underlying enterprise- 506 interior interfaces belonging to the same enterprise, where the VET 507 interface presents a Non-Broadcast, Multiple Access (NBMA) 508 abstraction in which all EBRs in the enterprise appear as single hop 509 neighbors through the use of IP-in-IP encapsulation. 511 When IPv6 and IPv4 are used as the inner/outer protocols 512 (respectively), the EBR autoconfigures an ISATAP link-local address 513 ([RFC5214], Section 6.2) on the VET interface to support packet 514 forwarding and operation of the IPv6 neighbor discovery protocol. 515 The ISATAP link-local address embeds an IPv4 ELA assigned to an 516 underlying enterprise-interior interface, and need not be checked for 517 uniqueness since the IPv4 ELA itself was already checked (see: 518 Section 4.1). Link-local address configuration for other inner/outer 519 IP protocol combinations is through administrative configuration or 520 through an unspecified alternate method. 522 After the EBR configures a VET interface, it can communicate with 523 other VET nodes as single-hop neighbors from the viewpoint of the 524 inner IP protocol. 526 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 527 Identification 529 The EBR next discovers a list of EBGs for each of its VET interfaces. 530 The list can be discovered through information conveyed in the 531 routing protocol and/or through the Potential Router List (PRL) 532 discovery mechanisms outlined in ([RFC5214], Section 8.3.2). In 533 multicast-capable enterprises, they can also listen for 534 advertisements on the 'rasadv' [RASADV] IPv4 multicast group address. 536 In particular, whether or not routing information is available the 537 EBR can discover the list of EBGs in the PRL by resolving an 538 identifying name for the PRL ('PRLNAME') using an enterprise local 539 name resolution service (e.g., an enterprise-local DNS service, LLMNR 540 [RFC4759], etc.). 'PRLNAME' is formed as 'hostname.domainname', 541 where 'hostname' is an enterprise-specific name string and 542 'domainname' is an enterprise-specific DNS suffix when such a suffix 543 is available. 545 The EBR discovers 'PRLNAME' through manual configuration, a DHCP 546 option, 'rasadv' protocol advertisements, link-layer information 547 (e.g., an IEEE 802.11 SSID) or through some other means specific to 548 the enterprise. In the absence of other information, the EBR sets 549 the 'hostname' component of 'PRLNAME' to "isatap" and sets the 550 'domainname' component only if an enterprise-specifc DNS suffix 551 "example.com" is known (e.g., as "isatap.example.com"). 553 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 554 resolving 'PRLNAME' to a list of IPv4 addresses through a name 555 service lookup. 'PRLNAME' as well as the ELAs of EBGs and/or the IP 556 prefixes they aggregate serve as an identifier for the enterprise. 558 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration 560 EBRs can acquire Provider-Aggregated (PA) prefixes through 561 autoconfiguration exchanges with EBGs over VET interfaces. When IPv4 562 is used as the inner IP protocol, the EBR acquires PA prefixes via an 563 unspecified automated IPv4 prefix delegation exchange, explicit 564 management, etc. 566 When IPv6 is used as the inner IP protocol, the EBR acquires PA 567 prefixes via IPv6 Neighbor Discovery and DHCPv6 Prefix Delegation 568 exchanges. In particular, the EBR (acting as a requesting router) 569 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 570 obtain PA IPv6 prefixes from the server (acting as a delegating 571 router). 573 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 574 exchange [RFC3315]. For example, to perform the 2-message exchange 575 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 576 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 577 relay (see: Section 4.1). The relay then forwards the message over 578 the VET interface to the EBG. The forwarded Solicit message will 579 elicit a reply from the server containing PA IPv6 prefix delegations. 581 The EBR can propose a specific prefix to the DHCPv6 server per 582 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 583 available. The server will check the proposed prefix for consistency 584 and uniqueness, then return it in the reply to the EBR if it was able 585 to perform the delegation. 587 After the EBR receives PA prefix delegations, it can provision the 588 prefixes on its enterprise-edge interfaces as well as on other VET 589 interfaces for which it is configured as an EBG. 591 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration 593 Independent of any PA prefixes, EBRs can acquire and use Provider- 594 Independent (PI) prefixes that are either delegated by a registration 595 authority or self-configured by the EBR 596 [RFC4193][I-D.ietf-ipv6-ula-central]). 598 When an EBR acquires a PI prefix, it must also obtain credentials 599 (e.g., from a certification authority) that it can use to prove 600 prefix ownership through Secure Neighbor Discovery (SEND) [RFC3971] 601 messaging as specified in Section 5.3 and Section 5.4. 603 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 605 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 607 EBGs are EBRs that connect child enterprises to a provider network 608 via ordinay provider-edge interfaces and/or VET interfaces configured 609 over parent enterprises. EBGs autoconfigure provider-edge interfaces 610 in a manner that is specific to their provider connections, and 611 autoconfigure VET interfaces as specified in Section 4.2.1. EBGs 612 that support PA prefix delegation also configure a DHCP relay/server. 614 For each VET interface on which it is configured as an EBG, the EBG 615 must arrange to add its enterprise-interior interface addresses 616 (i.e., its ELAs) to the PRL (see: Section 4.2.1.2), and must maintain 617 these resource records in accordance with ([RFC5214], Section 9). In 618 particular, for each such VET interface the EBG adds its ELAs to name 619 service resource records for 'PRLNAME'. 621 4.4. VET Host Autoconfiguration 623 Nodes that cannot be attached via an EBR's enterprise-edge interface 624 (e.g., nomadic laptops that connect to a home office via a Virtual 625 Private Network (VPN)) can instead be configured for operation as a 626 simple host connected to the VET interface. Such VET hosts perform 627 the same VET interface autoconfiguration procedures as specified for 628 EBRs in Section 4.2.1, but they configure their VET interfaces as 629 host interfaces (and not router interfaces). VET hosts can then send 630 packets to other hosts on the VET interface, or to off-enterprise 631 destinations via a next-hop EBR. 633 Note that a node may be configured as a host on some VET interfaces 634 and as an EBR/EBG on other VET interfaces. 636 5. Internetworking Operation 638 Following the autoconfiguration procedures specified in Section 4, 639 EIRs, EBRs, EBGs and VET hosts engage in normal internetworking 640 operations as discussed in the following sections: 642 5.1. Routing Protocol Participation 644 Following autoconfiguration, EIRs engage in any routing protocols 645 over their enterprise-interior interfaces and forward outer IP 646 packets within the enterprise as for any ordinary router. 648 EBRs can additionally engage in any inner IP routing protocols over 649 enterprise-edge and provider-edge interfaces, and can use those 650 interfaces for forwarding inner IP packets to off-enterprise 651 destinations. Note that these inner IP routing protocols are 652 separate and distinct from any enterprise-interior routing protocols. 654 5.2. PA Prefix Maintenance 656 When an EBR uses DHCP prefix delegation to obtain PA prefixes via an 657 EBG, the DHCP server ensures that the delegations are unique and that 658 the EBG's router function will forward IP packets over the VET 659 interface to the correct EBR. 661 The DHCP prefix delegations remain active as long as the EBR 662 continues to issue renewals over the VET interface before lease 663 lifetimes expire. The lease lifetime also keeps the delegation state 664 active even if communications between the EBR and DHCP server are 665 disrupted for a period of time (e.g., due to an enterprise network 666 partition) before being reestablished (e.g., due to an enterprise 667 network merge). 669 Additionnally, ordinary requesting routers on enterprise edge 670 interfaces can maintain PA prefix delegations exactly as specified in 671 [RFC3633]. 673 5.3. IPv6 Border Router Discovery and PI Prefix Maintenance 675 The following sections discuss border router discovery and PI prefix 676 maintenance for the case of IPv6 as the inner IP protocol: 678 5.3.1. IPv6 EBG Discovery 680 EBGs follow the router and prefix discovery procedures specified in 681 ([RFC5214], Section 8.2). They send solicited RAs over VET 682 interfaces for which they are configured as gateways with default 683 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 684 with any other required options/parameters. EBGs must set the 'M' 685 flag in RAs to 0, since the use of DHCPv6 for address configuration 686 on VET interfaces is undefined. EBGs can also include PIOs with the 687 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 688 of an aggregated prefix from which it is willing to delegate longer 689 PA prefixes. 691 VET nodes follow the router and prefix discovery procedures specified 692 in ([RFC5214], Section 8.3). They discover EBGs within the 693 enterprise as specified in Section 4.2.1.2, then perform SEND- 694 protected RS/RA exchanges with the EBGs to establish and maintain 695 default routes. In particular the VET node sends SEND-protected 696 unicast RS messages to EBGs over its VET interface(s) to receive 697 SEND-protected RAs. When the VET node receives an RA, it configures 698 a default route based on the Router Lifetime. If the RA contains 699 Prefix Information Options (PIOs) with the 'A' and 'L' bits set to 1, 700 the VET node also autoconfigures IPv6 addresses from the advertised 701 prefixes using SLAAC and assigns them to the VET interface. 702 Thereafter, the VET node accepts packets that are fowarded by EBGs 703 for which it has current default routing information (i.e., ingress 704 filtering is based on the default router relationship rather than a 705 prefix-specific ingress filter entry). 707 5.3.2. IPv6 PI Prefix Registration 709 When an EBR discovers EBGs for the enterprise, it must register its 710 PI prefixes by sending SEND-protected RAs to a set of one or more 711 EBGs with Route information Options (RIOs) [RFC4191] that contain the 712 EBR's PI prefixes. Each RA must include the ELA of an EBG as the 713 outer IP destination address and an ISATAP link-local address derived 714 from the ELA as the inner IP destination address. The RAs must also 715 include a CGA link-local inner source address along with a SEND 716 signature that can be used to validate the CGA plus any certificates 717 needed to prove ownership of the PI prefixes. The EBR additionally 718 tracks the set of EBGs that it sends RAs to so that it can send 719 subsequent RAs to the same set. 721 When the EBG receives the RA, it uses SEND to authenticate the 722 message; if the authentication fails, the EBG discards the RA. 723 Otherwise, the EBG installs the PI prefixes with their respective 724 lifetimes in its Forwarding Information Base (FIB) and configures 725 them for both ingress filtering [RFC3704] and forwarding purposes. 726 In particular, the EBG configures the FIB entries as ingress filter 727 rules to accept packets received on the VET interface with a source 728 address taken from the PI prefixes. It also configures the FIB 729 entries to forward packets received on other interfaces with a 730 destination address taken from the PI prefixes to the EBR that 731 registered the prefixes on the VET interface. 733 The EBG then publishes the PI prefixes in a distributed database 734 (e.g., in a private instance of a routing protocol in which only EBGs 735 participate, via an automated name service update mechanism 736 [RFC3007], etc.). For enterprises that are managed under a 737 cooperative administrative authority, the EBG also makes the PI 738 prefixes available for enterprise-local name service queries 739 [RFC1035]. For VET interfaces configured over enterprises that are 740 managed in a distributed fashion, EBG should instead respond directly 741 to LLMNR [RFC4759] name service queries. 743 To support name service queries, the EBG publishes each /56 prefix 744 taken from the PI prefixes as a seperate FQDN that consists of a 745 sequence of 14 nibbles in reverse order (i.e., the same as in 746 [RFC3596], Section 2.5) followed by the string 'PRLNAME'. For 747 example, when 'PRLNAME' is "isatap.example.com", the EBG publishes 748 the prefix '2001:DB8::/56' as: 749 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. The EBG 750 includes the inner IPv6 CGA source address (e.g., in a DNS AAAA 751 record) and the outer IPv4 source address of the RA (e.g., in a DNS A 752 resource record) in each prefix publication. If the prefix was 753 already installed in the distributed database, the EBG instead adds 754 the outer IPv4 source address (e.g., in an additional DNS AAAA 755 record) to the pre-existing publication. 757 After the EBG authenticates the RA and publishes the PI prefixes, it 758 next acts as a Secure Neighbor Discovery Proxy (SENDProxy) 759 [I-D.ietf-csi-proxy-send] on the VET interfaces configured over any 760 of its provider enterprises and relays a SEND-protected proxied RA to 761 the default routers (i.e., EBGs) on those interfaces. Those EBGs in 762 turn act as SENDProxys to relay the RAs to EBGs on their provider 763 enterprises, etc. The RA proxying and PI prefix publication recurses 764 in this fashion and ends when a default mapping service for the 765 interdomain routing core is reached. (In the case of the global 766 Internet interdomain routing core, the 'PRLNAME' for the default 767 mapping service is "isatap.net".) 769 After the initial PI prefix registration, the EBR that owns the 770 prefix(es) must periodically send additional RAs to its set of EBGs 771 to refresh prefix lifetimes. Each such EBG/SENDProxy tracks the set 772 of EBGs that it relays the proxied RAs to, and should relay 773 subsequent RAs to the same set of EBGs. 775 This procedure has a direct analogy in the Teredo method of 776 maintaining state in network middleboxes through the periodic 777 transmission of "bubbles" [RFC4380]. 779 5.3.3. IPv6 Next-Hop EBR Discovery 781 VET nodes discover destination-specific next-hop EBRs within the 782 enterprise by querying the name service for the /56 IPv6 PI prefix 783 taken from a packet's destination address, by forwarding packets via 784 a default route to an EBG, or by some other inner IP to outer IP 785 address mapping mechansim. For example, for the IPv6 destination 786 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 787 node can lookup the domain name: 788 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. If the name 789 service lookup succeeds, it will return an IPv6 CGA address (e.g., in 790 a DNS AAAA record) and IPv4 addresses (e.g., in DNS A records) that 791 correspond to the ELAs assigned to enterprise interior interfaces of 792 next-hop EBRs to which the VET node can forward packets. 794 Alternatively, the VET node can simply forward an initial packet via 795 a default route to an EBG. The EBG will forward the packet to a 796 next-hop EBR on the VET interface and return a SEND-protected ICMPv6 797 Redirect [RFC4861]. If the packet's source address is on-link on the 798 VET interface, the EBG returns an ordinary "router-to-host" redirects 799 with the source address of the packet as its destination. If the 800 packet's source address is not on-link, the EBG instead returns a 801 "router-to-router" redirect with the link-local ISATAP address of the 802 previous-hop EBR as its destination. The EBG also includes in the 803 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 804 contain the IPv4 ELAs of potential next-hop EBRs arranged in order 805 from highest to lowest priority (i.e., the first LLAO contains the 806 highest priority ELA and the final LLAO option contains the lowest 807 priority). The LLAOs are formatted using a modified version of the 808 form specified in ( [RFC2529], Section 5) as shown in Figure 2: 810 +-------+-------+-------+-------+-------+-------+-------+-------+ 811 | Type |Length | TTL | IPv4 Address | 812 +-------+-------+-------+-------+-------+-------+-------+-------+ 814 Figure 2: VET Link-Layer Address Option Format 816 For each LLAO, the Type is set to 2 (for Target Link-Layer Address 817 Option), Length is set to 1, and IPv4 Address is set to the IPv4 ELA 818 of the next-hop EBR. TTL is set to the time in seconds that the 819 recipient may cache the ELA, where the value 65535 represents 820 infinity and the value 0 suspends forwarding through this ELA. 822 When a VET host receives an ordinay "router-to-host" redirect, it 823 processes the redirect exacly as specified in [RFC4861], Section 8. 824 When an EBR receives a "router-to-router" redirect, it discovers the 825 IPv4 ELA addresses of potential next-hop EBRs by examining the LLAOs 826 included in the redirect. The EBR then installs a FIB entry that 827 contains the /56 prefix of the destination address encoded in the 828 redirect and the list of IPv4 ELAs of potential next-hop EBRs. The 829 EBR then enables the FIB entry for forwarding to next-hop EBRs but 830 DOES NOT enable it for ingress filtering acceptance of packets from 831 next-hop EBRs (i.e., the forwarding determination is unidirectional). 832 The EBR then sends RAs over the VET interface to one or more of the 833 potential next-hop EBRs with a link-local ISATAP address that embeds 834 a next-hop EBR IPv4 ELA as the destination. The RAs must include the 835 EBR's CGA link-local address as the inner IPv6 source address along 836 with a SEND signature. The RAs must also include a Route Information 837 Option (RIO) [RFC4191] that contains the /56 PI prefix of the 838 original packet's source address. Afte sending the RAs, the EBR can 839 either enable the new FIB entry for forwarding immediately or delay 840 until it receives an acknowledgement that a next-hop EBR received the 841 RA (see: Section 5.6). 843 When a next-hop EBR receives the RA, it uses SEND to verify the CGA 844 then performs a name service lookup on the prefix in the RIO. If the 845 name service returns the correct CGA and ELA information, the next- 846 hop EBR then installs the prefix in the RIO in its FIB and enables 847 the FIB entry for ingress filtering but DOES NOT enable it for 848 forwarding purposes. After an EBR sends initial RAs following a 849 redirect, it should send periodic RAs to refresh the next-hop EBR's 850 ingress filter prefix lifetimes as long as traffic is flowing. 852 EBRs retain the FIB entrys created as side effect of an ICMP redirect 853 until all ELA TTLs expire, or until no hints of forward progress 854 through any of the associated ELAs are received. In this way, ELA 855 liveness detection exactly parallels IPv6 Neighbor Unreachability 856 Detection ([RFC4861], Section 3). 858 5.4. IPv4 Border Router Discovery and PI Prefix Maintenace 860 When IPv4 is used as the inner IP protocol, border router discovery 861 and PI prefix maintenance exactly parallels the mechanisms specified 862 for IPv6 in Section 5.3. To support this, modifications to the 863 ICMPv4 Router Advertisement [RFC1256] function to include SEND 864 constructs, and modifications to the ICMPv4 Redirect [RFC0792] 865 function to support router-to-router redirects will be specified in a 866 future document. Additionally, publications for IPv4 prefixes will 867 be in dotted-nibble format in the 'ip4.isatap.example.com' domain. 868 For example, the IPv4 prefix 192.0.2/24 would be represented as: 869 '2.0.0.0.0.c.ip4.isatap.example.com'. 871 5.5. Forwarding Packets 873 VET nodes forward packets by consulting the FIB to determine a 874 specific EBR/EBG as the next-hop router on a VET interface. When 875 multiple next-hop routers are available, VET nodes can use default 876 router preferences, routing protocol information, traffic engineering 877 configurations, etc. to select the best exit router. When there is 878 no FIB information other than ::/0 available, VET nodes can discover 879 the next-hop EBR/EBG through the mechanisms specified in 880 Section 5.3.1 and Section 5.3.3. 882 VET interfaces encapsulate inner IP packets in any mid-layer headers 883 followed by an outer IP header according to the specific 884 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 885 next submit the encapsulated packet to the outer IP forwarding engine 886 for transmission on an underlying enterprise-interior interface. 888 For forwarding to next-hop addresses over VET interfaces that use 889 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 890 address (i.e., the IPv4 ELA of the next-hop EBR) through static 891 extraction of the IPv4 address embedded in the next-hop ISATAP 892 address. For other IP-in-IP encapsulations, determination of the 893 outer destination address is through administrative configuration or 894 through an unspecified alternate method. When there are multiple 895 candidate destination ELAs available, the VET node should only select 896 an ELA for which there is current forwarding information in the outer 897 IP protocol FIB. 899 5.6. SEAL Encapsulation 901 VET nodes that do not use IPsec encapsulation should use SEAL 902 encapsulation [I-D.templin-seal] in conjunction with packet 903 forwarding over VET interfaces to accommdate path MTU diversity, to 904 detect source address spoofing, and to monitor next-hop EBR 905 reachability. SEAL encapsulation maintains a unidirectional and 906 monotonically-incrementing per-packet identification value known as 907 the 'SEAL_ID'. When a VET node that uses SEAL encapsulation sends a 908 SEND-protected Router Advertisement (RA) or Router Solicitation (RS) 909 message to another VET node, both nodes cache the new SEAL_ID as per- 910 tunnel state used for maintaining a window of unacknowledged 911 SEAL_IDs. 913 In terms of security, when a VET node receives an ICMP message, it 914 can confirm that the packet-in-error within the ICMP message 915 corresponds to one of its recently-sent packets by examining the 916 SEAL_ID along with source and destination addresses, etc. 917 Additionally, a next-hop EBR can track the SEAL_ID in packets 918 received from EBRs for which there is an ingress filter entry and 919 discard packets that have SEAL_ID values outside of the current 920 window. 922 In terms of next-hop reachability, an EBR can set the SEAL 923 "Acknowledgement Requested" bit in messages to receive confirmation 924 that a next-hop EBR is reachable (see also Section 5.3.3. Setting 925 the "Acknowledgement Requested" bit is also used as the method for 926 maintaining the window of outstanding SEAL_ID's. 928 5.7. Generating Errors 930 When an EBR receives a packet over a VET interface and there is no 931 matching ingress filter entry, it drops the packet and returns an 932 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 933 ingress/egress policy" message to the previous hop EBR subject to 934 rate limiting. 936 When an EBR receives a packet over a VET interface, and there is no 937 longest-prefix-match FIB entry for the destination, it returns an 938 ICMPv6 "Destination Unreachable; No route to destination" message to 939 the previous hop EBR subject to rate limiting. 941 When an EBR receives a packet over a VET interface and the longest- 942 prefix-match FIB entry for the destination is configured over the 943 same VET interface the packet arrived on, the EBR forwards the packet 944 then (if the FIB prefix is longer than ::/0) sends a SEND-protected 945 router-to-router ICMPv6 Redirect message to the previous hop EBR as 946 specified in Section 5.3.3. 948 Generation of other ICMPv6 messages (e.g., ICMPv6 "Packet Too Big") 949 is the same as for any IPv6 interface. 951 5.8. Processing Errors 953 When an EBR receives an ICMPv6 "Destination Unreachable; Source 954 address failed ingress/egress policy" message from a next-hop EBR, 955 and there is a longest-prefix-match FIB entry for the original 956 packet's destination that is more-specific than ::/0, the EBR 957 discards the message and marks the FIB entry for the destination as 958 "forwarding suspended" for the ELA taken from the source address of 959 the ICMPv6 message. The EBR should then allow subsequent packets to 960 flow through different ELAs associated with the FIB entry until it 961 forwards a new SEND-protected RA to the suspended ELA. If the EBR 962 receives excessive ICMPv6 ingress policy errors through multiple ELAs 963 associated with the same FIB entry, it should delete the FIB entry 964 and allow subsequent packets to flow through an EBG. 966 When a VET node receives an ICMPv6 "Destination Unreachable; No route 967 to destination" message from a next-hop EBR, it forwards the ICMPv6 968 message to the source of the original packet as normal. If the EBR 969 has longest-prefix-match FIB entry for the original packet's 970 destination that is more-specific than ::/0, the EBR also deletes the 971 FIB entry. 973 When an EBR receives an ICMPv6 Redirect with a valid SEND signature, 974 it processes the packet as specified in Section 5.3.3. 976 When an EBG receives new mapping information for a specific 977 destination prefix, it can propagate the update to other EBRs/EBGs by 978 sending an ICMPv6 redirect message to the 'All Routers' link-local 979 multicast address with a LLAO with the TTL for the unreachable LLAO 980 set to zero, and with a NULL packet in error. 982 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 983 Unreachable; net / host unreachable" messages from an EIR indicating 984 that the path to a VET neighbor may be failing. The EBR should first 985 check identifying information in the message (e.g., the SEAL_ID, 986 IPsec sequence number, source address of the original packet if 987 available, etc.) before accepting it, then should mark the longest- 988 prefix-match FIB entry for the destination as "forwarding suspended" 989 for the ELA destination address of the ICMPv4 packet-in-error. If 990 the EBR receives excessive ICMPv4 unreachable errors through multiple 991 ELAs associated with the same FIB entry, it should delete the FIB 992 entry and allow subsequent packets to flow through a different route. 994 5.9. Mobility and Multihoming Considerations 996 EBRs can retain their PI prefixes as they travel between distinct 997 enterprise networks as long as they register the prefixes with new 998 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 999 departure. Prefix registration with new EBGs is coordinated exactly 1000 as specified in Section 5.3.2; prefix withdrawl from old EBGs is 1001 simply through re-announcing the PI prefixes with zero lifetimes. 1003 Since EBRs can move about independently of one another, stale FIB 1004 entry state may be left in VET nodes when a neighboring EBR departs. 1005 Additionally, EBRs can lose state for various reasons, e.g., power 1006 failure, machine reboot, etc. For this reason, EBRs are advised to 1007 set relatively short PI prefix lifetimes in RIO options, and to send 1008 additional RAs to refresh lifetimes before they expire. (EBRs should 1009 place conservative limits on the RAs they send to reduce congestion, 1010 however.) 1012 EBRs may register their PI prefixes with multiple EBGs for 1013 multihoming purposes. EBRs should only forward packets via EBGs with 1014 which it has registered its PI prefixes, since other EBGs may drop 1015 the packets and return ICMPv6 "Destination Unreachable; Source 1016 address failed ingress/egress policy" messages. 1018 EBRs can also act as delegating routers to sub-delegate portions of 1019 their PI prefixes to requesting routers on their enterprise edge 1020 interfaces and on VET interfaces for which they are configured as 1021 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1022 become the PA prefixes for downstream-dependent nodes. Downstream- 1023 dependent nodes that travel with a mobile provider EBR can continue 1024 to use addresses configured from PA prefixes; downstream-dependent 1025 nodes that move away from their provider EBR must perform address/ 1026 prefix renumbering when they assocate with a new provider. 1028 The EBGs of a multi-homed enterprise should participate in a private 1029 inner IP routing protocol instance between themselves (possibly over 1030 an alternate topology) to accommodate enterprise partitions/merges as 1031 well as intra-enterprise mobility events. These peer EBGs should 1032 accept packets from one another without respect to the destination 1033 (i.e., ingress filtering is based on the peering relationship rather 1034 than a prefix-specific ingress filter entry). 1036 5.10. Enterprise-Local Communications 1038 When permitted by policy, end systems that configure the endpoints of 1039 enterprise-local communications can avoid VET interface encapsulation 1040 by directly invoking the outer IP protocol using ELAs assigned to 1041 their enterprise-interior interfaces. For example, when the outer 1042 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 1043 communications over their enterprise-interior interfaces without 1044 using encapsulation. 1046 5.11. Multicast 1048 In multicast-capable deployments, EIRs provide an enterprise-wide 1049 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1050 [I-D.ietf-manet-smf], PIM routing, DVMRP routing, etc.) over their 1051 enterprise-interior interfaces such that outer IP multicast messages 1052 of site- or greater scope will be propagated across the enterprise. 1053 For such deployments, VET nodes can also provide an inner IP 1054 multicast/broadcast capability over their VET interfaces through 1055 mapping of the inner IP multicast address space to the outer IP 1056 multicast address space. In that case, operation of link- or greater 1057 scoped inner IP multicasting services (e.g., a link-scoped neighbor 1058 discovery protocol) over the VET interface is available, but link- 1059 scoped services should be used sparingly to minimize enterprise-wide 1060 flooding. 1062 VET nodes encapsulate inner IP multicast messages sent over the VET 1063 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1064 outer IP header with a site-scoped outer IP multicast address as the 1065 destination. For the case of IPv6 and IPv4 as the inner/outer 1066 protocols (respectively), [RFC2529] provides mappings from the IPv6 1067 multicast address space to a site-scoped IPv4 multicast address space 1068 (for other IP-in-IP encapsulations, mappings are established through 1069 administrative configuration or through an unspecified alternate 1070 method). 1072 Multicast forwarding for inner IP multicast groups over outer IP 1073 multicast groups can be accommodated, e.g. through VET interface 1074 snooping of inner multicast group membership and routing protocol 1075 control messages. To support inner-to-outer IP multicast forwarding, 1076 VET interface acts as a virtual outer IP multicast host connected to 1077 its underlying enterprise-interior interfaces. When the VET 1078 interface detects inner IP multicast group joins or leaves, it 1079 forwards corresponding outer IP multicast group membership reports 1080 for each enterprise-interior interface over which the VET interface 1081 is configured. If the VET node is configured as an outer IP 1082 multicast router on the underlying enterprise-interior interfaces, 1083 the VET interface forwards locally looped-back group membership 1084 reports to the outer IP multicast routing process. If the VET node 1085 is configued as a simple outer IP multicast host, the VET interface 1086 instead fowards actual group membership reports (e.g., IGMP messages) 1087 directly over each of the underlying enterprise-interior interfaces. 1089 Since inner IP multicast groups are mapped to site-scoped outer IP 1090 multicast groups, the VET node must ensure that the site-scope outer 1091 IP multicast messages received on the enterprise-interior interfaces 1092 for one VET interface do not "leak over" to the enterprise-interior 1093 interfaces of another VET interface. This is accomodated through 1094 normal site-scoped outer IP multicast group filtering at enterprise- 1095 interior interface boundaries. 1097 5.12. Service Discovery 1099 VET nodes can peform enterprise-wide service discovery using a 1100 suitable name-to-address resolution service. Examples of flooding- 1101 based services include the use of LLMNR [RFC4759] over the VET 1102 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1103 underlying enterprise-interior interface. More scalable and 1104 efficient service discovery mechanisms are for further study. 1106 5.13. Enterprise Partitioning 1108 EBGs can physically partition an enterprise by configuring multiple 1109 VET interfaces over multiple distinct sets of underlying interfaces. 1110 In that case, each partition (i.e., each VET interface) must 1111 configure its own distinct 'PRLNAME' (e.g., 1112 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1114 EBGs can logically partition an enterprise using a single VET 1115 interface by sending RAs with PIOs containing different IPv6 PA 1116 prefixes to group nodes into different logical partitions. EBGs can 1117 identify partitions, e.g., by examining IPv4 ELA prefixes, observing 1118 the interfaces over which RSs are received, etc. In that case, a 1119 single 'PRLNAME' can cover all partitions. 1121 6. IANA Considerations 1123 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1124 DHCPv4 server discovery is requested. The allocation should be taken 1125 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1126 the IANA 'multicast-addresses' registry. 1128 7. Security Considerations 1130 Security considerations for MANETs are found in [RFC2501]. 1132 Security considerations with tunneling that apply also to VET are 1133 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1134 that the outer IP source address of a packet received on a VET 1135 interface is correct for the inner IP source address using the 1136 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1137 the ingress filtering mechanisms specified in this document. 1139 SEND [RFC3971] and SEAL Section 5.6 provide additional securing 1140 mitigations to detect source address spoofing and bogus RA messages 1141 sent by rogue routers. 1143 Rogue routers can send bogus RA messages with spoofed ELA source 1144 addresses that can consume network resources and cause EBGs to 1145 perform extra work. Nonetheless, EBGs should not "blacklist" such 1146 ELAs, as that may result in a denial of service to the ELAs' 1147 legitimate owners. 1149 8. Related Work 1151 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1152 automatic tunneling in [RFC2529]; this concept was later called: 1153 "Virtual Ethernet" and investigated by Quang Nguyen under the 1154 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1155 their colleagues have motivated a number of foundational concepts on 1156 which this work is based. 1158 Telcordia has proposed DHCP-related solutions for MANETs through the 1159 CECOM MOSAIC program. 1161 The Naval Research Lab (NRL) Information Technology Division uses 1162 DHCP in their MANET research testbeds. 1164 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 1165 pertaining to tunneling mechanisms. 1167 An automated IPv4 prefix delegation mechanism is proposed in 1168 [I-D.ietf-dhc-subnet-alloc]. 1170 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1172 Various proposals within the IETF have suggested similar mechanisms. 1174 9. Acknowledgements 1176 The following individuals gave direct and/or indirect input that was 1177 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Scott 1178 Brim, Brian Carpenter, James Bound, Thomas Clausen, Dino Farinacci, 1179 Vince Fuller, Thomas Goff, Joel Halpern, Bob Hinden, Sapumal 1180 Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe Macker, David Meyer, 1181 Thomas Narten, Pekka Nikander, Dave Oran, Alexandru Petrescu, John 1182 Spence, Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela Vanderveen, 1183 Lixia Zhang and others in the IETF AUTOCONF and MANET working groups. 1184 Many others have provided guidance over the course of many years. 1186 10. Contributors 1188 The following individuals have contributed to this document: 1190 Eric Fleischman (eric.fleischman@boeing.com) 1191 Thomas Henderson (thomas.r.henderson@boeing.com) 1192 Steven Russert (steven.w.russert@boeing.com) 1193 Seung Yi (seung.yi@boeing.com) 1195 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1196 of the document. 1198 11. References 1200 11.1. Normative References 1202 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1203 September 1981. 1205 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1206 RFC 792, September 1981. 1208 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1209 converting network protocol addresses to 48.bit Ethernet 1210 address for transmission on Ethernet hardware", STD 37, 1211 RFC 826, November 1982. 1213 [RFC1035] Mockapetris, P., "Domain names - implementation and 1214 specification", STD 13, RFC 1035, November 1987. 1216 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1217 RFC 2131, March 1997. 1219 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1220 (IPv6) Specification", RFC 2460, December 1998. 1222 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1223 Update", RFC 3007, November 2000. 1225 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1226 and M. Carney, "Dynamic Host Configuration Protocol for 1227 IPv6 (DHCPv6)", RFC 3315, July 2003. 1229 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1230 "DNS Extensions to Support IP Version 6", RFC 3596, 1231 October 2003. 1233 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1234 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1235 December 2003. 1237 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1238 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1240 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1241 RFC 3972, March 2005. 1243 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1244 More-Specific Routes", RFC 4191, November 2005. 1246 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1247 Architecture", RFC 4291, February 2006. 1249 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1250 Message Protocol (ICMPv6) for the Internet Protocol 1251 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1253 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1254 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1255 September 2007. 1257 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1258 Address Autoconfiguration", RFC 4862, September 2007. 1260 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1261 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1262 March 2008. 1264 11.2. Informative References 1266 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1267 Switching Networks", May 1974. 1269 [I-D.cheshire-dnsext-multicastdns] 1270 Cheshire, S. and M. Krochmal, "Multicast DNS", 1271 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1272 September 2008. 1274 [I-D.clausen-manet-linktype] 1275 Clausen, T., "The MANET Link Type", 1276 draft-clausen-manet-linktype-00 (work in progress), 1277 October 2008. 1279 [I-D.ietf-autoconf-manetarch] 1280 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1281 Network Architecture", draft-ietf-autoconf-manetarch-07 1282 (work in progress), November 2007. 1284 [I-D.ietf-csi-proxy-send] 1285 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1286 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1287 in progress), November 2008. 1289 [I-D.ietf-dhc-subnet-alloc] 1290 Johnson, R., "Subnet Allocation Option", 1291 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1292 July 2008. 1294 [I-D.ietf-ipv6-ula-central] 1295 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1296 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1297 progress), June 2007. 1299 [I-D.ietf-manet-smf] 1300 Macker, J. and S. Team, "Simplified Multicast Forwarding 1301 for MANET", draft-ietf-manet-smf-08 (work in progress), 1302 November 2008. 1304 [I-D.ietf-v6ops-tunnel-security-concerns] 1305 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1306 Concerns With IP Tunneling", 1307 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1308 progress), October 2008. 1310 [I-D.jen-apt] 1311 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1312 L. Zhang, "APT: A Practical Transit Mapping Service", 1313 draft-jen-apt-01 (work in progress), November 2007. 1315 [I-D.templin-seal] 1316 Templin, F., "The Subnetwork Encapsulation and Adaptation 1317 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1318 August 2008. 1320 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1321 July 1978. 1323 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1324 Protocol Specification", October 2008. 1326 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1327 Communication Layers", STD 3, RFC 1122, October 1989. 1329 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1330 September 1991. 1332 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1333 Routing and Addressing Architecture", RFC 1753, 1334 December 1994. 1336 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1337 E. Lear, "Address Allocation for Private Internets", 1338 BCP 5, RFC 1918, February 1996. 1340 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1341 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1343 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1344 (MANET): Routing Protocol Performance Issues and 1345 Evaluation Considerations", RFC 2501, January 1999. 1347 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1348 Domains without Explicit Tunnels", RFC 2529, March 1999. 1350 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1351 February 2000. 1353 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1354 via IPv4 Clouds", RFC 3056, February 2001. 1356 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1357 Networks", BCP 84, RFC 3704, March 2004. 1359 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1360 RFC 3753, June 2004. 1362 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1363 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1364 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1365 RFC 3819, July 2004. 1367 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1368 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1369 May 2005. 1371 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1372 Addresses", RFC 4193, October 2005. 1374 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1375 Internet Protocol", RFC 4301, December 2005. 1377 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1378 Network Address Translations (NATs)", RFC 4380, 1379 February 2006. 1381 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1382 Indicator Parameter for the "tel" URI", RFC 4759, 1383 December 2006. 1385 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1386 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1387 Focus", RFC 4852, April 2007. 1389 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1390 June 2007. 1392 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1393 Extensions for Stateless Address Autoconfiguration in 1394 IPv6", RFC 4941, September 2007. 1396 Appendix A. Duplicate Address Detection (DAD) Considerations 1398 A-priori uniqueness determination (also known as "pre-service DAD") 1399 for an ELA assigned on an enterprise-interior interface would require 1400 either flooding the entire enterprise or somehow discovering a link 1401 in the enterprise on which a node that configures a duplicate address 1402 is attached and performing a localized DAD exchange on that link. 1403 But, the control message overhead for such an enterprise-wide DAD 1404 would be substantial and prone to false-negatives due to packet loss 1405 and intermittent connectivity. An alternative to pre-service DAD is 1406 to autoconfigure pseudo-random ELAs on enterprise-interior interfaces 1407 and employ a passive in-service DAD (e.g., one that monitors routing 1408 protocol messages for duplicate assignments). 1410 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1411 CGAs, IPv6 privacy addresses, etc. with very small probability of 1412 collision. Pseudo-random IPv4 ELAs can be generated through random 1413 assignment from a suitably large IPv4 prefix space. 1415 Consistent operational practices can assure uniqueness for EBG- 1416 aggregated addresses/prefixes, while statistical properties for 1417 pseudo-random address self-generation can assure uniqueness for the 1418 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 1419 ELA delegation authority should be used when available, while a 1420 passive in-service DAD mechanism should be used to detect ELA 1421 duplications when there is no ELA delegation authority. 1423 Appendix B. Change Log 1425 (Note to RFC editor - this section to be removed before publication 1426 as an RFC.) 1428 Changes from -32 to 33:: 1430 o Secure Neighbor Discovery Proxy 1432 Changes from -28 to 29: 1434 o Updates on processing/receiving errors. 1436 Changes from -27 to 28: 1438 o Introduced concept of a default mapper. 1440 Changes from -26 to 27: 1442 o Introduced new model for PI prefix management. 1444 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1445 "isado"?) 1447 Changes from -25 to 26: 1449 o Clarifications on Router Discovery and Ingress FIltering. 1451 o Mechanisms for detecting locator liveness 1453 o Mechanisms for avoiding state synchonization requirements. 1455 Changes from -23 to 24: 1457 o Clarifications on router discovery. 1459 Changes from -22 to 23: 1461 o Clarifications on prefix mapping. 1463 Changes from -21 to 22: 1465 o Using SEAL to secure VET 1467 Changes from -20 to 21: 1469 o Enterprise partitioning. 1471 o Mapping and name service management. 1473 Changes from -18 to 20: 1475 o Added support for simple hosts. 1477 o Added EBG name service maintenace procedures 1479 o Added router and prefix maintenace procedures 1481 Changes from -17 to 18: 1483 o adjusted section headings to group autoconf operations under EIR/ 1484 EBR/EBG. 1486 o clarified M/O bits 1488 o clarified EBG roles 1489 Changes from -15 to 17: 1491 o title change to "Virtual Enterprise Traversal (VET)". 1493 o changed document focus from MANET-centric to the much-broader 1494 Enterprise-centric, where "Enterprise" is understood to also cover 1495 a wide range of MANET types. 1497 Changes from -14 to 15: 1499 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1501 o Address review comments 1503 Changes from -12 to 14: 1505 o title change to "The MANET Virtual Ethernet Abstraction". 1507 o Minor section rearrangement. 1509 o Clartifications on portable and self-configured prefixes. 1511 o Clarifications on DHCPv6 prefix delegation procedures. 1513 Changes from -11 to 12: 1515 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1517 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1518 delegation mechanism. 1520 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1522 o fixed editorials based on comments received. 1524 Changes from -10 to 11: 1526 o removed the transparent/opaque VET portal abstractions. 1528 o removed routing header as an option for MANET exit router 1529 selection. 1531 o included IPv6 SLAAC as an endorsed address configuration mechanism 1532 for the VET interface. 1534 Changes from -08 to -09: 1536 o Introduced the term "VET". 1538 o Changed address delegation language to speak of "MNBR-aggregated" 1539 instead of global/local. 1541 o Updated figures 1-3. 1543 o Explained why a MANET interface is "neutral". 1545 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1546 DHCPv4 servers; not relays. 1548 Changes from -07 to -08: 1550 o changed terms "unenhanced" and "enhanced" to "transparent" and 1551 "opaque". 1553 o revised MANET Router diagram. 1555 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1556 interface. 1558 o changed abbreviations to "MNR" and "MNBR". 1560 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1562 o rearranged Section 3.1. 1564 o various minor text cleanups 1566 Changes from -06 to -07: 1568 o added MANET Router diagram. 1570 o added new references 1572 o various minor text cleanups 1574 Changed from -05 to -06: 1576 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1578 o minor changes to preserve generality 1580 Changed from -04 to -05: 1582 o introduced conceptual "virtual ethernet" model. 1584 o support "raw" and "cooked" modes as equivalent access methods on 1585 the virutal ethernet. 1587 Changed from -03 to -04: 1589 o introduced conceptual "imaginary shared link" as a representation 1590 for a MANET. 1592 o discussion of autonomous system and site abstractions for MANETs 1594 o discussion of autoconfiguration of CGAs 1596 o new appendix on IPv6 StateLess Address AutoConfiguration 1598 Changes from -02 to -03: 1600 o updated terminology based on RFC2461 "asymmetric reachability" 1601 link type; IETF67 MANET Autoconf wg discussions. 1603 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1604 Address Detection 1606 o relaxed DHCP server deployment considerations allow DHCP servers 1607 within the MANET itself 1609 Changes from -01 to -02: 1611 o minor updates for consistency with recent developments 1613 Changes from -00 to -01: 1615 o new text on DHCPv6 prefix delegation and multilink subnet 1616 considerations. 1618 o various editorial changes 1620 Author's Address 1622 Fred L. Templin (editor) 1623 Boeing Research and Technology 1624 P.O. Box 3707 MC 7L-49 1625 Seattle, WA 98124 1626 USA 1628 Email: fltemplin@acm.org