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