idnits 2.17.1 draft-templin-autoconf-dhcp-23.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 1277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1301. 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 710: '... MUST NOT accept them from ordinary ...' 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 (December 15, 2008) is 5601 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 157, but not defined == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1025, 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: 5 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 December 15, 2008 5 Expires: June 18, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-23.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 June 18, 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. Nodes 39 in enterprise networks must have a way to automatically provision IP 40 addresses/prefixes and other information, and must also support post- 41 autoconfiguration operations even for highly-dynamic networks. This 42 document specifies a Virtual Enterprise Traversal (VET) abstraction 43 for autoconfiguration and operation of nodes in enterprise networks. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 7 50 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 8 51 4.1. Enterprise Interior Router (EIR) Autoconfiguration . . . . 9 52 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 10 53 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 10 54 4.2.2. Provider-Aggregated Prefix Autoconfiguration . . . . . 11 55 4.2.3. Provider-Independent Prefix Autoconfiguration . . . . 12 56 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 13 57 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 13 58 5. Post-Autoconfiguration Operation . . . . . . . . . . . . . . . 13 59 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 13 60 5.2. DHCP Prefix Delegation Maintenance . . . . . . . . . . . . 14 61 5.3. IPv6 Prefix Mapping . . . . . . . . . . . . . . . . . . . 14 62 5.4. IPv6 EBR/EBG Router Discovery . . . . . . . . . . . . . . 15 63 5.5. Forwarding Packets to Destinations Outside of the 64 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 16 65 5.6. Source Address Verification . . . . . . . . . . . . . . . 17 66 5.7. Enterprise-Local Communications . . . . . . . . . . . . . 17 67 5.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17 68 5.9. Service Discovery . . . . . . . . . . . . . . . . . . . . 17 69 6. Enterprise Partitioning . . . . . . . . . . . . . . . . . . . 18 70 7. Fortifying VET with SEAL . . . . . . . . . . . . . . . . . . . 18 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 73 10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 75 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 79 Appendix A. Duplicate Address Detection (DAD) Considerations . . 23 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 Intellectual Property and Copyright Statements . . . . . . . . . . 28 84 1. Introduction 86 Enterprise networks [RFC4852] connect routers over various link types 87 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 88 (MANETs) [RFC2501] can be considered as a challenging example of an 89 enterprise network, in that their topologies may change dynamically 90 over time and that they may employ little/no active management by a 91 centralized network administrative authority. These specialized 92 characteristics for MANETs require careful consideration, but the 93 same principles apply equally to other enterprise network scenarios. 95 This document specifies a Virtual Enterprise Traversal (VET) 96 abstraction for autoconfiguration and runtime operation of nodes in 97 enterprises, where addresses of different scopes may be assigned on 98 various types of interfaces with diverse properties. Both IPv4 99 [RFC0791] and IPv6 [RFC2460] are discussed within this context. The 100 use of standard DHCP [RFC2131][RFC3315] and neighbor discovery 101 [RFC0826][RFC4861] mechanisms is assumed unless otherwise specified. 103 Provider-edge Interfaces 104 x x x 105 | | | 106 +--------------------+---+--------+----------+ E 107 | | | | | n 108 | I | | .... | | t 109 | n +---+---+--------+---+ | e 110 | t | +--------+ /| | r 111 | e I x----+ | Host | I /*+------+--< p I 112 | r n | |Function| n|**| | r n 113 | n t | +--------+ t|**| | i t 114 | a e x----+ V e|**+------+--< s e 115 | l r . | E r|**| . | e r 116 | f . | T f|**| . | f 117 | V a . | +--------+ a|**| . | I a 118 | i c . | | Router | c|**| . | n c 119 | r e x----+ |Function| e \*+------+--< t e 120 | t s | +--------+ \| | e s 121 | u +---+---+--------+---+ | r 122 | a | | .... | | i 123 | l | | | | o 124 +--------------------+---+--------+----------+ r 125 | | | 126 x x x 127 Enterprise-edge Interfaces 129 Figure 1: Enterprise Router Architecture 131 Figure 1 above depicts the architectural model for an enterprise 132 router. As shown in the figure, an enterprise router may have a 133 variety of interface types including enterprise-edge, enterprise- 134 interior, provider-edge, internal-virtual, as well as VET interfaces 135 used for encapsulation of inner IP packets within outer IP headers. 136 The different types of interfaces are defined, and the 137 autoconfiguration mechanisms used for each type are specified. This 138 architecture applies equally for MANET routers, in which enterprise- 139 interior interfaces correspond to the wireless multihop radio 140 interfaces typically associated with MANETs. Out of scope for this 141 document is the autoconfiguration of provider interfaces, which must 142 be coordinated in a manner specific to the service provider's 143 network. 145 The VET specification represents a functional superset of 6over4 146 [RFC2529] and ISATAP [RFC5214], and further supports additional 147 encapsulations such as IPsec [RFC4301], SEAL [I-D.templin-seal], etc. 148 As a result, VET provides a map-and-encaps architecture using 149 IP-in-IP tunneling based on both forwarding table and mapping service 150 lookups (defined herein). 152 The VET principles can be either directly or indirectly traced to the 153 deliberations of the ROAD group in January 1992, and also to still 154 earlier works including NIMROD [RFC1753], the Catenet model for 155 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 156 the high-level architectural aspects of the ROAD group deliberations 157 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 158 IPNG". 160 VET is related to the present-day activites of the IETF autoconf, 161 dhc, ipv6, manet and v6ops working groups. 163 2. Terminology 165 The mechanisms within this document build upon the fundamental 166 principles of IP-within-IP encapsulation. The terms "inner" and 167 "outer" are used throughout this document to respectively refer to 168 the innermost IP {address, protocol, header, packet, etc.} *before* 169 encapsulation, and the outermost IP {address, protocol, header, 170 packet, etc.} *after* encapsulation. VET also supports the inclusion 171 of "mid-layer" encapsulations between the inner and outer layers, 172 including IPSec [RFC4301], the Subnetwork Encapsulation and 173 Adaptation Layer (SEAL) [I-D.templin-seal], etc. 175 The terminology in the normative references apply; the following 176 terms are defined within the scope of this document: 178 subnetwork 179 the same as defined in [RFC3819]. 181 enterprise 182 the same as defined in [RFC4852]. 184 site 185 a logical and/or physical grouping of interfaces that connect a 186 topological area less than or equal to the enterprise in scope. A 187 site within an enterprise can be considered as an enterprise unto 188 itself. 190 Mobile Ad-hoc Network (MANET) 191 a connected topology of mobile or fixed routers that maintain a 192 routing structure among themselves over MANET link types 193 [I-D.clausen-manet-linktype], where a wide variety of MANETs share 194 common properties with enterprise networks. Further information 195 on MANETs can be found in [RFC2501]. 197 enterprise/site/MANET 198 throughout the remainder of this document, the term "enterprise" 199 is used to collectively refer to any of enterprise/site/MANET, 200 i.e., the VET mechanisms and operational principles apply equally 201 to enterprises, sites and MANETs. 203 enterprise router 204 an Enterprise Interior Router, Enterprise Border Router, or 205 Enterprise Border Gateway. As depicted in Figure 1, an enterprise 206 router comprises a router function, a host function, one or more 207 enterprise-interior interfaces and zero or more internal virtual, 208 enterprise-edge, provider-edge and VET interfaces. 210 Enterprise Interior Router (EIR) 211 a fixed or mobile enterprise router that forwards packets over one 212 or more sets of enterprise-interior interface; each set connected 213 to a distinct enterprise. 215 Enterprise Border Router (EBR) 216 an EIR that connects edge networks to the enterprise, and/or 217 connects multiple enterprises together. An EBR configures a 218 seperate VET interface over each set of enterprise-interior 219 interfaces that connect the EBR to each distinct enterprise, i.e., 220 an EBR may configure mulitple VET interfaces - one for each 221 distinct enterprise. All EBRs are also EIRs. 223 Enterprise Border Gateway (EBG) 224 an EBR that either directly or indirectly connects the enterprise 225 to provider networks and can delegate addresses/prefixes to other 226 EBRs within the enterprise. All EBGs are also EBRs. 228 internal-virtual interface 229 a virtual interface that is a special case of either an 230 enterprise-edge or an enterprise-interior interface. Internal- 231 virtual interfaces that are also enterprise-edge interfaces are 232 often loopback interfaces of some form. Internal-virtual 233 interfaces that are also enterprise-interior interfaces are often 234 tunnel interfaces of some form configured over another enterprise- 235 interior interface. 237 enterprise-edge interface 238 an EBR's attachment to a link (e.g., an ethernet, a wireless 239 personal area network, etc.) on an arbitrarily-complex edge 240 network that the EBR connects to an enterprise and/or to provider 241 networks. 243 provider-edge interface 244 an EBR's attachment to the Internet, or to a provider network 245 outside of the enterprise via which the Internet can be reached. 247 enterprise-interior interface 248 a EIR's attachment to a link within an enterprise. An enterprise- 249 interior interface is "neutral" in its orientation, i.e., it is 250 inherently neither an enterprise-edge nor provider-edge interface. 251 In particular, a packet may need to be forwarded over several 252 enterprise-interior interfaces before it is forwarded via either 253 an enterprise-edge or provider-edge interface. 255 Enterprise Local Address (ELA) 256 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 257 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 258 is assigned to an enterprise-interior interface and unique within 259 the enterprise. ELAs are used as identifiers for operating the 260 routing protocol and/or locators for packet forwarding within the 261 scope of the enterprise; ELAs are also used as *outer* IP 262 addresses during encapsulation. 264 Virtual Enterprise Traversal (VET) 265 an abstraction that uses IP-in-IP encapsulation to span a multi- 266 link enterprise in a single (inner) IP hop. 268 VET interface 269 an EBR's Non-Broadcast, Multiple Access interface used for Virtual 270 Enterprise Traversal. The EBR configures a VET interface over a 271 set of underlying enterprise-interior interface(s) belonging to 272 the same enterprise. When there are multiple distinct enterprises 273 (each with their own distinct set of enterprise-interior 274 interfaces), the EBR configures a separate VET interface over each 275 set of enterprise-interior interfaces, i.e., the EBR configures 276 multiple VET interfaces. 278 The VET interface encapsulates each inner IP packet in any mid- 279 layer headers plus an outer IP header then forwards it on an 280 underlying enterprise-interior interface such that the TTL/Hop 281 Limit in the inner header is not decremented as the packet 282 traverses the enterprise. The VET interface presents an automatic 283 tunneling abstraction that represents the enterprise as a single 284 IP hop. 286 The following additional acronyms are used throughout the document: 288 CGA - Cryptographically Generated Address 289 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 290 FIB - Forwarding Information Base 291 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 292 ND - Neighbor Discovery 293 PIO - Prefix Information Option 294 PRL - Potential Router List 295 RIO - Route Information Option 296 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 297 SEAL - Subnetwork Encapsulation and Adaptation Layer 298 SLAAC - IPv6 StateLess Address AutoConfiguation 300 3. Enterprise Characteristics 302 Enterprises consist of links that are connected by enterprise routers 303 as depicted in Figure 1. All enterprise routers are also Enterprise 304 Interior Routers (EIRs), and typically participate in a routing 305 protocol over enterprise-interior interfaces to discover routes that 306 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 307 Border Routers (EBRs) are EIRs that connect edge networks and/or join 308 multiple enterprises together, while Enterprise Border Gateways 309 (EBGs) are EBRs that either directly or indirectly connect 310 enterprises to provider networks. 312 An enterprise may be as simple as a small collection of enterprise 313 routers (and their attached edge networks); an enterprise may also 314 contain other enterprises and/or be a subnetwork of a larger 315 enterprise. An enterprise may further encompass a set of branch 316 offices and/or nomadic hosts connected to a home office over one or 317 several service providers, e.g., through Virtual Private Network 318 (VPN) tunnels. 320 Enterprises that comprise link types with sufficiently similar 321 properties (e.g., Layer-2 (L2) address formats, maximum transmission 322 units (MTUs), etc.) can configure a sub-IP layer routing service such 323 that IP sees the enterprise as an ordinary shared link the same as 324 for a (bridged) campus LAN. In that case, a single IP hop is 325 sufficient to traverse the enterprise without IP layer encapsulation. 327 Enterprises that comprise link types with diverse properties and/or 328 configure multiple IP subnets must also provide a routing service 329 that operates as an IP layer mechanism. In that case, multiple IP 330 hops may be necessary to traverse the enterprise such that specific 331 autoconfiguration procedures are necessary to avoid multilink subnet 332 issues [RFC4903]. In particular, we describe herein the use of IP- 333 in-IP encapsulation to span the enterprise in a single (inner) IP hop 334 in order to avoid the multilink subnet issues that arise when 335 enterprise-interior interfaces are used directly by applications. 337 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 338 both a host function and router function. The host function supports 339 global-scoped communications over any of the enterprise router's non- 340 enterprise-interior interfaces according to the weak end system model 341 [RFC1122] and also supports enterprise-local-scoped communications 342 over its enterprise-interior interfaces. The router function 343 connects the enterprise router's attached edge networks to the 344 enterprise and/or connects the enterprise to other networks including 345 the Internet (see: Figure 1). 347 In addition to other interface types, EBRs configure VET interfaces 348 that view all other EBRs in an enterprise as single-hop neighbors, 349 where the enterprise can also appear as a single IP hop within 350 another enterprise. EBRs configure a separate VET interface for each 351 distinct enterprise to which they connect, and discover a list of 352 EBRs for each VET interface that can be used for forwarding packets 353 to off-enterprise destinations. The following sections present the 354 Virtual Enterprise Traversal approach. 356 4. Autoconfiguration 358 EIRs configure enterprise-interior interfaces. An EBR is an EIR that 359 also configures enterprise-edge and VET interfaces. An EBG is an EBR 360 that also either directly or indirectly connects the enterprise to a 361 provider network. EIRs, EBRs and EBGs configure themselves for 362 operation according to the following subsections: 364 4.1. Enterprise Interior Router (EIR) Autoconfiguration 366 EIRs configure enterprise-interior interfaces and engage in routing 367 protocols over those interfaces. 369 When an EIR joins an enterprise, it first configures a unique IPv6 370 link-local address on each enterprise-interior interface that 371 requires an IPv6 link-local capability and an IPv4 link-local address 372 on each enterprise-interior interface that requires an IPv4 link- 373 local capability. IPv6 link-local address generation mechanisms that 374 provide sufficient uniqueness include Cryptographically Generated 375 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 376 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 377 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 378 provide an IPv4 link-local address generation capability. 380 Next, the EIR configures an Enterprise Local Address (ELA) of the 381 outer IP protocol version on each of its enterprise-interior 382 interfaces and engages in any routing protocols on those interfaces. 383 The EIR can configure an ELA via explicit management, DHCP 384 autoconfiguration, pseudo-random self-generation from a suitably 385 large address pool, or through an alternate autoconfiguration 386 mechanism. In some enterprise use cases (e.g., highly dynamic 387 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 388 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 389 issues. 391 EIRs that configure ELAs using DHCP may require relay support from 392 other EIRs within the enterprise; the EIR can alternatively configure 393 both a DHCP client and relay that are connected, e.g., via a pair of 394 back-to-back connected ethernet interfaces, a tun/tap interface, a 395 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 396 do not already know the ELA of a server relay requests to the 397 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 398 relays that do not already know the ELA of a server relay requests to 399 the site-scoped IPv4 multicast group address TBD (see: Section 8). 400 DHCPv4 servers that delegate ELAs join the TBD multicast group and 401 service any DHCPv4 messages received for that group. 403 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 404 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 405 generation of ELAs for IPv4 can be from a large IPv4 private address 406 range (e.g., [RFC1918]). When self-generation is used alone, the EIR 407 must continuously monitor the ELAs for uniqueness, e.g., by 408 monitoring the routing protocol, but care must be taken in the 409 interaction of this monitoring with existing mechanisms. 411 A combined approach using both DHCP and self-generation is also 412 possible in which the EIR first self-generates a temporary ELA used 413 only for the purpose of procuring an actual ELA taken from a disjoint 414 addressing range. The EIR then assigns the temporary ELA to an 415 enterprise-interior interface, engages in the routing protocol and 416 performs a DHCP client/relay exchange using the temporary ELA as the 417 address of the relay. When the DHCP server delegates an actual ELA, 418 the EIR abandons the temporary ELA, assigns the actual ELA to the 419 enterprise-interior interface and re-engages in the routing protocol. 421 4.2. Enterprise Border Router (EBR) Autoconfiguration 423 EBRs are EIRs that configure VET interfaces over distinct sets of 424 underlying enterprise-interior interfaces; an EBR can connect to 425 multiple enterprises, in which case it would configure multiple VET 426 interfaces. EBRs perform the following autoconfiguration operations: 428 4.2.1. VET Interface Autoconfiguration 430 VET interface autoconfiguration entails: 1) interface initialization, 431 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 432 address autoconfiguration. These functions are specified in the 433 following sections: 435 4.2.1.1. Interface Initialization 437 EBRs configure a VET interface over a set of underlying enterprise- 438 interior interfaces belonging to the same enterprise, where the VET 439 interface presents a virtual view of all EBRs in the enterprise as 440 single hop neighbors through the use of IP-in-IP encapsulation. 442 When IPv6 and IPv4 are used as the inner/outer protocols 443 (respectively), the EBR autoconfigures an ISATAP link-local address 444 ([RFC5214], Section 6.2) on the VET interface to support packet 445 forwarding and operation of the IPv6 neighbor discovery protocol. 446 The ISATAP link-local address embeds an IPv4 ELA assigned to an 447 underlying enterprise-interior interface, and need not be checked for 448 uniqueness since the IPv4 ELA itself was already determined to be 449 unique (see: Section 4.1). Link-local address configuration for 450 other inner/outer IP protocol combinations is through administrative 451 configuration or through an unspecified alternate method. 453 After the EBR configures a VET interface, it can communicate with 454 other EBRs as single-hop neighbors from the viewpoint of the inner IP 455 protocol (where discovery of other EBRs is discussed in Section 5.4). 456 The EBR can also confirm reachability of other EBRs through Neighbor 457 Discovery (ND) and/or DHCP exchanges over the VET interface, or 458 through other means such as information conveyed in the routing 459 protocol. 461 The EBR must be able to detect and recover from the loss of VET 462 interface neighbors due to, e.g., network partitions, node failures, 463 etc. Mechanisms specified outside of this document such as 464 monitoring the routing protocol, ND beaconing/polling, DHCP renewals/ 465 leasequeries, upper layer protocol hints of forward progress, 466 bidirectional forward detection, detection of network attachment, 467 etc. can be used according to the particular deployment scenario. 469 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 470 Identification 472 The EBR next discovers a list of EBGs for each of its VET interfaces, 473 i.e., for each enterprise it connects to. The list can be discovered 474 through information conveyed in the routing protocol and/or through 475 the Potential Router List (PRL) discovery mechanisms outlined in 476 [RFC5214], Section 8.3.2. 478 In particular, whether or not routing information is available the 479 EBR can discover the list of EBGs by resolving an identifying name 480 for the enterprise using an enterprise local name resolution service 481 (e.g., an enterprise-local DNS service, LLMNR [RFC4759], etc.). In 482 the absence of other identifying names, the EBR can resolve either 483 the hostname "isatap" or the FQDN "isatap.example.com" if an 484 enterprise-specific suffix "example.com" is known. 486 Identifying names along with addresses of EBGs and/or the prefixes 487 they aggregate serve as an identifier for the enterprise. 489 4.2.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) 491 When IPv6 is used as the inner protocol, the EBR sends unicast IPv6 492 Router Solicitation (RS) messages over its VET interface(s) to 493 receive Router Advertisements (RAs) from EBGs. When the EBR receives 494 an RA containing Prefix Information Options (PIOs) with the 'A' and 495 'L' bits set to 1, it autoconfigures IPv6 addresses from the prefixes 496 using SLAAC and assigns them to the VET interface. (When IPv4 is 497 used as the outer IP protocol, the addresses are autoconfigured and 498 assigned as ISATAP addresses the same as specified in [RFC5214].) 500 The use of DHCPv6 for address configuration on VET interfaces is 501 undefined. 503 4.2.2. Provider-Aggregated Prefix Autoconfiguration 505 EBRs acquire provider-aggregated prefixes through autoconfiguration 506 exchanges with EBGs over VET interfaces. When IPv4 is used as the 507 inner IP protocol, the EBR acquires provider-aggregated prefixes via 508 an unspecified automated IPv4 prefix delegation exchange, explicit 509 management, etc. 511 When IPv6 is used as the inner IP protocol, the EBR acquires 512 provider-aggregated prefixes via IPv6 Neighbor Discovery and DHCPv6 513 Prefix Delegation exchanges. If the EBR receives an RA from an EBG 514 that contains PIOs with the 'L' bit set to 0, it can use the PIOs as 515 hints of prefixes the DHCPv6 server may be willing to delegate (see: 516 Section 5.4). Whether or not such hints are available, the EBR 517 (acting as a requesting router) can use DHCPv6 prefix delegation 518 [RFC3633] over the VET interface to obtain Provider-Aggregated IPv6 519 prefixes from the server (acting as a delegating router). 521 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 522 exchange [RFC3315]. For example, to perform the 2-message exchange 523 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 524 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 525 relay (see: Section 4.1). The relay then forwards the message over 526 the VET interface to the EBG. The forwarded Solicit message will 527 elicit a reply from the server containing provider-aggregated IPv6 528 prefix delegations. 530 The EBR can propose a specific prefix to the DHCPv6 server per 531 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 532 available. The server will check the proposed prefix for consistency 533 and uniqueness, then return it in the reply to the EBR if it was able 534 to perform the delegation. 536 After the EBR received provider-aggregated prefix delegations, it can 537 provision the prefixes on its enterprise-edge interfaces as well as 538 on other VET interfaces for which it is configured as an EBG. 540 4.2.3. Provider-Independent Prefix Autoconfiguration 542 Independent of any provider-aggregated prefixes (see: Section 4.2.2), 543 EBRs can also acquire and use provider-independent and/or self- 544 configured prefixes (e.g., IPv6 Unique Local Addresses (ULAs) 545 [RFC4193][I-D.ietf-ipv6-ula-central]). 547 EBRs can retain their provider-independent addresses/prefixes as they 548 travel between visited enterprise networks as long as they register 549 the prefixes with new enterprises and (preferrably) withdraw the 550 prefixes from departed enterprises. EBRs can use SEND to prove 551 ownership of their provider-independent prefixes and can use DHCPv6 552 prefix delegation to register the prefixes in the new enterprise. 553 EBRs can also act as delegating routers to sub-delegate portions of 554 their provider-independent prefixes to requesting routers on their 555 enterprise edge interfaces and on VET interfaces for which they are 556 configured as EBGs. 558 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 560 EBGs are EBRs that connect enterprises to a service provider either 561 directly via provider-edge interfaces or indirectly via another 562 enterprise. EBGs configure provider-edge interfaces in a manner that 563 is specific to its provider connections. EBGs also configure a DHCP 564 relay/server that can service prefix delegation requests. 566 For each VET interface on which it is configured as an EBG, the EBG 567 must arrange to add its enterprise-interior interface addresses to 568 the PRL (see: Section 4.2.1.2), and must maintain these resource 569 records in accordance with ([RFC5214], Section 9). In particular, 570 for each such VET interface the EBG adds its enterprise-interior 571 interface addresses to the hostname "isatap" and/or the FQDN 572 "isatap.example.com". 574 4.4. VET Host Autoconfiguration 576 Non-routing hosts that cannot be attached via an EBR's enterprise- 577 edge interface (e.g., nomadic laptops that connect to a home office 578 via a Virtual Private Network (VPN)) can instead be configured for 579 operation as a simple host connected to the VET interface. Such VET 580 hosts configure one or more VET interfaces over corresponding sets of 581 enterprise-interior interfaces exactly as for EBRs, but they do not 582 configure a router function nor provide packet forwarding services. 583 VET hosts can then send packets to other hosts on the VET interface, 584 or to off-enterprise destinations via a next-hop EBR. 586 5. Post-Autoconfiguration Operation 588 The following sections discuss post-autoconfiguration operations: 590 5.1. Routing Protocol Participation 592 After an EIR has been autoconfigured, it participates in any routing 593 protocols over enterprise-interior interfaces and forwards outer IP 594 packets within the enterprise as for any ordinary router. 596 EBRs can additionally engage in any inner IP routing protocols over 597 enterprise-edge, provider-edge and VET interfaces, and can use those 598 interfaces for forwarding inner IP packets to off-enterprise 599 destinations. Note that these inner IP routing protocols are 600 separate and distinct from any enterprise-interior routing protocols. 602 5.2. DHCP Prefix Delegation Maintenance 604 When DHCP prefix delegation is used, the DHCP server ensures that the 605 delegations are unique and that the EBG's router function will 606 forward IP packets over the VET interface to the EBRs to which the 607 prefixes were delegated. The EBRs can then sub-delegate the prefixes 608 to other requesting routers. 610 The DHCP prefix delegations remain active as long as the EBR 611 continues to issue renewals over the VET interface before lease 612 lifetimes expire. The lease lifetime also keeps the delegation state 613 active even if communications between the EBR and DHCP server are 614 disrupted for a period of time (e.g., due to an enterprise network 615 partition) before being reestablished (e.g., due to an enterprise 616 network merge). When the EBR leaves the enterprise, it should first 617 release its delegated provider-dependent prefixes and unregister its 618 provider-independent prefixes to avoid black-holing future 619 communications. 621 Since the DHCP client and relay are co-resident on the same EBR, no 622 special coordination is necessary for the EBG to maintain routing 623 information. The EBG simply retains Forwarding Information Base 624 (FIB) entries that identify the EBR as the next-hop toward the 625 prefixes over the VET interface. 627 5.3. IPv6 Prefix Mapping 629 EBRs in enterprises that are managed under a cooperative 630 administrative authority should use the enterprise-local name service 631 (e.g., the DNS [RFC1035]) as the IPv6 prefix mapping service. ENBRs 632 in enterprises that are managed in a distributed fashion should 633 implement their own distributed name resolution services (e.g., LLMNR 634 [RFC4759]). 636 For each of the /64 prefixes they aggregate, EBRs must respond to 637 messages addressed to the prefix's IPv6 subnet router anycast address 638 [RFC4291]. EBRs must also publish the prefixes in the enterprise- 639 local name service using the domain name suffix 'isatap.example.com'; 640 for publications within the global DNS itself, the domain name suffix 641 'isatap.net' is used instead. The EBR publishes the prefix as a 642 domain name consisting of a sequence of 16 nibbles in reverse order 643 the same as in ([RFC3596], Section 2.5). For example, the EBR 644 publishes the prefix 2001:DB8::/64 as: 645 '0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. 647 The EBR (or one of a group of EBRs that service the same prefix) 648 includes in each prefix publication IPv4 addresses (e.g., in DNS A 649 records) taken from the EBRs' enterprise interior interfaces, and 650 IPv6 CGA addresses [RFC3972] (e.g., in DNS AAAA records) that other 651 nodes can use to uniquely identify the EBR (or one of a group of 652 redundant EBRs). In enterprises with a cooperative administrative 653 authority, EBRs coordinate their publications with an administrator 654 and/or by using a secure automated name service update mechanism 655 (e.g., [RFC3007]). In enterprises that are managed in a distributed 656 fashion, EBRs publish their prefixes through direct responses to 657 distributed name resoultion service queries via a mechanism such as 658 LLMNR.. 660 In this way, the enterprise name service itself becomes an extension 661 of the enterprise's PRL, and the global DNS serves as the PRL for the 662 entire Internet. 664 5.4. IPv6 EBR/EBG Router Discovery 666 EBGs follow the router and prefix discovery procedures specified in 667 ([RFC5214], Section 8.2). They send RAs over VET interfaces for 668 which they are gateways with PIOs for SLAAC, with the 'M' flag set to 669 0 and with the 'O' flag set to indicate whether "other" DHCP services 670 are available. EBGs can also include PIOs with the 'L' bit set to 0 671 and with a prefix such as 2001:DB8::/48 as a hint of an aggregated 672 prefix from which it is willing to delegate longer prefixes. 674 VET hosts and EBRs (i.e., source EBRs) follow the router and prefix 675 discovery procedures specified in ([RFC5214], Section 8.3). They 676 discover EBGs by resolving the hostname 'isatap' or the FQDN 677 "isatap.example.com"; in multicast-capable deployments, they can also 678 derive hints of EBG reachability by listening for advertisements on 679 the 'rasadv' [RASADV] IPv4 multicast group address. 681 Source EBRs can discover target EBRs for specific IPv6 prefixes by 682 querying the name service for the prefix corresponding to a packet's 683 destination address. For example, for the IPv6 destination address 684 2001:DB8:1:2::1 the source EBR can query the 'isatap.example.com' 685 domain for the domain name: 686 '2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. The name 687 service query will return IPv4 addresses (e.g., in DNS A records) 688 that correspond to the target EBR's enterprise interior interfaces 689 and IPv6 CGA addresses (e.g., in DNS AAAA records) that the source 690 EBR can use to verify address ownership. 692 Source EBRs can also send a Secure Neighbor Discovery (SEND)- 693 protected [RFC3971] RS over the VET interface with a CGA address as 694 the source and the subnet router anycast address corresponding to a 695 specific IPv6 prefix as the destination address. A target EBR that 696 services the prefix will authenticate the RS and return a SEND- 697 protected RA with the source address of the RS as the IPv6 698 destination address, with the CGA published in the name service as 699 the IPv6 source address, with an IPv4 address taken from its 700 enterprise interior addresses as the IPv4 address in the outer 701 header, with router/prefix information [RFC4861] and with Route 702 Information Options [RFC4191] containing specific IPv6 prefixes. 704 The source EBR can then use SEND to verify that the RA came from the 705 correct target EBR, and can configure default and more-specific 706 routes based on the RA contents. 708 VET hosts and EBR must only accept PIOs, M/O flag settings and 709 default router preferences in RAs that are received from EBGs; they 710 MUST NOT accept them from ordinary EBRs. 712 5.5. Forwarding Packets to Destinations Outside of the Enterprise 714 After default and/or more-specific routes are discovered, VET hosts 715 and EBRs can forward IP packets to off-enterprise destinations by 716 consulting the FIB to determine a specific EBR/EBG as the next-hop 717 router on the VET interface. When multiple next-hop routers are 718 available, VET hosts and EBRs can use default router preferences, 719 routing protocol information, traffic engineering configurations, 720 etc. to select the best exit router. When there is no FIB 721 information available, VET hosts and EBRs can discover the next-hop 722 EBR/EBG through the mechanisms specified in Section 5.4. 724 VET interfaces encapsulate inner IP packets in any mid-layer headers 725 followed by an outer IP header according to the specific 726 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 727 next submit the encapsulated packet to the outer IP forwarding engine 728 for transmission on an underlying enterprise-interior interface. For 729 forwarding to next-hop addresses over VET interfaces that use IPv6- 730 in-IPv4 encapsulation, VET hosts and EBRs determine the outer 731 destination address through static extraction of the IPv4 address 732 embedded in the next-hop ISATAP address. For other IP-in-IP 733 encapsulations, determination of the outer destination address is 734 through administrative configuration or through an unspecified 735 alternate method. 737 When a VET host/EBR forward packets to an EBG that has more 738 comprehensive FIB information, the EBG can forward the packet and 739 issue ordinary ICMP redirects over the VET interface as necessary. 740 If the next-hop corresponds to a node outside the enterprise, the EBG 741 decapulates the packet and forwards it the same as for an ordinary 742 router. If the next-hop corresponds to another node on the VET 743 interface, however, the EBG forwards the packet without decapsulation 744 by rewriting the outer IP destination address but leaving the outer 745 IP source address intact. 747 5.6. Source Address Verification 749 VET hosts and EBRs must verify that the outer IP source address of a 750 packet received on a VET interface is correct for the inner IP source 751 address using the procedures specified in ([RFC5214], Section 7.3). 753 5.7. Enterprise-Local Communications 755 When permitted by policy, end systems that configure the endpoints of 756 enterprise-local communications can avoid VET interface encapsulation 757 by directly invoking the outer IP protocol using ELAs assigned to 758 their enterprise-interior interfaces. For example, when the outer 759 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 760 communications over their enterprise-interior interfaces without 761 using the VET interface. 763 5.8. Multicast 765 In multicast-capable deployments, EIRs provide an enterprise-wide 766 multicasting service such as Simplified Multicast Forwarding (SMF) 767 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 768 that outer IP multicast messages of site- or greater scope will be 769 propagated across the enterprise. For such deployments, VET hosts 770 and EBRs can also provide an inner IP multicast/broadcast capability 771 over their VET interfaces through mapping of the inner IP multicast 772 address space to the outer IP multicast address space. 774 VET hosts and EBRs encapsulate inner IP multicast messages sent over 775 the VET interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) 776 plus an outer IP header with a site-scoped outer IP multicast address 777 as the destination. For the case of IPv6 and IPv4 as the inner/outer 778 protocols (respectively), [RFC2529] provides mappings from the IPv6 779 multicast address space to the IPv4 multicast address space. For 780 other IP-in-IP encapsulations, mappings are established through 781 administrative configuration or through an unspecified alternate 782 method. 784 For multicast-capable enterprises, use of the inner IP multicast 785 service for operating the ND protocol over the VET interface is 786 available but should be used sparingly to minimize enterprise-wide 787 flooding. 789 5.9. Service Discovery 791 VET hosts and EBRs can peform enterprise-wide service discovery using 792 a suitable name-to-address resolution service. Examples of flooding- 793 based services include the use of LLMNR [RFC4759] over the VET 794 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 795 underlying enterprise-interior interface. More scalable and 796 efficient service discovery mechanisms are for further study. 798 6. Enterprise Partitioning 800 EBGs can physically partition an enterprise by configuring multiple 801 VET interfaces over multiple distinct sets of underlying interfaces. 802 In that case, each partition (i.e., each VET interface) must 803 configure its own distinct PRL zone (e.g., 'zone1.example.com', 804 'zone2.example.com', etc.). 806 EBGs can logically partition an enterprise using a single VET 807 interface by sending RAs with PIOs containing different IPv6 subnet 808 prefixes to nodes in different logical partitions. EBGs can identify 809 partitions, e.g., by examining IPv4 prefixes, observing the 810 interfaces over which RSs are received, etc. In that case, a single 811 PRL zone can cover all partitions. 813 7. Fortifying VET with SEAL 815 Enterprises should use SEAL encapsulation [I-D.templin-seal] in 816 conjunction with VET to accommdate path MTU diversity, and to defend 817 against rogue routers and source address spoofing. In particular, 818 EBRs can discard packets that have SEAL_ID values outside of the 819 current window, and can use egress filtering based on prefix 820 information received in SEND-protected RAs to detect source address 821 spoofing. 823 To maintain synchronization, the EBR resets its cached SEAL_IDs for 824 correspondent EBRs/EBGs within the enterise whenever it receives 825 fresh SEND-protected RAs. 827 8. IANA Considerations 829 A Site-Local Scope IPv4 multicast group (TBD) for DHCPv4 server 830 discovery is requested. The allocation should be taken from the 831 239.255.000.000-239.255.255.255 Site-Local Scope range in the IANA 832 'multicast-addresses' registry. 834 9. Security Considerations 836 Security considerations for MANETs are found in [RFC2501]. 838 Security considerations with tunneling that apply also to VET are 839 found in [RFC2529][RFC5214]. 841 The securing methods specified in Section 7 provide additional 842 mitigation against both rogue EBRs (via SEND) and source address 843 spoofing (via the SEAL_ID and prefix-based egress filtering). 845 10. Related Work 847 The authors acknowledge the work done by Brian Carpenter and Cyndi 848 Jung in [RFC2529] that introduced the concept of intra-site automatic 849 tunneling. This concept was later called: "Virtual Ethernet" and 850 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 851 As for this document, these architectural principles also follow from 852 earlier works articulated by the ROAD group deliberations of 1992. 854 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 855 program. The Naval Research Lab (NRL) Information Technology 856 Division uses DHCP in their MANET research testbeds. Various 857 proposals within the IETF have suggested similar mechanisms. 859 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 860 regarding tunneling mechanisms that may subvert security through 861 Network Address Translator (NAT) traversal. 863 An automated IPv4 prefix delegation mechanism is proposed in 864 [I-D.ietf-dhc-subnet-alloc]. 866 11. Acknowledgements 868 The following individuals gave direct and/or indirect input that was 869 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 870 Bound, Thomas Clausen, Joel Halpern, Bob Hinden, Joe Macker, Thomas 871 Narten, Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, 872 Ole Troan, Michaela Vanderveen and others in the IETF AUTOCONF and 873 MANET working groups. Many others have provided guidance over the 874 course of many years. 876 12. Contributors 878 The following individuals have contributed to this document: 880 Eric Fleischman (eric.fleischman@boeing.com) 881 Thomas Henderson (thomas.r.henderson@boeing.com) 882 Steven Russert (steven.w.russert@boeing.com) 883 Seung Yi (seung.yi@boeing.com) 884 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 885 of the document. 887 13. References 889 13.1. Normative References 891 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 892 September 1981. 894 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 895 converting network protocol addresses to 48.bit Ethernet 896 address for transmission on Ethernet hardware", STD 37, 897 RFC 826, November 1982. 899 [RFC1035] Mockapetris, P., "Domain names - implementation and 900 specification", STD 13, RFC 1035, November 1987. 902 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 903 RFC 2131, March 1997. 905 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 906 (IPv6) Specification", RFC 2460, December 1998. 908 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 909 Update", RFC 3007, November 2000. 911 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 912 and M. Carney, "Dynamic Host Configuration Protocol for 913 IPv6 (DHCPv6)", RFC 3315, July 2003. 915 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 916 "DNS Extensions to Support IP Version 6", RFC 3596, 917 October 2003. 919 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 920 Host Configuration Protocol (DHCP) version 6", RFC 3633, 921 December 2003. 923 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 924 Neighbor Discovery (SEND)", RFC 3971, March 2005. 926 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 927 RFC 3972, March 2005. 929 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 930 More-Specific Routes", RFC 4191, November 2005. 932 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 933 Architecture", RFC 4291, February 2006. 935 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 936 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 937 September 2007. 939 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 940 Address Autoconfiguration", RFC 4862, September 2007. 942 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 943 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 944 March 2008. 946 13.2. Informative References 948 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 949 Switching Networks", May 1974. 951 [I-D.cheshire-dnsext-multicastdns] 952 Cheshire, S. and M. Krochmal, "Multicast DNS", 953 draft-cheshire-dnsext-multicastdns-07 (work in progress), 954 September 2008. 956 [I-D.clausen-manet-linktype] 957 Clausen, T., "The MANET Link Type", 958 draft-clausen-manet-linktype-00 (work in progress), 959 October 2008. 961 [I-D.ietf-autoconf-manetarch] 962 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 963 Network Architecture", draft-ietf-autoconf-manetarch-07 964 (work in progress), November 2007. 966 [I-D.ietf-dhc-subnet-alloc] 967 Johnson, R., "Subnet Allocation Option", 968 draft-ietf-dhc-subnet-alloc-07 (work in progress), 969 July 2008. 971 [I-D.ietf-ipv6-ula-central] 972 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 973 Addresses", draft-ietf-ipv6-ula-central-02 (work in 974 progress), June 2007. 976 [I-D.ietf-manet-smf] 977 Macker, J. and S. Team, "Simplified Multicast Forwarding 978 for MANET", draft-ietf-manet-smf-08 (work in progress), 979 November 2008. 981 [I-D.ietf-v6ops-tunnel-security-concerns] 982 Hoagland, J., Krishnan, S., and D. Thaler, "Security 983 Concerns With IP Tunneling", 984 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 985 progress), October 2008. 987 [I-D.templin-seal] 988 Templin, F., "The Subnetwork Encapsulation and Adaptation 989 Layer (SEAL)", draft-templin-seal-23 (work in progress), 990 August 2008. 992 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 993 July 1978. 995 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 996 Protocol Specification", October 2008. 998 [RFC1122] Braden, R., "Requirements for Internet Hosts - 999 Communication Layers", STD 3, RFC 1122, October 1989. 1001 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1002 Routing and Addressing Architecture", RFC 1753, 1003 December 1994. 1005 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1006 E. Lear, "Address Allocation for Private Internets", 1007 BCP 5, RFC 1918, February 1996. 1009 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1010 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1012 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1013 (MANET): Routing Protocol Performance Issues and 1014 Evaluation Considerations", RFC 2501, January 1999. 1016 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1017 Domains without Explicit Tunnels", RFC 2529, March 1999. 1019 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1020 February 2000. 1022 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1023 via IPv4 Clouds", RFC 3056, February 2001. 1025 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1026 RFC 3753, June 2004. 1028 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1029 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1030 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1031 RFC 3819, July 2004. 1033 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1034 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1035 May 2005. 1037 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1038 Addresses", RFC 4193, October 2005. 1040 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1041 Internet Protocol", RFC 4301, December 2005. 1043 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1044 Indicator Parameter for the "tel" URI", RFC 4759, 1045 December 2006. 1047 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1048 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1049 Focus", RFC 4852, April 2007. 1051 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1052 June 2007. 1054 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1055 Extensions for Stateless Address Autoconfiguration in 1056 IPv6", RFC 4941, September 2007. 1058 Appendix A. Duplicate Address Detection (DAD) Considerations 1060 A-priori uniqueness determination (also known as "pre-service DAD") 1061 for an ELA assigned on an enterprise-interior interface (such as 1062 specified in [RFC4862]) would require either flooding the entire 1063 enterprise or somehow discovering a link in the enterprise on which a 1064 node that configures a duplicate address is attached and performing a 1065 localized DAD exchange on that link. But, the control message 1066 overhead for such an enterprise-wide DAD would be substantial and 1067 prone to false-negatives due to packet loss and intermittent 1068 connectivity. An alternative to pre-service DAD is to autoconfigure 1069 pseudo-random ELAs on enterprise-interior interfaces and employ a 1070 passive in-service DAD (e.g., one that monitors routing protocol 1071 messages for duplicate assignments). 1073 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1074 CGAs, IPv6 privacy addresses, etc. with very small probability of 1075 collision. Pseudo-random IPv4 ELAs can be generated through random 1076 assignment from a suitably large IPv4 prefix space. 1078 Consistent operational practices can assure uniqueness for EBG- 1079 aggregated addresses/prefixes, while statistical properties for 1080 pseudo-random address self-generation can assure uniqueness for the 1081 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 1082 ELA delegation authority should be used when available, while a 1083 passive in-service DAD mechanism should be used to detect ELA 1084 duplications when there is no ELA delegation authority. 1086 Appendix B. Change Log 1088 (Note to RFC editor - this section to be removed before publication 1089 as an RFC.) 1091 Changes from -22 to 23: 1093 o Clarifications on prefix mapping. 1095 Changes from -21 to 22: 1097 o Using SEAL to secure VET 1099 Changes from -20 to 21: 1101 o Enterprise partitioning. 1103 o Mapping and name service management. 1105 Changes from -18 to 20: 1107 o Added support for simple hosts. 1109 o Added EBG name service maintenace procedures 1111 o Added router and prefix maintenace procedures 1113 Changes from -17 to 18: 1115 o adjusted section headings to group autoconf operations under EIR/ 1116 EBR/EBG. 1118 o clarified M/O bits 1120 o clarified EBG roles 1122 Changes from -15 to 17: 1124 o title change to "Virtual Enterprise Traversal (VET)". 1126 o changed document focus from MANET-centric to the much-broader 1127 Enterprise-centric, where "Enterprise" is understood to also cover 1128 a wide range of MANET types. 1130 Changes from -14 to 15: 1132 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1134 o Address review comments 1136 Changes from -12 to 14: 1138 o title change to "The MANET Virtual Ethernet Abstraction". 1140 o Minor section rearrangement. 1142 o Clartifications on portable and self-configured prefixes. 1144 o Clarifications on DHCPv6 prefix delegation procedures. 1146 Changes from -11 to 12: 1148 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1150 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1151 delegation mechanism. 1153 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1155 o fixed editorials based on comments received. 1157 Changes from -10 to 11: 1159 o removed the transparent/opaque VET portal abstractions. 1161 o removed routing header as an option for MANET exit router 1162 selection. 1164 o included IPv6 SLAAC as an endorsed address configuration mechanism 1165 for the VET interface. 1167 Changes from -08 to -09: 1169 o Introduced the term "VET". 1171 o Changed address delegation language to speak of "MNBR-aggregated" 1172 instead of global/local. 1174 o Updated figures 1-3. 1176 o Explained why a MANET interface is "neutral". 1178 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1179 DHCPv4 servers; not relays. 1181 Changes from -07 to -08: 1183 o changed terms "unenhanced" and "enhanced" to "transparent" and 1184 "opaque". 1186 o revised MANET Router diagram. 1188 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1189 interface. 1191 o changed abbreviations to "MNR" and "MNBR". 1193 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1195 o rearranged Section 3.1. 1197 o various minor text cleanups 1199 Changes from -06 to -07: 1201 o added MANET Router diagram. 1203 o added new references 1205 o various minor text cleanups 1207 Changed from -05 to -06: 1209 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1211 o minor changes to preserve generality 1213 Changed from -04 to -05: 1215 o introduced conceptual "virtual ethernet" model. 1217 o support "raw" and "cooked" modes as equivalent access methods on 1218 the virutal ethernet. 1220 Changed from -03 to -04: 1222 o introduced conceptual "imaginary shared link" as a representation 1223 for a MANET. 1225 o discussion of autonomous system and site abstractions for MANETs 1227 o discussion of autoconfiguration of CGAs 1229 o new appendix on IPv6 StateLess Address AutoConfiguration 1231 Changes from -02 to -03: 1233 o updated terminology based on RFC2461 "asymmetric reachability" 1234 link type; IETF67 MANET Autoconf wg discussions. 1236 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1237 Address Detection 1239 o relaxed DHCP server deployment considerations allow DHCP servers 1240 within the MANET itself 1242 Changes from -01 to -02: 1244 o minor updates for consistency with recent developments 1246 Changes from -00 to -01: 1248 o new text on DHCPv6 prefix delegation and multilink subnet 1249 considerations. 1251 o various editorial changes 1253 Author's Address 1255 Fred L. Templin (editor) 1256 Boeing Phantom Works 1257 P.O. Box 3707 MC 7L-49 1258 Seattle, WA 98124 1259 USA 1261 Email: fltemplin@acm.org 1263 Full Copyright Statement 1265 Copyright (C) The IETF Trust (2008). 1267 This document is subject to the rights, licenses and restrictions 1268 contained in BCP 78, and except as set forth therein, the authors 1269 retain all their rights. 1271 This document and the information contained herein are provided on an 1272 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1273 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1274 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1275 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1276 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1277 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1279 Intellectual Property 1281 The IETF takes no position regarding the validity or scope of any 1282 Intellectual Property Rights or other rights that might be claimed to 1283 pertain to the implementation or use of the technology described in 1284 this document or the extent to which any license under such rights 1285 might or might not be available; nor does it represent that it has 1286 made any independent effort to identify any such rights. Information 1287 on the procedures with respect to rights in RFC documents can be 1288 found in BCP 78 and BCP 79. 1290 Copies of IPR disclosures made to the IETF Secretariat and any 1291 assurances of licenses to be made available, or the result of an 1292 attempt made to obtain a general license or permission for the use of 1293 such proprietary rights by implementers or users of this 1294 specification can be obtained from the IETF on-line IPR repository at 1295 http://www.ietf.org/ipr. 1297 The IETF invites any interested party to bring to its attention any 1298 copyrights, patents or patent applications, or other proprietary 1299 rights that may cover technology that may be required to implement 1300 this standard. Please address the information to the IETF at 1301 ietf-ipr@ietf.org.