idnits 2.17.1 draft-templin-autoconf-dhcp-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1160. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1173. 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 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 (October 31, 2008) is 5656 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 152, but not defined == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 907, 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-07 == 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: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 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 Phantom Works 4 Intended status: Informational October 31, 2008 5 Expires: May 4, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-20.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 4, 2009. 35 Abstract 37 Enterprise networks connect routers over various link types, and may 38 also connect to provider networks and/or the global Internet. 39 Routers in enterprise networks must have a way to automatically 40 provision IP addresses/prefixes and other information, and must also 41 support post-autoconfiguration operations even for highly-dynamic 42 networks. This document specifies a Virtual Enterprise Traversal 43 (VET) abstraction for autoconfiguration and operation of routers in 44 enterprise networks. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 7 51 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 8 52 4.1. Enterprise Interior Router (EIR) Autoconfiguration . . . . 8 53 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 10 54 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 10 55 4.2.2. Inner IP Address/Prefix Delegation and Maintenance . . 11 56 4.2.3. Portable Inner IP Addresses/Prefixes . . . . . . . . . 13 57 4.2.4. Enterprise-edge Interface Autoconfiguration . . . . . 13 58 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 13 59 4.4. Simple Host Autoconfiguration . . . . . . . . . . . . . . 14 60 5. Post-Autoconfiguration Operation . . . . . . . . . . . . . . . 14 61 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 14 62 5.2. Router and Prefix Maintenance . . . . . . . . . . . . . . 14 63 5.3. Forwarding Packets to Destinations Outside of the 64 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 15 65 5.4. Source Address Verification . . . . . . . . . . . . . . . 15 66 5.5. Enterprise-Local Communications . . . . . . . . . . . . . 16 67 5.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.7. Service Discovery . . . . . . . . . . . . . . . . . . . . 16 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 73 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 77 Appendix A. Duplicate Address Detection (DAD) Considerations . . 21 78 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 Intellectual Property and Copyright Statements . . . . . . . . . . 26 82 1. Introduction 84 Enterprise networks [RFC4852] connect routers over various link types 85 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 86 (MANETs) [RFC2501] can be considered as a challenging example of an 87 enterprise network, in that their topologies may change dynamically 88 over time and that they may employ little/no active management by a 89 centralized network administrative authority. These specialized 90 characteristics for MANETs require careful consideration, but the 91 same principles apply equally to other enterprise network scenarios. 93 This document specifies a Virtual Enterprise Traversal (VET) 94 abstraction for autoconfiguration and runtime operation of enterprise 95 routers over various interface types, where addresses of different 96 scopes may be assigned on various types of interfaces with diverse 97 properties. Both IPv4 [RFC0791] and IPv6 [RFC2460] are discussed 98 within this context. The use of standard DHCP [RFC2131][RFC3315] and 99 neighbor discovery [RFC0826][RFC4861] mechanisms is assumed unless 100 otherwise specified. 102 Provider-edge Interfaces 103 x x x 104 | | | 105 +--------------------+---+--------+----------+ E 106 | | | | | n 107 | I | | .... | | t 108 | n +---+---+--------+---+ | e 109 | t | +--------+ /| | r 110 | e I x----+ | Host | I /*+------+--< p I 111 | r n | |Function| n|**| | r n 112 | n t | +--------+ t|**| | i t 113 | a e x----+ V e|**+------+--< s e 114 | l r . | E r|**| . | e r 115 | f . | T f|**| . | f 116 | V a . | +--------+ a|**| . | I a 117 | i c . | | Router | c|**| . | n c 118 | r e x----+ |Function| e \*+------+--< t e 119 | t s | +--------+ \| | e s 120 | u +---+---+--------+---+ | r 121 | a | | .... | | i 122 | l | | | | o 123 +--------------------+---+--------+----------+ r 124 | | | 125 x x x 126 Enterprise-edge Interfaces 128 Figure 1: Enterprise Router Architecture 130 Figure 1 above depicts the architectural model for an enterprise 131 router. As shown in the figure, an enterprise router may have a 132 variety of interface types including enterprise-edge, enterprise- 133 interior, provider-edge, internal-virtual, as well as VET interfaces 134 used for encapsulation of inner IP packets within outer IP headers. 135 The different types of interfaces are defined, and the 136 autoconfiguration mechanisms used for each type are specified. This 137 architecture applies equally for MANET routers, in which enterprise- 138 interior interfaces correspond to the wireless multihop radio 139 interfaces typically associated with MANETs. Out of scope for this 140 document is the autoconfiguration of provider interfaces, which must 141 be coordinated in a manner specific to the service provider's 142 network. 144 The VET specification represents a functional superset of 6over4 145 [RFC2529] and ISATAP [RFC5214], and further supports additional 146 encapsulations such as IPsec [RFC4301], SEAL [I-D.templin-seal], etc. 148 The VET principles can be either directly or indirectly traced to the 149 deliberations of the ROAD group in January 1992, and likely also to 150 still earlier works. [RFC1955] captures the high-level architectural 151 aspects of the ROAD group deliberations in a "New Scheme for Internet 152 Routing and Addressing [ENCAPS] for IPNG". 154 VET is related to the present-day activites of the IETF autoconf, 155 dhc, ipv6, manet and v6ops working groups. 157 2. Terminology 159 The mechanisms within this document build upon the fundamental 160 principles of IP-within-IP encapsulation. The terms "inner" and 161 "outer" are used throughout this document to respectively refer to 162 the innermost IP {address, protocol, header, packet, etc.} *before* 163 encapsulation, and the outermost IP {address, protocol, header, 164 packet, etc.} *after* encapsulation. VET also supports the inclusion 165 of "mid-layer" encapsulations between the inner and outer layers, 166 including IPSec [RFC4301], the Subnetwork Encapsulation and 167 Adaptation Layer (SEAL) [I-D.templin-seal], etc. 169 The terminology in the normative references apply; the following 170 terms are defined within the scope of this document: 172 subnetwork 173 the same as defined in [RFC3819]. 175 enterprise 176 the same as defined in [RFC4852]. 178 site 179 a logical and/or physical grouping of interfaces that connect a 180 topological area less than or equal to the enterprise in scope. A 181 site within an enterprise can be considered as an enterprise unto 182 itself. 184 Mobile Ad-hoc Network (MANET) 185 a connected topology of mobile or fixed routers that maintain a 186 routing structure among themselves over MANET link types 187 [I-D.clausen-manet-linktype], where a wide variety of MANETs share 188 common properties with enterprise networks. Further information 189 on MANETs can be found in [RFC2501]. 191 enterprise/site/MANET 192 throughout the remainder of this document, the term "enterprise" 193 is used to collectively refer to any of enterprise/site/MANET, 194 i.e., the VET mechanisms and operational principles apply equally 195 to enterprises, sites and MANETs. 197 enterprise router 198 an Enterprise Interior Router, Enterprise Border Router, or 199 Enterprise Border Gateway. For the purose of this specification, 200 an enterprise router comprises a router function, a host function, 201 one or more enterprise-interior interfaces and zero or more 202 internal virtual, enterprise-edge, provider-edge and VET 203 interfaces. 205 Enterprise Interior Router (EIR) 206 a fixed or mobile enterprise router that forwards packets over a 207 set of enterprise-interior interfaces connected to the same 208 enterprise. 210 Enterprise Border Router (EBR) 211 an EIR that connects edge networks to the enterprise, and/or 212 connects multiple enterprises together. An EBR configures a 213 seperate VET interface over each set of enterprise-interior 214 interfaces that connect the EBR to each distinct enterprise, i.e., 215 an EBR may configure mulitple VET interfaces - one for each 216 distinct enterprise. All EBRs are also EIRs. 218 Enterprise Border Gateway (EBG) 219 an EBR that either directly or indirectly connects the enterprise 220 to provider networks and can delegate addresses/prefixes to other 221 EBRs within the enterprise. All EBGs are also EBRs. 223 internal-virtual interface 224 a virtual interface that is a special case of either an 225 enterprise-edge or an enterprise-interior interface. Internal- 226 virtual interfaces that are also enterprise-edge interfaces are 227 often loopback interfaces of some form. Internal-virtual 228 interfaces that are also enterprise-interior interfaces are often 229 tunnel interfaces of some form configured over another enterprise- 230 interior interface. 232 enterprise-edge interface 233 an EBR's attachment to a link (e.g., an ethernet, a wireless 234 personal area network, etc.) on an arbitrarily-complex edge 235 network that the EBR connects to an enterprise and/or to provider 236 networks. 238 provider-edge interface 239 an EBR's attachment to the Internet, or to a provider network 240 outside of the enterprise via which the Internet can be reached. 242 enterprise-interior Interface 243 a EIR's attachment to a link within an enterprise. An enterprise- 244 interior interface is "neutral" in its orientation, i.e., it is 245 inherently neither an enterprise-edge nor provider-edge interface. 246 In particular, a packet may need to be forwarded over several 247 enterprise-interior interfaces before it is forwarded via either 248 an enterprise-edge or provider-edge interface. 250 Enterprise Local Address (ELA) 251 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 252 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 253 is assigned to an enterprise-interior interface and unique within 254 the enterprise. ELAs are used as identifiers for operating the 255 routing protocol and/or locators for packet forwarding within the 256 scope of the enterprise; ELAs are also used as *outer* IP 257 addresses during encapsulation. 259 Virtual Enterprise Traversal (VET) 260 an abstraction that uses IP-in-IP encapsulation to span a multi- 261 link enterprise in a single (inner) IP hop. 263 VET interface 264 an EBR's Non-Broadcast, Multiple Access interface used for Virtual 265 Enterprise Traversal. The EBR configures a VET interface over a 266 set of underlying enterprise-interior interface(s) belonging to 267 the same enterprise. When there are multiple distinct enterprises 268 (each with their own distinct set of enterprise-interior 269 interfaces), the EBR configures a separate VET interface over each 270 set of enterprise-interior interfaces, i.e., the EBR configures 271 multiple VET interfaces. 273 The VET interface encapsulates each inner IP packet in any mid- 274 layer headers plus an outer IP header then forwards it on an 275 underlying enterprise-interior interface such that the TTL/Hop 276 Limit in the inner header is not decremented as the packet 277 traverses the enterprise. The VET interface presents an automatic 278 tunneling abstraction that represents the enterprise as a single 279 IP hop. 281 The following additional acronyms are used throughout the document: 283 CGA - Cryptographically Generated Address 284 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 285 IP[v4,v6] - the Internet Protocol 286 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 287 ND - Neighbor Discovery 288 PIO - Prefix Information Option 289 PRL - Potential Router List 290 RIO - Route Information Option 291 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 292 SEAL - Subnetwork Encapsulation and Adaptation Layer 293 SLAAC - IPv6 StateLess Address AutoConfiguation 295 3. Enterprise Characteristics 297 Enterprises consist of simple hosts on links that are connected by 298 enterprise routers as depicted in Figure 1. All enterprise routers 299 are also Enterprise Interior Routers (EIRs) that typically 300 participate in a routing protocol over enterprise-interior interfaces 301 to discover routes that may include multiple Layer-2 or Layer-3 302 forwarding hops. Enterprise Border Routers (EBRs) are EIRs that 303 connect edge networks and/or join multiple enterprises together, 304 while Enterprise Border Gateways (EBGs) are EBRs that either directly 305 or indirectly connect enterprises to provider networks. An 306 enterprise may be as simple as a small collection of enterprise 307 routers (and their attached edge networks); an enterprise may also 308 contain other enterprises/sites and/or be a subnetwork of a larger 309 enterprise. An enterprise may further encompass a set of branch 310 offices and/or nomadic hosts connected to a home office over one or 311 several service providers, e.g., through Virtual Private Network 312 (VPN) tunnels. 314 Enterprises that comprise homogeneous link types within a single IP 315 subnet can configure the routing protocol to operate as a sub-IP 316 layer mechanism such that IP sees the enterprise as an ordinary 317 shared link the same as for a (bridged) campus LAN. In that case, a 318 single IP hop is sufficient to traverse the enterprise without IP 319 layer encapsulation. 321 Enterprises that comprise heterogeneous link types and/or multiple IP 322 subnets must also provide a routing service that operates as an IP 323 layer mechanism, e.g., to accommodate media types with dissimilar 324 Layer-2 address formats and maximum transmission units (MTUs). In 325 that case, multiple IP hops may be necessary to traverse the 326 enterprise such that specific autoconfiguration procedures are 327 necessary to avoid multilink subnet issues [RFC4903]. In particular, 328 we describe herein the use of IP-in-IP encapsulation to span the 329 enterprise in a single (inner) IP hop in order to avoid the multilink 330 subnet issues that arise when enterprise-interior interfaces are used 331 directly by applications. 333 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 334 both a host function and router function. The host function supports 335 global-scoped communications over any of the enterprise router's non- 336 enterprise-interior interfaces according to the weak end system model 337 [RFC1122] and also supports enterprise-local-scoped communications 338 over its enterprise-interior interfaces. The router function 339 connects the enterprise router's attached edge networks to the 340 enterprise and/or connects the enterprise to other networks including 341 the Internet (see: Figure 1). 343 In addition to other interface types, EBRs configure VET interfaces 344 that view all other EBRs in an enterprise as single-hop neighbors, 345 where the enterprise can also appear as a single IP hop within 346 another enterprise. EBRs configure a separate VET interface for each 347 distinct enterprise to which they connect, and discover a list of 348 EBRs for each VET interface that can be used for forwarding packets 349 to off-enterprise destinations. The following sections present the 350 Virtual Enterprise Traversal approach. 352 4. Autoconfiguration 354 EIRs configure enterprise-interior interfaces. An EBR is an EIR that 355 also configures enterprise-edge and VET interfaces. An EBG is an EBR 356 that also either directly or indirectly connects the enterprise to a 357 provider network. EIRs, EBRs and EBGs configure themselves for 358 operation according to the following subsections: 360 4.1. Enterprise Interior Router (EIR) Autoconfiguration 362 EIRs configure enterprise-interior interfaces and engage in routing 363 protocols over those interfaces. 365 When an EIR joins an enterprise, it first configures a unique IPv6 366 link-local address on each enterprise-interior interface that 367 requires an IPv6 link-local capability and an IPv4 link-local address 368 on each enterprise-interior interface that requires an IPv4 link- 369 local capability. IPv6 link-local address generation mechanisms that 370 provide sufficient uniqueness include Cryptographically Generated 371 Addresses (CGAs) [RFC3972], StateLess Address AutoConfiguration 372 (SLAAC) using EUI-64 interface identifiers [RFC4862], etc. The 373 mechanisms specified in [RFC3927] provide an IPv4 link-local address 374 generation capability. 376 Next, the EIR configures an Enterprise Local Address (ELA) of the 377 outer IP protocol version on each of its enterprise-interior 378 interfaces and engages in any routing protocols on those interfaces. 379 The EIR can configure an ELA via explicit management, DHCP 380 autoconfiguration, pseudo-random self-generation from a suitably 381 large address pool, or through an alternate autoconfiguration 382 mechanism. 384 DHCP configuration of ELAs may require support from relays within the 385 enterprise that have already autoconfigured an ELA as well as an 386 enterprise-wide multicast forwarding capability. For DHCPv6, relays 387 that do not already know the ELA of a server relay requests to the 388 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 389 relays that do not already know the ELA of a server relay requests to 390 the site-scoped IPv4 multicast group address TBD (see: Section 6). 391 DHCPv4 servers that delegate ELAs join the TBD multicast group and 392 service any DHCPv4 messages received for that group. 394 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 395 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 396 generation of ELAs for IPv4 can be from a large IPv4 private address 397 range, e.g., [I-D.fuller-240space]. When self-generation is used 398 alone, the EIR must continuously monitor the ELAs for uniqueness, 399 e.g., by monitoring the routing protocol, sending beacons, etc. 400 (This continuous monitoring process is sometimes known as "in-service 401 duplicate address detection"). 403 A combined approach using both DHCP and self-generation is also 404 possible. In this combined approach, the EIR first self-generates a 405 temporary ELA which it will use only for the purpose of procuring an 406 actual ELA from a DHCP server. Acting as a combined client/relay, 407 the EIR then assigns the temporary ELA to an enterprise-interior 408 interface, engages in the routing protocol and performs a relay- 409 server exchange using the temporary ELA as an address for the relay. 410 When the DHCP server delegates an actual ELA, the EIR abandons the 411 temporary ELA, assigns the actual ELA to the enterprise-interior 412 interface and re-engages in the routing protocol. Note that the 413 range of ELAs delegated by a DHCP server must be disjoint from the 414 range of ELAs used by the EIR for self-generation. 416 4.2. Enterprise Border Router (EBR) Autoconfiguration 418 EBRs are EIRs that configure enterprise-edge interfaces, and also 419 configure a VET interface over a set of underlying enterprise- 420 interior interfaces belonging to the same enterprise. Note that an 421 EBR may connect to multiple distinct enterprises, in which case it 422 would configure multiple VET interfaces over multiple distinct sets 423 of enterprise-interior interfaces. EBRs perform the following 424 autoconfiguration operations: 426 4.2.1. VET Interface Autoconfiguration 428 VET interface autoconfiguration entails: 1) interface initialization, 429 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 430 address autoconfiguration. These functions are specified in the 431 following sections: 433 4.2.1.1. Interface Initialization 435 EBRs configure a VET interface over a set of underlying enterprise- 436 interior interfaces belonging to the same enterprise, where the VET 437 interface presents a virtual view of all EBRs in the enterprise as 438 single hop neighbors through the use of IP-in-IP encapsulation. 440 When IPv6 and IPv4 are used as the inner/outer protocols 441 (respectively), the EBR autoconfigures an ISATAP link-local address 442 ([RFC5214], Section 6.2) on the VET interface to support packet 443 forwarding and operation of the IPv6 neighbor discovery protocol. 444 The ISATAP link-local address embeds an IPv4 ELA assigned to an 445 underlying enterprise-interior interface, and need not be checked for 446 uniqueness since the IPv4 ELA itself was already determined to be 447 unique. Link-local address configuration for other inner/outer IP 448 protocol combinations is through administrative configuration or 449 through an unspecified alternate method. 451 After the EBR configures a VET interface, it can communicate with 452 other EBRs as single-hop neighbors. It can also confirm reachability 453 of other EBRs through Neighbor Discovery (ND) and/or DHCP exchanges 454 over the VET interface, or through other means such as information 455 conveyed in the routing protocol. 457 The EBR must be able to detect and recover from the loss of VET 458 interface neighbors due to e.g., enterprise network partitions, node 459 failures, etc. Mechanisms specified outside of this document such as 460 monitoring the routing protocol, ND beaconing/polling, DHCP renewals/ 461 leasequeries, upper layer protocol hints of forward progress, 462 bidirectional forward detection, detection of network attachment, 463 etc. can be used according to the particular deployment scenario. 465 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 466 Identification 468 After the EBR configures its VET interfaces, it next discovers a list 469 of EBGs for each distinct enterprise to which it connects. The list 470 can be discovered through information conveyed in the routing 471 protocol and/or through the Potential Router List (PRL) discovery 472 mechanisms outlined in [RFC5214], Section 8.3.2. 474 In particular, whether or not routing information is available the 475 EBR can discover the list of EBGs by resolving an identifying name 476 for the enterprise using an enterprise local name resolution service 477 (e.g., and enterprise-wide DNS service, LLMNR [RFC4759], etc.). In 478 the absence of other identifying names, the EBR can resolve either 479 the hostname "6over4" or the FQDN "6over4.example.com" (i.e., if an 480 enterprise specific suffix "example.com" is known) for multicast 481 capable enterprises. For non-multicast enterprises, the EBR can 482 instead resolve the hostname "isatap" or the FQDN 483 "isatap.example.com". 485 Identifying names along with addresses of EBGs and/or the prefixes 486 they aggregate serve as an identifier for the enterprise. 488 4.2.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) 490 When IPv6 is used as the inner protocol, the EBR sends unicast IPv6 491 Router Solicitation (RS) messages over its VET interface(s) to 492 receive Router Advertisements (RAs) from EBGs. When the EBR receives 493 an RA containing Prefix Information Options (PIOs) with the 'A' and 494 'L' bits set to 1, it autoconfigures IPv6 addresses from the prefixes 495 using SLAAC and assigns them to the VET interface. (When IPv4 is 496 used as the outer IP protocol, the addresses are autoconfigured and 497 assigned as ISATAP addresses the same as specified in [RFC5214].) 499 The use of DHCPv6 for address configuration on VET interfaces is not 500 specified in this document. 502 4.2.2. Inner IP Address/Prefix Delegation and Maintenance 504 EBRs acquire inner IP protocol addresses and/or prefix delegations 505 through autoconfiguration exchanges via EBGs over VET interfaces, as 506 discussed in the following sections: 508 4.2.2.1. IPv4 Addresses/Prefix Delegation 510 When IPv4 is used as the inner IP protocol, the EBR coordinates with 511 EBGs to acquire IPv4 prefixes for sub-delegation and/or assignment on 512 its enterprise-edge interfaces. This coordination can be through 513 explicit management, or through an unspecified automated prefix 514 delegation exchange. 516 4.2.2.2. IPv6 Addresses/Prefix Delegation 518 If the EBR receives an RA from an EBG that also contains PIOs with 519 the 'L' bit set to 0, it can use the PIOs as hints of prefixes a 520 DHCPv6 server reachable via the EBG is willing to delegate (see: 521 Section 4.3). Whether or not such hints are available, the EBR 522 (acting as a requesting router) can use DHCPv6 prefix delegation 523 [RFC3633] over the VET interface to obtain IPv6 prefixes from the 524 server (acting as a delegating router). The EBR can then use the 525 delegated prefixes for sub-delegation on enterprise-edge networks 526 and/or assignment on its enterprise-edge interfaces. 528 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 529 exchange [RFC3315]. For example, to perform the 2-message exchange a 530 DHCPv6 client associated with the EBR's host function forwards a 531 Solicit message with an IA_PD option to a DHCPv6 relay associated 532 with its router function, i.e., the EBR acts as both client and 533 relay. The relay then forwards the message over the VET interface to 534 the server via the EBG. The forwarded Solicit message will elicit a 535 Reply from the server containing IPv6 prefix delegations. 537 The EBR can also propose a specific prefix to the DHCPv6 server per 538 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 539 available. The server will check the proposed prefix for consistency 540 and uniqueness, then return it in the reply to the EBR if it was able 541 to perform the delegation. The EBR can use mechanisms such as CGAs 542 [RFC3972], IPv6 privacy address [RFC4941], etc. to self-generate 543 addresses in conjunction with prefix delegation. 545 4.2.2.3. Prefix and Route Maintenance 547 When DHCP prefix delegation is used, the DHCP server ensures that the 548 delegations are unique and that the EBG's router function will 549 forward IP packets over the VET interface to the EBR to which the 550 prefix was delegated. The prefix delegation remains active as long 551 as the EBR continues to issue renewals over the VET interface before 552 the lease lifetime expires. The lease lifetime also keeps the 553 delegation state active even if communications between the EBR and 554 DHCP server is disrupted for a period of time (e.g., due to an 555 enterprise network partition) before being reestablished (e.g., due 556 to an enterprise network merge). EBRs can also sub-delegate inner IP 557 prefixes to requesting routers on networks connected on their 558 enterprise-edge interfaces as well as to EBRs in other enterprises. 560 Since the DHCP client and relay are co-resident on the same EBR, no 561 special coordination is necessary for the EBG to maintain routing 562 information. The EBG simply retains forwarding information base 563 entries that identify the EBR as the next-hop toward the prefix over 564 the VET interface, and issues ordinary redirects over the VET 565 interface when necessary . 567 4.2.3. Portable Inner IP Addresses/Prefixes 569 Independent of any inner IP addresses/prefix delegations (see: 570 Section 4.2.2), an EBR can also use portable IP addresses/prefixes 571 (e.g., taken from a home network) and/or self-configured IP 572 addresses/prefixes (e.g., IPv6 Unique Local Addresses (ULAs) 573 [RFC4193][I-D.ietf-ipv6-ula-central]). The EBR can continue to use 574 these addresses/prefixes as it travels between visited enterprise 575 networks as long as it coordinates in some fashion with a mapping 576 agent, prefix aggregation authority, etc. EBRs can also sub-delegate 577 portable (and other self-configured) prefixes to requesting routers 578 on networks connected on their enterprise-edge interfaces as well as 579 to EBRs in other enterprises. 581 4.2.4. Enterprise-edge Interface Autoconfiguration 583 After the EBR receives inner IP address/prefix delegations (see: 584 Section 4.2.2), it can assign them on enterprise-edge interfaces 585 only; it does not assign them on provider-edge, VET, or enterprise- 586 interior interfaces (see: [RFC3633], Section 12.1). Similarly, the 587 EBR can assign portable and/or self-configured addresses/prefixes 588 (see: Section 4.2.3) on enterprise-edge interfaces. 590 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 592 EBGs are EBRs that connect an enterprise to a service provider either 593 directly via provider-edge interfaces or indirectly via another 594 enterprise. EBGs configure provider-edge interfaces in a manner that 595 is specific to its provider connections. EBGs should also configure 596 a DHCP relay/server that can service prefix delegation requests from 597 EBRs. 599 For IPv6, EBGs send RAs over VET interfaces on enterprises for which 600 they are gateways with PIOs for SLAAC, with the 'M' flag set to 0 and 601 with the 'O' flag set to indicate whether "other" DHCP services are 602 available. EBGs can also include PIOs with the 'L' bit set to 0 and 603 with a prefix such as 2001:DB8::/48 as a hint of an aggregated prefix 604 from which it is willing to delegate longer prefixes. 606 EBGs must arrange to add their enterprise-interior interface 607 addresses to the enterprise name service resource records used for 608 Enterprise Border Gateway discovery (see: Section 4.2.1.2), and must 609 maintain these resource records in accordance with ( [RFC5214], 610 Section 9). EBGs add their enterprise-interior interface addresses 611 to the hostname "isatap" and/or the FQDN "isatap.example.com"; EBGs 612 that connect to multicast-capable enterprises additionally add these 613 addresses to the hostname "6over4" and/or the FQDN 614 "6over4.example.com". 616 4.4. Simple Host Autoconfiguration 618 Simple hosts that cannot be attached via an EBR's enterprise-edge 619 interface (e.g., nomadic laptops that connect to a home office via a 620 Virtual Private Network (VPN)) can instead be configured for 621 operation as a simple host over the VET interface. Such hosts 622 configure one or more VET interfaces over corresponding sets of 623 enterprise-interior interfaces exactly as for EBRs, but they do not 624 configure a router function nor provide packet forwarding services 625 for nodes on enterprise-edge interfaces. Simple hosts can then send 626 packets over their VET interfaces to other simple hosts within the 627 enterprise, or to off-enterprise destinations via a next-hop EBR. 629 5. Post-Autoconfiguration Operation 631 The following sections discuss post-autoconfiguration operations: 633 5.1. Routing Protocol Participation 635 After an EIR has been autoconfigured, it participates in any routing 636 protocols over enterprise-interior interfaces and forwards outer IP 637 packets within the enterprise as for any ordinary router. 639 EBRs can additionally engage in any inner IP routing protocols over 640 enterprise-edge, provider-edge and VET interfaces, and can use those 641 interfaces for forwarding inner IP packets to off-enterprise 642 destinations. Note that these inner IP routing protocols are 643 separate and distinct from any enterprise-interior routing protocols. 645 5.2. Router and Prefix Maintenance 647 Simple hosts and EBRs follow the router and prefix maintenance 648 procedures specified in ([RFC5214], Section 8.3). 650 Simple hosts and EBRs that use IPv6 as the inner protocol can 651 discover default router lifetimes, default router preferences and 652 more-specific routes [RFC4191] by sending an RS over the VET 653 interface to elicit an RA from an EBR/EBG. 655 Simple hosts and EBRs must only accept PIOs, M/O flag settings and 656 default router preferences in RAs that are received from EBGs (i.e., 657 and not from ordinary EBRs). 659 5.3. Forwarding Packets to Destinations Outside of the Enterprise 661 After default and/or more-specific routes are discovered, simple 662 hosts and EBRs can forward IP packets to off-enterprise destinations 663 via a specific EBR/EBG as the next-hop router on the VET interface. 664 When multiple next-hop routers are available, the host/EBR can use 665 default router preferences, routing protocol information, traffic 666 engineering configurations, etc. to select the best exit router. 668 Simple hosts and EBRs consult the inner IP forwarding table to 669 determine the next hop address (e.g., the VET interface address of 670 another EBR) for forwarding packets to destinations outside of the 671 enterprise. When there is no forwarding information available, the 672 host/EBR can discover the next-hop through FQDN or reverse lookup 673 using the same name resolution services as for EBG discovery (see: 674 Section 4.2.1.2). 676 Simple hosts and ERBRs encapsulate inner IP packets forwarded over 677 the VET interface in any mid-layer headers followed by an outer IP 678 header according to the specific encapsulation type (e.g., 679 [RFC4301][RFC5214][I-D.templin-seal]), then submit the encapsulated 680 packet to the outer IP forwarding engine for transmission on an 681 underlying enterprise-interior interface. For forwarding to next-hop 682 addresses over VET interfaces that use IPv6-in-IPv4 encapsulation, 683 simple hosts and EBRs determine the outer destination address through 684 static extraction of the IPv4 address embedded in the next-hop ISATAP 685 address. For other IP-in-IP encapsulations, determination of the 686 outer destination address is through administrative configuration or 687 through an unspecified alternate method. 689 5.4. Source Address Verification 691 Simple hosts and EBRs must verify that the outer IP source address of 692 a packet received on a VET interface is correct for the inner IP 693 source address using the procedures specified in ( [RFC5214], Section 694 7.3). 696 5.5. Enterprise-Local Communications 698 When permitted by policy, end systems that configure the endpoints of 699 an enterprise-local communications session can avoid VET interface 700 encapsulation by directly invoking the outer IP protocol using ELAs 701 assigned to their enterprise-interior interfaces. For example, when 702 the outer protocol is IPv4, end systems can use IPv4 ELAs for 703 enterprise-local communications over their enterprise-interior 704 interfaces without using the VET interface. 706 5.6. Multicast 708 In multicast-capable deployments, EIRs provide an enterprise-wide 709 multicasting service such as Simplified Multicast Forwarding (SMF) 710 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 711 that outer IP multicast messages of site- or greater scope will be 712 propagated across the enterprise. For such deployments, simple hosts 713 and EBRs can also provide an inner IP multicast/broadcast capability 714 over their VET interfaces through mapping of the inner IP multicast 715 address space to the outer IP multicast address space. 717 SImple hosts and EBRs encapsulate inner IP multicast messages sent 718 over the VET interface in any mid-layer headers (e.g., IPsec, SEAL, 719 etc.) plus an outer IP header with a site-scoped outer IP multicast 720 address as the destination. For the case of IPv6 and IPv4 as the 721 inner/outer protocols (respectively), [RFC2529] provides mappings 722 from the IPv6 multicast address space to the IPv4 multicast address 723 space. For other IP-in-IP encapsulations, mappings are established 724 through administrative configuration or through an unspecified 725 alternate method. 727 For multicast-capable enterprises, use of the inner IP multicast 728 service for operating the ND protocol over the VET interface is 729 available but should be used sparingly to minimize enterprise-wide 730 flooding. Therefore, EBRs should use unicast ND services over the 731 VET interface instead of multicast whenever possible. 733 5.7. Service Discovery 735 Simple hosts and EBRs can peform enterprise-wide service discovery 736 using a suitable name-to-address resolution service. Examples of 737 flooding-based services include the use of LLMNR [RFC4759] over the 738 VET interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 739 underlying enterprise-interior interface. More scalable and 740 efficient service discovery mechanisms are for further study. 742 6. IANA Considerations 744 A Site-Local Scope IPv4 multicast group (TBD) for DHCPv4 server 745 discovery is requested. The allocation should be taken from the 746 239.255.000.000-239.255.255.255 Site-Local Scope range in the IANA 747 'multicast-addresses' registry. 749 7. Security Considerations 751 Security considerations for MANETs are found in [RFC2501]. 753 Security considerations with tunneling that apply also to VET are 754 found in [RFC2529][RFC5214]. 756 8. Related Work 758 The authors acknowledge the work done by Brian Carpenter and Cyndi 759 Jung in [RFC2529] that introduced the concept of intra-site automatic 760 tunneling. This concept was later called: "Virtual Ethernet" and 761 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 762 As for this document, these architectural principles also follow from 763 earlier works articulated by the ROAD group deliberations of 1992. 765 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 766 program. The Naval Research Lab (NRL) Information Technology 767 Division uses DHCP in their MANET research testbeds. Various 768 proposals within the IETF have suggested similar mechanisms. 770 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 771 regarding tunneling mechanisms that may subvert security through 772 Network Address Translator (NAT) traversal. 774 An automated IPv4 prefix delegation mechanism is proposed in 775 [I-D.ietf-dhc-subnet-alloc]. 777 9. Acknowledgements 779 The following individuals gave direct and/or indirect input that was 780 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 781 Bound, Thomas Clausen, Bob Hinden, Joe Macker, Thomas Narten, 782 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole 783 Troan, Michaela Vanderveen and others in the IETF AUTOCONF and MANET 784 working groups. Many others have provided guidance over the course 785 of many years. 787 10. Contributors 789 The following individuals have contributed to this document: 791 Eric Fleischman (eric.fleischman@boeing.com) 792 Thomas Henderson (thomas.r.henderson@boeing.com) 793 Steven Russert (steven.w.russert@boeing.com) 794 Seung Yi (seung.yi@boeing.com) 796 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 797 of the document. 799 11. References 801 11.1. Normative References 803 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 804 September 1981. 806 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 807 converting network protocol addresses to 48.bit Ethernet 808 address for transmission on Ethernet hardware", STD 37, 809 RFC 826, November 1982. 811 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 812 RFC 2131, March 1997. 814 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 815 (IPv6) Specification", RFC 2460, December 1998. 817 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 818 and M. Carney, "Dynamic Host Configuration Protocol for 819 IPv6 (DHCPv6)", RFC 3315, July 2003. 821 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 822 Host Configuration Protocol (DHCP) version 6", RFC 3633, 823 December 2003. 825 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 826 More-Specific Routes", RFC 4191, November 2005. 828 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 829 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 830 September 2007. 832 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 833 Address Autoconfiguration", RFC 4862, September 2007. 835 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 836 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 837 March 2008. 839 11.2. Informative References 841 [I-D.cheshire-dnsext-multicastdns] 842 Cheshire, S. and M. Krochmal, "Multicast DNS", 843 draft-cheshire-dnsext-multicastdns-07 (work in progress), 844 September 2008. 846 [I-D.clausen-manet-linktype] 847 Clausen, T., "The MANET Link Type", 848 draft-clausen-manet-linktype-00 (work in progress), 849 October 2008. 851 [I-D.fuller-240space] 852 Fuller, V., "Reclassifying 240/4 as usable unicast address 853 space", draft-fuller-240space-02 (work in progress), 854 March 2008. 856 [I-D.ietf-autoconf-manetarch] 857 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 858 Network Architecture", draft-ietf-autoconf-manetarch-07 859 (work in progress), November 2007. 861 [I-D.ietf-dhc-subnet-alloc] 862 Johnson, R., "Subnet Allocation Option", 863 draft-ietf-dhc-subnet-alloc-07 (work in progress), 864 July 2008. 866 [I-D.ietf-ipv6-ula-central] 867 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 868 Addresses", draft-ietf-ipv6-ula-central-02 (work in 869 progress), June 2007. 871 [I-D.ietf-manet-smf] 872 Macker, J. and S. Team, "Simplified Multicast Forwarding 873 for MANET", draft-ietf-manet-smf-07 (work in progress), 874 February 2008. 876 [I-D.ietf-v6ops-tunnel-security-concerns] 877 Hoagland, J., Krishnan, S., and D. Thaler, "Security 878 Concerns With IP Tunneling", 879 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 880 progress), October 2008. 882 [I-D.templin-seal] 883 Templin, F., "The Subnetwork Encapsulation and Adaptation 884 Layer (SEAL)", draft-templin-seal-23 (work in progress), 885 August 2008. 887 [RFC1122] Braden, R., "Requirements for Internet Hosts - 888 Communication Layers", STD 3, RFC 1122, October 1989. 890 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 891 E. Lear, "Address Allocation for Private Internets", 892 BCP 5, RFC 1918, February 1996. 894 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 895 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 897 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 898 (MANET): Routing Protocol Performance Issues and 899 Evaluation Considerations", RFC 2501, January 1999. 901 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 902 Domains without Explicit Tunnels", RFC 2529, March 1999. 904 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 905 via IPv4 Clouds", RFC 3056, February 2001. 907 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 908 RFC 3753, June 2004. 910 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 911 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 912 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 913 RFC 3819, July 2004. 915 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 916 Configuration of IPv4 Link-Local Addresses", RFC 3927, 917 May 2005. 919 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 920 RFC 3972, March 2005. 922 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 923 Addresses", RFC 4193, October 2005. 925 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 926 Internet Protocol", RFC 4301, December 2005. 928 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 929 Indicator Parameter for the "tel" URI", RFC 4759, 930 December 2006. 932 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 933 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 934 Focus", RFC 4852, April 2007. 936 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 937 June 2007. 939 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 940 Extensions for Stateless Address Autoconfiguration in 941 IPv6", RFC 4941, September 2007. 943 Appendix A. Duplicate Address Detection (DAD) Considerations 945 A-priori uniqueness determination (also known as "pre-service DAD") 946 for an ELA assigned on an enterprise-interior interface (such as 947 specified in [RFC4862]) would require either flooding the entire 948 enterprise or somehow discovering a link in the enterprise on which a 949 node that configures a duplicate address is attached and performing a 950 localized DAD exchange on that link. But, the control message 951 overhead for such an enterprise-wide DAD would be substantial and 952 prone to false-negatives due to packet loss and intermittent 953 connectivity. An alternative to pre-service DAD is to autoconfigure 954 pseudo-random ELAs on enterprise-interior interfaces and employ a 955 passive in-service DAD (e.g., one that monitors routing protocol 956 messages for duplicate assignments). 958 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 959 CGAs, IPv6 privacy addresses, etc. with very small probability of 960 collision. Pseudo-random IPv4 ELAs can be generated through random 961 assignment from a suitably large IPv4 prefix space, e.g., the soon- 962 to-be-reclassified 240/4 space [I-D.fuller-240space]. 964 Consistent operational practices can assure uniqueness for EBG- 965 aggregated addresses/prefixes, while statistical properties for 966 pseudo-random address self-generation can assure uniqueness for the 967 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 968 ELA delegation authority should be used when available, while a 969 passive in-service DAD mechanism should be used to detect ELA 970 duplications when there is no ELA delegation authority. 972 Appendix B. Change Log 974 (Note to RFC editor - this section to be removed before publication 975 as an RFC.) 977 Changes from -18 to 20: 979 o Added support for simple hosts. 981 o Added EGBG name service maintenace procedures 983 o Added router and prefix maintenace procedures 985 Changes from -17 to 18: 987 o adjusted section headings to group autoconf operations under EIR/ 988 EBR/EBG. 990 o clarified M/O bits 992 o clarified EBG roles 994 Changes from -15 to 17: 996 o title change to "Virtual Enterprise Traversal (VET)". 998 o changed document focus from MANET-centric to the much-broader 999 Enterprise-centric, where "Enterprise" is understood to also cover 1000 a wide range of MANET types. 1002 Changes from -14 to 15: 1004 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1006 o Address review comments 1008 Changes from -12 to 14: 1010 o title change to "The MANET Virtual Ethernet Abstraction". 1012 o Minor section rearrangement. 1014 o Clartifications on portable and self-configured prefixes. 1016 o Clarifications on DHCPv6 prefix delegation procedures. 1018 Changes from -11 to 12: 1020 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1022 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1023 delegation mechanism. 1025 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1027 o fixed editorials based on comments received. 1029 Changes from -10 to 11: 1031 o removed the transparent/opaque VET portal abstractions. 1033 o removed routing header as an option for MANET exit router 1034 selection. 1036 o included IPv6 SLAAC as an endorsed address configuration mechanism 1037 for the VET interface. 1039 Changes from -08 to -09: 1041 o Introduced the term "VET". 1043 o Changed address delegation language to speak of "MNBR-aggregated" 1044 instead of global/local. 1046 o Updated figures 1-3. 1048 o Explained why a MANET interface is "neutral". 1050 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1051 DHCPv4 servers; not relays. 1053 Changes from -07 to -08: 1055 o changed terms "unenhanced" and "enhanced" to "transparent" and 1056 "opaque". 1058 o revised MANET Router diagram. 1060 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1061 interface. 1063 o changed abbreviations to "MNR" and "MNBR". 1065 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1067 o rearranged Section 3.1. 1069 o various minor text cleanups 1071 Changes from -06 to -07: 1073 o added MANET Router diagram. 1075 o added new references 1077 o various minor text cleanups 1079 Changed from -05 to -06: 1081 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1083 o minor changes to preserve generality 1085 Changed from -04 to -05: 1087 o introduced conceptual "virtual ethernet" model. 1089 o support "raw" and "cooked" modes as equivalent access methods on 1090 the virutal ethernet. 1092 Changed from -03 to -04: 1094 o introduced conceptual "imaginary shared link" as a representation 1095 for a MANET. 1097 o discussion of autonomous system and site abstractions for MANETs 1099 o discussion of autoconfiguration of CGAs 1101 o new appendix on IPv6 StateLess Address AutoConfiguration 1103 Changes from -02 to -03: 1105 o updated terminology based on RFC2461 "asymmetric reachability" 1106 link type; IETF67 MANET Autoconf wg discussions. 1108 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1109 Address Detection 1111 o relaxed DHCP server deployment considerations allow DHCP servers 1112 within the MANET itself 1114 Changes from -01 to -02: 1116 o minor updates for consistency with recent developments 1118 Changes from -00 to -01: 1120 o new text on DHCPv6 prefix delegation and multilink subnet 1121 considerations. 1123 o various editorial changes 1125 Author's Address 1127 Fred L. Templin (editor) 1128 Boeing Phantom Works 1129 P.O. Box 3707 MC 7L-49 1130 Seattle, WA 98124 1131 USA 1133 Email: fltemplin@acm.org 1135 Full Copyright Statement 1137 Copyright (C) The IETF Trust (2008). 1139 This document is subject to the rights, licenses and restrictions 1140 contained in BCP 78, and except as set forth therein, the authors 1141 retain all their rights. 1143 This document and the information contained herein are provided on an 1144 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1145 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1146 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1147 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1148 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1149 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1151 Intellectual Property 1153 The IETF takes no position regarding the validity or scope of any 1154 Intellectual Property Rights or other rights that might be claimed to 1155 pertain to the implementation or use of the technology described in 1156 this document or the extent to which any license under such rights 1157 might or might not be available; nor does it represent that it has 1158 made any independent effort to identify any such rights. Information 1159 on the procedures with respect to rights in RFC documents can be 1160 found in BCP 78 and BCP 79. 1162 Copies of IPR disclosures made to the IETF Secretariat and any 1163 assurances of licenses to be made available, or the result of an 1164 attempt made to obtain a general license or permission for the use of 1165 such proprietary rights by implementers or users of this 1166 specification can be obtained from the IETF on-line IPR repository at 1167 http://www.ietf.org/ipr. 1169 The IETF invites any interested party to bring to its attention any 1170 copyrights, patents or patent applications, or other proprietary 1171 rights that may cover technology that may be required to implement 1172 this standard. Please address the information to the IETF at 1173 ietf-ipr@ietf.org.