idnits 2.17.1 draft-templin-autoconf-dhcp-37.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 704: '...id looping, EBGs MUST NOT configure a ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2009) is 5505 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 190, but not defined == Unused Reference: 'RFC4291' is defined on line 1413, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1532, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1538, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 == Outdated reference: A later version (-05) exists of draft-ietf-csi-proxy-send-00 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-07 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-08 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research and Technology 4 Intended status: Informational March 3, 2009 5 Expires: September 4, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-37.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 4, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Enterprise networks connect routers over various link types, and may 47 also connect to provider networks and/or the global Internet. 48 Enterprise network nodes require a means to automatically provision 49 IP addresses/prefixes and support internetworking operation in a wide 50 variety of use cases including SOHO networks, Mobile Ad-hoc Networks 51 (MANETs), multi-organizational corporate networks and the interdomain 52 core of the global Internet itself. This document specifies a 53 Virtual Enterprise Traversal (VET) abstraction for autoconfiguration 54 and operation of nodes in enterprise networks. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 10 61 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 11 62 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 11 63 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 13 64 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 13 65 4.2.2. Provider-Aggregated (PA) EID Prefix 66 Autoconfiguration . . . . . . . . . . . . . . . . . . 15 67 4.2.3. Provider-Independent (PI) EID Prefix 68 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 69 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 16 70 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 17 71 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 17 72 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 17 73 5.2. RLOC-based Communications . . . . . . . . . . . . . . . . 17 74 5.3. EID-based Communications . . . . . . . . . . . . . . . . . 18 75 5.4. IPv6 Router Discovery and Prefix Registration . . . . . . 18 76 5.4.1. IPv6 Router and Prefix Discovery . . . . . . . . . . . 18 77 5.4.2. IPv6 PA Prefix Registration . . . . . . . . . . . . . 19 78 5.4.3. IPv6 PI Prefix Registration . . . . . . . . . . . . . 19 79 5.4.4. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . 21 80 5.5. IPv4 Router Discovery and Prefix Registration . . . . . . 23 81 5.6. VET Encapsulation . . . . . . . . . . . . . . . . . . . . 23 82 5.7. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 24 83 5.8. Generating Errors . . . . . . . . . . . . . . . . . . . . 24 84 5.9. Processing Errors . . . . . . . . . . . . . . . . . . . . 25 85 5.10. Mobility and Multihoming Considerations . . . . . . . . . 26 86 5.11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 27 87 5.12. Service Discovery . . . . . . . . . . . . . . . . . . . . 28 88 5.13. Enterprise Partitioning . . . . . . . . . . . . . . . . . 28 89 5.14. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 28 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 94 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 98 Appendix A. Duplicate Address Detection (DAD) Considerations . . 35 99 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 102 1. Introduction 104 Enterprise networks [RFC4852] connect routers over various link types 105 (see: [RFC4861], Section 2.2). The term "enterprise network" in this 106 context extends to a wide variety of use cases and deployment 107 scenarios. For example, an "enterprise" can be as small as a SOHO 108 network, as complex as a multi-organizational corporation, or as 109 large as the global Internet itself. Mobile Ad-hoc Networks (MANETs) 110 [RFC2501] can also be considered as a challenging example of an 111 enterprise network, in that their topologies may change dynamically 112 over time and that they may employ little/no active management by a 113 centralized network administrative authority. These specialized 114 characteristics for MANETs require careful consideration, but the 115 same principles apply equally to other enterprise network scenarios. 117 This document specifies a Virtual Enterprise Traversal (VET) 118 abstraction for autoconfiguration and internetworking operation, 119 where addresses of different scopes may be assigned on various types 120 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 121 [RFC2460] are discussed within this context. The use of standard 122 DHCP [RFC2131][RFC3315] and neighbor discovery 123 [RFC0826][RFC1256][RFC4861] mechanisms is assumed unless otherwise 124 specified. 126 Provider-edge Interfaces 127 x x x 128 | | | 129 +--------------------+---+--------+----------+ E 130 | | | | | n 131 | I | | .... | | t 132 | n +---+---+--------+---+ | e 133 | t | +--------+ /| | r 134 | e I x----+ | Host | I /*+------+--< p I 135 | r n | |Function| n|**| | r n 136 | n t | +--------+ t|**| | i t 137 | a e x----+ V e|**+------+--< s e 138 | l r . | E r|**| . | e r 139 | f . | T f|**| . | f 140 | V a . | +--------+ a|**| . | I a 141 | i c . | | Router | c|**| . | n c 142 | r e x----+ |Function| e \*+------+--< t e 143 | t s | +--------+ \| | e s 144 | u +---+---+--------+---+ | r 145 | a | | .... | | i 146 | l | | | | o 147 +--------------------+---+--------+----------+ r 148 | | | 149 x x x 150 Enterprise-edge Interfaces 152 Figure 1: Enterprise Router (ER) Architecture 154 Figure 1 above depicts the architectural model for an Enterprise 155 Router (ER). As shown in the figure, an ER may have a variety of 156 interface types including enterprise-edge, enterprise-interior, 157 provider-edge, internal-virtual, as well as VET interfaces used for 158 IP-in-IP encapsulation. The different types of interfaces are 159 defined, and the autoconfiguration mechanisms used for each type are 160 specified. This architecture applies equally for MANET routers, in 161 which enterprise-interior interfaces correspond to the wireless 162 multihop radio interfaces typically associated with MANETs. Out of 163 scope for this document is the autoconfiguration of provider 164 interfaces, which must be coordinated in a manner specific to the 165 service provider's network. 167 Enterprise networks must have a means for supporting both Provider- 168 Independent (PI) and Provider-Aggregated (PA) IP prefixes. This is 169 especially true for enterprise scenarios that involve mobility and 170 multihoming. Also in scope are ingress filtering for multi-homed 171 sites, adaptation based on authenticated ICMP feedback from on-path 172 routers, effective tunnel path MTU mitigations and routing scaling 173 suppression as required in many enterprise network scenarios. 175 Recognizing that one size does not fit all, the VET specification 176 provides adaptable mechanisms that address these issues and more in a 177 wide variety of enterprise network use cases. 179 VET represents a functional superset of 6over4 [RFC2529] and ISATAP 180 [RFC5214], and further supports additional encapsulations such as 181 IPsec [RFC4301], SEAL [I-D.templin-seal], etc. As a result, VET 182 provides a map-and-encaps architecture using IP-in-IP tunneling based 183 on both IP routing and mapping service resolution (defined herein). 185 The VET principles can be either directly or indirectly traced to the 186 deliberations of the ROAD group in January 1992, and also to still 187 earlier works including NIMROD [RFC1753], the Catenet model for 188 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 189 the high-level architectural aspects of the ROAD group deliberations 190 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 191 IPNG". 193 VET is related to the present-day activites of the IETF autoconf, 194 dhc, ipv6, manet and v6ops working groups, as well as the IRTF rrg 195 working group. 197 2. Terminology 199 The mechanisms within this document build upon the fundamental 200 principles of IP-within-IP encapsulation. The terms "inner" and 201 "outer" are used to respectively refer to the innermost IP {address, 202 protocol, header, packet, etc.} *before* encapsulation, and the 203 outermost IP {address, protocol, header, packet, etc.} *after* 204 encapsulation. VET also allows for inclusion of "mid-layer" 205 encapsulations between the inner and outer layers, including IPSec 206 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 207 [I-D.templin-seal], etc. 209 The terminology in the normative references apply; the following 210 terms are defined within the scope of this document: 212 subnetwork 213 the same as defined in [RFC3819]. 215 enterprise 216 the same as defined in [RFC4852]. An enterprise is also 217 understood to refer to a cooperative networked collective with a 218 commonality of business, social, political, etc. interests. 219 Minimally, the only commonality of interest in some enterprise 220 network scenarios may be the cooperative provisioning of 221 connectivity itself. 223 site 224 a logical and/or physical grouping of interfaces that connect a 225 topological area less than or equal to an enterprise in scope. A 226 site within an enterprise can in some sense be considered as an 227 enterprise unto itself. 229 Mobile Ad-hoc Network (MANET) 230 a connected topology of mobile or fixed routers that maintain a 231 routing structure among themselves over dynamic links, where a 232 wide variety of MANETs share common properties with enterprise 233 networks. Characteristics of MANETs are defined in [RFC2501], 234 Section 3. 236 enterprise/site/MANET 237 throughout the remainder of this document, the term "enterprise" 238 is used to collectively refer to any of enterprise/site/MANET, 239 i.e., the VET mechanisms and operational principles can be applied 240 to enterprises, sites and MANETs of any size or shape. 242 Enterprise Router (ER) 243 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 244 mobile router that comprises a router function, a host function, 245 one or more enterprise-interior interfaces and zero or more 246 internal virtual, enterprise-edge, provider-edge and VET 247 interfaces. At a minimum, an ER forwards packets over one or more 248 sets of enterprise-interior interfaces, where each set connects to 249 a distinct enterprise. 251 Enterprise Border Router (EBR) 252 an ER that connects edge networks to the enterprise, and/or 253 connects multiple enterprises together. An EBR configures a 254 seperate VET interface over each set of enterprise-interior 255 interfaces that connect the EBR to each distinct enterprise. In 256 particular, an EBR may configure mulitple VET interfaces - one for 257 each distinct enterprise. All EBRs are also ERs. 259 Enterprise Border Gateway (EBG) 260 an EBR that connects VET interfaces configured over child 261 enterprises to a provider network - either directly via a 262 provider-edge interface, or indirectly via another VET interface 263 configured over a parent enterprise. EBRs may act as EBGs on some 264 VET interfaces and as ordinary EBRs on other VET interfaces. All 265 EBGs are also EBRs. 267 enterprise-interior interface 268 a ER's attachment to a link within an enterprise. Packets sent 269 over enterprise-interior interfaces may be forwarded over multiple 270 additional enterprise-interior interfaces within the enterprise 271 before they are forwarded via an enterprise-edge interface, 272 provider-edge interface or a VET interface configured over a 273 different enterprise. 275 enterprise-edge interface 276 an EBR's attachment to a link (e.g., an ethernet, a wireless 277 personal area network, etc.) on an arbitrarily-complex edge 278 network that the EBR connects to an enterprise and/or to provider 279 networks. 281 internal-virtual interface 282 a virtual interface that is a special case of either an 283 enterprise-edge or an enterprise-interior interface. Internal- 284 virtual interfaces that are also enterprise-edge interfaces are 285 often loopback interfaces of some form. Internal-virtual 286 interfaces that are also enterprise-interior interfaces are often 287 tunnel interfaces of some form configured over another enterprise- 288 interior interface. 290 provider-edge interface 291 an EBR's attachment to the Internet, or to a provider network 292 outside of the enterprise via which the Internet can be reached. 294 Virtual Enterprise Traversal (VET) 295 an abstraction that uses IP-in-IP encapsulation to create an 296 overlay that spans an enterprise in a single (inner) IP hop. 298 VET interface 299 an EBR's Non-Broadcast, Multiple Access (NBMA) interface used for 300 Virtual Enterprise Traversal. The EBR configures a VET interface 301 over a set of underlying enterprise-interior interface(s) 302 belonging to the same enterprise. When there are multiple 303 distinct enterprises (each with their own distinct set of 304 enterprise-interior interfaces), the EBR configures a separate VET 305 interface over each set of enterprise-interior interfaces, i.e., 306 the EBR configures multiple VET interfaces. 308 The VET interface encapsulates each inner IP packet in any mid- 309 layer headers plus an outer IP header then forwards it on an 310 underlying enterprise-interior interface such that the TTL/Hop 311 Limit in the inner header is not decremented as the packet 312 traverses the enterprise. The VET interface therefore presents an 313 automatic tunneling abstraction that represents the enterprise as 314 a single IP hop. 316 VET host 317 any node (host or router) that configures a VET interface for host 318 operation only. Note that a single node may configure some of its 319 VET interfaces as host interfaces and others as router interfaces. 321 VET node 322 any node that configures and uses a VET interface. 324 Provider-Independent (PI) prefix 325 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 326 that is either self-generated by a MR or delegated to an 327 enterprise by a registry. 329 Provider Aggregated (PA) prefix 330 an IPv6 or IPv4 prefix that is delegated to an enterprise by a 331 provider network. 333 Routing Locator (RLOC) 334 an IPv4 or IPv6 address taken from a PI/PA prefix that can appear 335 in enterprise-interior and/or interdomain routing tables. Global- 336 scope RLOC prefixes are delegated to specific enterprises and 337 routable within both the enterprise-interior and interdomain 338 routing regions. Enterprise-local-scope RLOC prefixes (e.g., IPv6 339 Unique Local Addresses [RFC4193], IPv4 privacy addresses 340 [RFC1918], etc.) are self-generated by individual enterprises and 341 routable only within the enterprise-interior routing region. 343 ERs use RLOCs for operating the enterprise-interior routing 344 protocol and for next-hop determination in forwarding packets 345 addressed to other RLOCs. End systems use RLOCs as addresses for 346 end-to-end communications that do not require VET encapsulation. 347 VET interfaces treat RLOCs as *outer* IP addresses during IP-in-IP 348 encapsulation. 350 Endpoint Interface iDentifier (EID) 351 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 352 within an enterprise-edge or VET overlay network scope, and may 353 also appear in enterprise-interior and/or interdomain mapping 354 tables. EID prefixes do not appear in enterprise-interior or 355 interdomain routing tables, and must be seperate and distinct from 356 any RLOC prefix space. 358 Edge network routers use EIDs for operating the enterprise-edge or 359 VET overlay network routing protocol and for next-hop 360 determination in forwarding addressed to other EIDs. End systems 361 use EIDs as addresses for end-to-end communications that require 362 VET encapsulation. VET interfaces treat EIDs as *inner* IP 363 addresses during IP-in-IP encapsulation. 365 The following additional acronyms are used throughout the document: 367 CGA - Cryptographically Generated Address 368 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 369 FIB - Forwarding Information Base 370 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 371 NBMA - Non-Broadcast, Multiple Access 372 ND - Neighbor Discovery 373 PIO - Prefix Information Option 374 PRL - Potential Router List 375 PRLNAME - Identifying name for the PRL (default is "isatap") 376 RIO - Route Information Option 377 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 378 SEAL - Subnetwork Encapsulation and Adaptation Layer 379 SLAAC - IPv6 StateLess Address AutoConfiguation 381 3. Enterprise Characteristics 383 Enterprises consist of links that are connected by Enterprise Routers 384 (ERs) as depicted in Figure 1. ERs typically participate in a 385 routing protocol over enterprise-interior interfaces to discover 386 routes that may include multiple Layer-2 or Layer-3 forwarding hops. 387 Enterprise Border Routers (EBRs) are ERs that connect edge networks 388 to the enterprise and/or join multiple enterprises together. 389 Enterprise Border Gateways (EBGs) are EBRs that either directly or 390 indirectly connect enterprises to provider networks. 392 An enterprise may be as simple as a small collection of ERs and their 393 attached edge networks; an enterprise may also contain other 394 enterprises and/or be a subnetwork of a larger enterprise. An 395 enterprise may further encompass a set of branch offices and/or 396 nomadic hosts connected to a home office over one or several service 397 providers, e.g., through Virtual Private Network (VPN) tunnels. 399 Enterprises that comprise link types with sufficiently similar 400 properties (e.g., Layer-2 (L2) address formats, maximum transmission 401 units (MTUs), etc.) can configure a sub-IP layer routing service such 402 that IP sees the enterprise as an ordinary shared link the same as 403 for a (bridged) campus LAN. In that case, a single IP hop is 404 sufficient to traverse the enterprise without IP layer encapsulation. 406 Enterprises that comprise link types with diverse properties and/or 407 configure multiple IP subnets must also provide a routing service 408 that operates as an IP layer mechanism. In that case, multiple IP 409 hops may be necessary to traverse the enterprise such that care must 410 be taken to avoid multilink subnet issues [RFC4903]. 412 Conceptually, an ER embodies both a host function and router 413 function. The host function supports Endpoint Interface iDentifier 414 (EID)-based and/or Routing LOCator (RLOC)-based communications 415 according to the weak end system model [RFC1122]. The router 416 function engages in the enterprise-interior routing protocol, 417 connects any of the ER's edge networks to the enterprise and may also 418 connect the enterprise to provider networks (see: Figure 1). 420 In addition to other interface types, VET nodes configure VET 421 interfaces that view all other VET nodes in an enterprise as single- 422 hop neighbors attached to an imaginary Non-Broadcast, Multiple Access 423 (NBMA) link. VET nodes configure a separate VET interface for each 424 distinct enterprise to which they connect, and discover other EBRs on 425 each VET interface that can be used for forwarding packets to off- 426 enterprise destinations. 428 For each distinct enterprise, an enterprise trust basis must be 429 established and consistently applied. For example, in enterprises in 430 which EBRs establish symmetric security associations, mechanisms such 431 as IPsec [RFC4301] can be used to assure authentication and 432 confidentiality. In other enterprise network scenarios, asymmetric 433 securing mechanisms such as SEcure Neighbor Discovery (SEND) 434 [RFC3971] may be necessary to authenticate exchanges based on trust 435 anchors. 437 Finally, in enterprises with a centralized management structure 438 (e.g., a corporate campus network), the enterprise name service and a 439 synchronized set of EBGs can provide infrastructure support for 440 virtual enterprise traversal. In that case, the EBGs can provide a 441 "default mapper" [I-D.jen-apt] service used for short term packet 442 forwarding until EBR neighbor relationships can be established. In 443 enterprises with a distributed management structure (e.g., MANETs), 444 peer-to-peer coordination between the EBRs themselves may be 445 required. Recognizing that various use cases will entail a continuum 446 between a fully-distributed and fully-centralized approach, the 447 following sections present the mechanisms of Virtual Enterprise 448 Traversal as they apply to a wide variety of scenarios. 450 4. Autoconfiguration 452 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 453 specified in the following subsections: 455 4.1. Enterprise Router (ER) Autoconfiguration 457 ERs configure enterprise-interior interfaces and engage in any 458 routing protocols over those interfaces. 460 When an ER joins an enterprise, it first configures a unique IPv6 461 link-local address on each enterprise-interior interface that 462 requires an IPv6 link-local capability and an IPv4 link-local address 463 on each enterprise-interior interface that requires an IPv4 link- 464 local capability. IPv6 link-local address generation mechanisms that 465 provide sufficient uniqueness include Cryptographically Generated 466 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 467 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 468 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 469 provide an IPv4 link-local address generation capability. 471 Next, the ER configures an RLOC on each of its enterprise-interior 472 interfaces and engages in any routing protocols on those interfaces. 473 The ER can configure an RLOC via explicit management, DHCP 474 autoconfiguration, pseudo-random self-generation from a suitably 475 large address pool, or through an alternate autoconfiguration 476 mechanism. 478 Alternatively (or in addition), the ER can request RLOC prefix 479 delegations via an automated prefix delegation exchange over an 480 enterprise-interior interface, and can assign the prefix(es) on 481 enterprise edge interfaces. In that case, the ER can leave 482 enterprise-interior interfaces unnumbered and use an RLOC assigned to 483 an enterprise-edge interface for enterprise-interior routing protocol 484 operation and next-hop determination purposes. Note that in some 485 cases, the same enterprise edge interfaces may assign both RLOC and 486 an EID addresses if there is a means for source address selection. 487 In other cases (e.g., for separation of security domains), RLOCs and 488 EIDs must be assigned on seperate sets of enterprise edge interfaces. 490 Self-generation of RLOCs for IPv6 can be from a large IPv6 local-use 491 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 492 generation of RLOCs for IPv4 can be from a large IPv4 private address 493 range (e.g., [RFC1918]). When self-generation is used alone, the ER 494 must continuously monitor the RLOCs for uniqueness, e.g., by 495 monitoring the routing protocol. 497 DHC generation of RLOCs may require support from relays within the 498 enterprise. For DHCPv6, relays that do not already know the RLOC of 499 a server within the enterprise relay requests to the 500 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 501 relays that do not already know the RLOC of a server within the 502 enterprise relay requests to the site-scoped IPv4 multicast group 503 address 'All_DHCPv4_Servers' (see: Section 6). DHCPv4 servers that 504 delegate RLOCs join the 'All_DHCPv4_Servers' multicast group and 505 service any DHCPv4 messages received for that group. 507 A combined approach using both DHCP and self-generation is also 508 possible when the ER configures both a DHCP client and relay that are 509 connected, e.g., via a pair of back-to-back connected ethernet 510 interfaces, a tun/tap interface, a loopback interface, inter-process 511 communication, etc. The ER first self-generates a temporary RLOC 512 used only for the purpose of procuring an actual RLOC taken from a 513 disjoint addressing range. The ER then assigns the temporary RLOC to 514 an enterprise-interior interface, engages in the routing protocol and 515 performs a DHCP client/relay exchange using the temporary RLOC as the 516 address of the relay. When the DHCP server delegates an actual RLOC 517 addres/prefix, the ER abandons the temporary RLOC and re-engages in 518 the routing protocol using an RLOC taken from the delegation. 520 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 521 enterprise-interior interfaces as singleton addresses (i.e., as /32s 522 for IPv4 and /128s for IPv6) may be necessary to avoid multilink 523 subnet issues. 525 4.2. Enterprise Border Router (EBR) Autoconfiguration 527 EBRs are ERs that configure VET interfaces over distinct sets of 528 underlying enterprise-interior interfaces; an EBR can connect to 529 multiple enterprises, in which case it would configure multiple VET 530 interfaces. In addition to the ER autoconfiguration procedures 531 specified in Section 4.1 EBRs perform the following autoconfiguration 532 operations: 534 4.2.1. VET Interface Autoconfiguration 536 VET interface autoconfiguration entails: 1) interface initialization, 537 2) EBG discovery and enterprise identification, and 3) EID 538 configuration. These functions are specified in the following 539 sections: 541 4.2.1.1. Interface Initialization 543 EBRs configure a VET interface over a set of underlying enterprise- 544 interior interfaces belonging to the same enterprise, where the VET 545 interface presents a Non-Broadcast, Multiple Access (NBMA) 546 abstraction in which all EBRs in the enterprise appear as single hop 547 neighbors through the use of IP-in-IP encapsulation. After the EBR 548 configures a VET interface, it initializes the interface and assigns 549 a link-local address if necessary. 551 When IPv6 and IPv4 are used as the inner/outer protocols 552 (respectively), the EBR autoconfigures an ISATAP link-local address 553 ([RFC5214], Section 6.2) on the VET interface to support packet 554 forwarding and operation of the IPv6 neighbor discovery protocol. 555 The ISATAP link-local address embeds an IPv4 RLOC, and need not be 556 checked for uniqueness since the IPv4 RLOC itself is managed for 557 uniqueness (see: Section 4.1). 559 Link-local address configuration for other inner/outer IP protocol 560 combinations is through administrative configuration or through an 561 unspecified alternate method. Link local address configuration for 562 other inner/outer IP protocol combinations may not be necessary if an 563 EID can be configured through other means (see: Section 4.2.1.3). 565 After the EBR initializes a VET interface, it can communicate with 566 other VET nodes as single-hop neighbors on the VET interface from the 567 viewpoint of the inner IP protocol. 569 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 570 Identification 572 The EBR next discovers a list of EBGs for each of its VET interfaces. 573 The list can be discovered through information conveyed in the 574 routing protocol, through the Potential Router List (PRL) discovery 575 mechanisms outlined in ([RFC5214], Section 8.3.2), through DHCP 576 options, etc. In multicast-capable enterprises, EBRs can also listen 577 for advertisements on the 'rasadv' [RASADV] multicast group address. 579 In particular, whether or not routing information is available the 580 EBR can discover the list of EBGs by resolving an identifying name 581 for the PRL ('PRLNAME') formed as 'hostname.domainname', where 582 'hostname' is an enterprise-specific name string and 'domainname' is 583 an enterprise-specific DNS suffix. The EBR discovers 'PRLNAME' 584 through manual configuration, a DHCP option, 'rasadv' protocol 585 advertisements, link-layer information (e.g., an IEEE 802.11 SSID) or 586 through some other means specific to the enterprise. In the absence 587 of other information, the EBR sets the 'hostname' component of 588 'PRLNAME' to "isatap" and sets the 'domainname' component only if an 589 enterprise-specifc DNS suffix "example.com" is known (e.g., as 590 "isatap.example.com"). 592 The global Internet interdomain routing core represents a specific 593 example of an enterprise network scenario, albeit on an enormous 594 scale. The 'PRLNAME' assigned to the global Internet interdomain 595 routing core is "isatap.net". 597 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 598 resolving 'PRLNAME' to a list of RLOC addresses through a name 599 service lookup. For centrally-managed enterprises, the EBR resolves 600 'PRLNAME' using an enterprise-local name service (e.g., the 601 enterprise-local DNS). For enterprises with a distributed management 602 structure, the EBR resolves 'PRLNAME' using LLMNR [RFC4759] over the 603 VET interface. In that case, all EBGs in the PRL respond to the 604 LLMNR query, and the EBR accepts the union of all responses. 606 Each distinct enterprise must have a unique identity that EBRs can 607 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 608 well as the RLOCs of EBGs and the IP prefixes they aggregate serve as 609 an identifier for the enterprise. 611 4.2.1.3. EID Configuration 613 After EBG discovery, the EBR configures EIDs on its VET interfaces. 614 When IPv6 and IPv4 are used as the inner/outer protocols 615 (respectively), the EBR autoconfigures EIDs as specified in 616 Section 5.4.1. In particular, the EBR acts as a host on its VET 617 interfaces for router and prefix discovery purposes but acts as a 618 router on its VET interfaces for routing protocol operation and 619 packet forwarding purposes. 621 EID configuration for other inner/outer IP protocol combinations is 622 through administrative configuration or through an unspecified 623 alternate method; in some cases, such EID configuration can be 624 performed independently of EBG discovery. 626 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 628 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 629 autoconfiguration exchanges with EBGs over VET interfaces, where each 630 EBG may be configured as either a DHCP relay or DHCP server. 632 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 633 delegation exchange, explicit management, etc. 635 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 636 exchanges. In particular, the EBR (acting as a requesting router) 637 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 638 obtain IPv6 EID prefixes from the server (acting as a delegating 639 router). 641 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 642 exchange [RFC3315]. For example, to perform the 2-message exchange 643 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 644 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 645 relay (see: Section 4.1). The relay then forwards the message over 646 the VET interface to an EBG, which either services the request or 647 relays it further. The forwarded Solicit message will elicit a reply 648 from the server containing PA IPv6 prefix delegations. 650 The EBR can propose a specific prefix to the DHCPv6 server per 651 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 652 available. The server will check the proposed prefix for consistency 653 and uniqueness, then return it in the reply to the EBR if it was able 654 to perform the delegation. 656 After the EBR receives PA prefix delegations, it can provision the 657 prefixes on enterprise-edge interfaces as well as on other VET 658 interfaces for which it is configured as an EBG. 660 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 662 Independent of any PA prefixes, EBRs can acquire and use Provider- 663 Independent (PI) EID prefixes that are self-configured (e.g., using 664 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 665 using [I-D.ietf-ipv6-ula-central], etc.). When an EBR acquires a PI 666 prefix, it must also obtain credentials that it can use to prove 667 prefix ownership when it registers the prefixes with EBGs within an 668 enterprise (see: Section 5.4 and Section 5.5). 670 After the EBR receives PI prefix delegations, it can provision the 671 prefixes on enterprise-edge interfaces as well as on other VET 672 interfaces for which it is configured as an EBG. 674 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 676 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 678 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 680 EBGs are EBRs that connect child enterprises to provider networks via 681 provider-edge interfaces and/or via VET interfaces configured over 682 parent enterprises. EBGs autoconfigure their provider-edge 683 interfaces in a manner that is specific to the provider connections, 684 and autoconfigure their VET interfaces configured over parent 685 interfaces using the EBR autoconfiguration procedures specified in 686 Section 4.2. 688 For each of its VET interfaces configured over a child enterprise, 689 the EBG initializes the interface and configures an EID the same as 690 for an ordinary EBR (see: Section 4.2.1). It must then arrange to 691 add one or more of its RLOCs associated with the child enterprise to 692 the PRL, and must maintain these resource records in accordance with 693 ([RFC5214], Section 9). In particular, for each VET interface 694 configured over a child enterprise the EBG adds the RLOCs to name 695 service resource records for 'PRLNAME'. 697 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 698 configured over child enterprises with a distributed management 699 structure. 701 EBGs configure a DHCP relay/server on VET interfaces configured over 702 child enterprises that require DHCP services. 704 To avoid looping, EBGs MUST NOT configure a default route on a VET 705 interface configued over a child interface. 707 4.4. VET Host Autoconfiguration 709 Nodes that cannot be attached via an EBR's enterprise-edge interface 710 (e.g., nomadic laptops that connect to a home office via a Virtual 711 Private Network (VPN)) can instead be configured for operation as a 712 simple host connected to the VET interface. Such VET hosts perform 713 the same VET interface autoconfiguration procedures as specified for 714 EBRs in Section 4.2.1, but they configure their VET interfaces as 715 host interfaces (and not router interfaces). VET hosts can then send 716 packets to the EID addresses of other hosts on the VET interface, or 717 to off-enterprise EID destinations via a next-hop EBR. 719 Note that a node may be configured as a host on some VET interfaces 720 and as an EBR/EBG on other VET interfaces. 722 5. Internetworking Operation 724 Following the autoconfiguration procedures specified in Section 4, 725 ERs, EBRs, EBGs and VET hosts engage in normal internetworking 726 operations as discussed in the following sections: 728 5.1. Routing Protocol Participation 730 Following autoconfiguration, ERs engage in any RLOC-based IP routing 731 protocols and forward IP packets with RLOC addresses. EBRs can 732 additionally engage in any EID-based IP routing protocols and forward 733 IP packets with EID addresses. Note that the EID-based IP routing 734 domains are separate and distinct from any RLOC-based IP routing 735 domains. 737 5.2. RLOC-based Communications 739 When permitted by policy and supported by routing, end systems can 740 avoid VET interface encapsulation through communications that 741 directly invoke the outer IP protocol using RLOC addresses instead of 742 EID addresses. End systems can use source address selection rules to 743 determine whether to use EID or RLOC addresses based on, e.g., name 744 service records. 746 5.3. EID-based Communications 748 In many enterprise scenarios, the use of EID-based communications 749 (i.e., instead of RLOC-based communications) may be necessary and/or 750 beneficial to support address scaling, NAT avoidance, security domain 751 separation, site multi-homing, traffic engineering, etc. 753 The remainder of this section discusses internetworking operation for 754 EID-based communications using the VET interface abstraction. 756 5.4. IPv6 Router Discovery and Prefix Registration 758 The following sections discuss router and prefix discovery 759 considerations for the case of IPv6 as the inner IP protocol: 761 5.4.1. IPv6 Router and Prefix Discovery 763 EBGs follow the router and prefix discovery procedures specified in 764 ([RFC5214], Section 8.2). They send solicited RAs over VET 765 interfaces for which they are configured as gateways with default 766 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 767 with any other required options/parameters. EBGs must set the 'M' 768 flag in RAs to 0, since the use of DHCPv6 for address configuration 769 on VET interfaces is undefined. EBGs can also include PIOs with the 770 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 771 of an aggregated prefix from which it is willing to delegate longer 772 PA prefixes. 774 VET nodes follow the router and prefix discovery procedures specified 775 in ([RFC5214], Section 8.3). They discover EBGs within the 776 enterprise as specified in Section 4.2.1.2, then perform RS/RA 777 exchanges with the EBGs to establish and maintain default routes. In 778 particular the VET node sends unicast RS messages to EBGs over its 779 VET interface(s) to receive RAs. Depending on the enterprise network 780 trust basis, VET nodes may be required to use SEND to secure the 781 RS/RA exchanges. 783 When the VET node receives an RA, it authenticates the message then 784 configures a default route based on the Router Lifetime. If the RA 785 contains Prefix Information Options (PIOs) with the 'A' and 'L' bits 786 set to 1, the VET node also autoconfigures IPv6 addresses from the 787 advertised prefixes using SLAAC and assigns them to the VET 788 interface. Thereafter, the VET node accepts packets that are 789 fowarded by EBGs for which it has current default routing information 790 (i.e., ingress filtering is based on the default router trust 791 relationship rather than a prefix-specific ingress filter entry). 793 In enterprises in which DHCPv6 is preferred, DHCPv6 exchanges between 794 EBRs and EBGs may be sufficient to convey default router and prefix 795 information. In that case, RS/RA exchanges may not be necessary. 797 5.4.2. IPv6 PA Prefix Registration 799 After an EBR discovers default routes, it can use DHCP prefix 800 delegation to obtain PA prefixes via an EBG as specified in 801 Section 4.2.2. The DHCP server ensures that the delegations are 802 unique and that the EBG's router function will forward IP packets 803 over the VET interface to the correct EBR. In particular, the EBG 804 must register and track the PA prefixes that are delegated to each 805 EBR. 807 The PA prefix registrations remain active in the EBGs as long as the 808 EBR continues to issue DHCP renewals over the VET interface before 809 lease lifetimes expire. The lease lifetime also keeps the delegation 810 state active even if communications between the EBR and DHCP server 811 are disrupted for a period of time (e.g., due to an enterprise 812 network partition) before being reestablished (e.g., due to an 813 enterprise network merge). 815 5.4.3. IPv6 PI Prefix Registration 817 After an EBR discovers default routes, it must register its PI 818 prefixes by sending RAs to a set of one or more EBGs with Route 819 information Options (RIOs) [RFC4191] that contain the EBR's PI 820 prefixes. Each RA must include the RLOC of an EBG as the outer IP 821 destination address and a link-local address assigned to the VET 822 interface as the inner IP destination address. For enterprises that 823 use SEND, the RAs also include a CGA link-local inner source address 824 along with SEND credentials plus any certificates needed to prove 825 ownership of the PI prefixes. The EBR additionally tracks the set of 826 EBGs that it sends RAs to so that it can send subsequent RAs to the 827 same set. 829 When the EBG receives the RA, it first authenticates the message; if 830 the authentication fails, the EBG discards the RA. Otherwise, the 831 EBG installs the PI prefixes with their respective lifetimes in its 832 Forwarding Information Base (FIB) and configures them for both 833 ingress filtering [RFC3704] and forwarding purposes. In particular, 834 the EBG configures the FIB entries as ingress filter rules to accept 835 packets received on the VET interface that have a source address 836 taken from the PI prefixes. It also configures the FIB entries to 837 forward packets received on other interfaces with a destination 838 address taken from the PI prefixes to the EBR that registered the 839 prefixes on the VET interface. 841 The EBG then publishes the PI prefixes in a distributed database 842 (e.g., in a private instance of a routing protocol in which only EBGs 843 participate, via an automated name service update mechanism 844 [RFC3007], etc.). For enterprises that are managed under a 845 centralized administrative authority, the EBG also publishes the PI 846 prefixes in the enterprise-local name service (e.g., the enterprise- 847 local DNS [RFC1035]). 849 In particular, the EBG publishes each /56 prefix taken from the PI 850 prefixes as a seperate FQDN that consists of a sequence of 14 nibbles 851 in reverse order (i.e., the same as in [RFC3596], Section 2.5) 852 followed by the string 'ip6' followed by the string 'PRLNAME'. For 853 example, when 'PRLNAME' is "isatap.example.com", the EBG publishes 854 the prefix '2001:DB8::/56' as: 855 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. The EBG 856 includes the outer RLOC source address of the RA (e.g., in a DNS A 857 resource record) in each prefix publication. For enterprises that 858 use SEND, the EBG also includes the inner IPv6 CGA source address 859 (e.g., in a DNS AAAA record) in each prefix publication. If the 860 prefix was already installed in the distributed database, the EBG 861 instead adds the outer RLOC source address (e.g., in an additional 862 DNS A records) to the pre-existing publication to support PI prefixes 863 that are multihomed. For enterprises that use SEND, this latter 864 provision requires all EBRs of a multihomed site that advertise the 865 same PI prefixes in RAs to use the same CGA and the same SEND 866 credentials. 868 After the EBG authenticates the RA and publishes the PI prefixes, it 869 next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the 870 VET interfaces configured over any of its parent enterprises and 871 relays a proxied RA to the EBGs on those interfaces. (For 872 enterprises that use SEND, the EBG additionally acts as a SEcure 873 Neighbor Discovery Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) 874 EBGs in parent enterprises that receive the proxied RAs in turn act 875 as NDProxys/SENDProxys to relay the RAs to EBGs on their parent 876 enterprises, etc. The RA proxying and PI prefix publication recurses 877 in this fashion and ends when an EBR attached to an interdomain 878 routing core is reached. 880 After the initial PI prefix registration, the EBR that owns the 881 prefix(es) must periodically send additional RAs to its set of EBGs 882 to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in 883 parent enterprises that it relays the proxied RAs to, and should 884 relay subsequent RAs to the same set. 886 This procedure has a direct analogy in the Teredo method of 887 maintaining state in network middleboxes through the periodic 888 transmission of "bubbles" [RFC4380]. 890 5.4.4. IPv6 Next-Hop EBR Discovery 892 VET nodes discover destination-specific next-hop EBRs within the 893 enterprise by querying the name service for the /56 IPv6 PI prefix 894 taken from a packet's destination address, by forwarding packets via 895 a default route to an EBG, or by some other inner IP to outer IP 896 address mapping mechansim. For example, for the IPv6 destination 897 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 898 node can lookup the domain name: 899 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. If the name 900 service lookup succeeds, it will return RLOC addresses (e.g., in DNS 901 A records) that correspond to the RLOCs assigned to enterprise 902 interior interfaces of next-hop EBRs to which the VET node can 903 forward packets. (In enterprises that use SEND, it will also return 904 an IPv6 CGA address, e.g., in a DNS AAAA record.) 906 Name service lookups in enterprises with a centralized management 907 structure use an infrastructure-based service, e.g., an enterprise- 908 local DNS. Name service lookups in enterprises with a distributed 909 management structure and/or that lack an infrastructure-based name 910 service instead use LLMNR over the VET interface. When LLMNR is 911 used, the EBR that performs the lookup sends an LLMNR query (with the 912 /56 prefix taken from the IP destination address encoded in dotted- 913 nibble format as shown above) and accepts the union of all replies it 914 receives from other EBRs on the VET interface. When an EBR receives 915 an LLMNR query, it responds to the query IFF it aggregates an IP 916 prefix that covers the prefix in the query. 918 Alternatively, in enterprises with a stable and highly-available set 919 of EBGs, the VET node can simply forward an initial packet via a 920 default route to an EBG. The EBG will forward the packet to a next- 921 hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] 922 (using SEND, if necessary). If the packet's source address is on- 923 link on the VET interface, the EBG returns an ordinary "router-to- 924 host" redirects with the source address of the packet as its 925 destination. If the packet's source address is not on-link, the EBG 926 instead returns a "router-to-router" redirect with the link-local 927 ISATAP address of the previous-hop EBR as its destination. When IPv4 928 is used as the outer IP protocol, the EBG also includes in the 929 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 930 contain the IPv4 RLOCs of potential next-hop EBRs arranged in order 931 from highest to lowest priority (i.e., the first LLAO contains the 932 highest priority RLOC and the final LLAO option contains the lowest 933 priority). These LLAOs are formatted using a modified version of the 934 form specified in ( [RFC2529], Section 5) as shown in Figure 2 (the 935 LLAO format for IPv6 as the outer IP protocol is out of scope): 937 +-------+-------+-------+-------+-------+-------+-------+-------+ 938 | Type |Length | TTL | IPv4 Address | 939 +-------+-------+-------+-------+-------+-------+-------+-------+ 941 Figure 2: VET Link-Layer Address Option Format 943 For each such IPv6/IPv4 LLAO, the Type is set to 2 (for Target Link- 944 Layer Address Option), Length is set to 1, and IPv4 Address is set to 945 the IPv4 RLOC of the next-hop EBR. TTL is set to the time in seconds 946 that the recipient may cache the RLOC, where the value 65535 947 represents infinity and the value 0 suspends forwarding through this 948 RLOC. 950 When a VET host receives an ordinay "router-to-host" redirect, it 951 processes the redirect exacly as specified in [RFC4861], Section 8. 952 When an EBR receives a "router-to-router" redirect, it discovers the 953 RLOC addresses of potential next-hop EBRs by examining the LLAOs 954 included in the redirect. The EBR then installs a FIB entry that 955 contains the /56 prefix of the destination address encoded in the 956 redirect and the list of RLOCs of potential next-hop EBRs. The EBR 957 then enables the FIB entry for forwarding to next-hop EBRs but DOES 958 NOT enable it for ingress filtering acceptance of packets from next- 959 hop EBRs (i.e., the forwarding determination is unidirectional). 961 In enterprises in which spoofing is possible, after discovering 962 potential next-hop EBRs (either through name service lookup or ICMP 963 redirect) the EBR must send authenticating credentials before 964 forwarding packets via the next-hops. To do so, the EBR must send 965 RAs over the VET interface (using SEND, if necessary) to one or more 966 of the potential next-hop EBRs with an RLOC as the outer IP 967 destination address. The RAs must include a Route Information Option 968 (RIO) [RFC4191] that contains the /56 PI prefix of the original 969 packet's source address. After sending the RAs, the EBR can either 970 enable the new FIB entry for forwarding immediately or delay until it 971 receives an explicit acknowledgement that a next-hop EBR received the 972 RA (e.g., using the SEAL explicit acknowledgement mechanism - see: 973 Section 5.7). 975 When a next-hop EBR receives the RA, it authenticates the message 976 then performs a name service lookup on the prefix in the RIO if 977 further authenticating evidence is required. If the name service 978 returns resource records that are consistent with the inner and outer 979 IP addresses of the RA, the next-hop EBR then installs the prefix in 980 the RIO in its FIB and enables the FIB entry for ingress filtering 981 but DOES NOT enable it for forwarding purposes. After an EBR sends 982 initial RAs following a redirect, it should send periodic RAs to 983 refresh the next-hop EBR's ingress filter prefix lifetimes as long as 984 traffic is flowing. 986 EBRs retain the FIB entrys created as result of an ICMP redirect 987 until all RLOC TTLs expire, or until no hints of forward progress 988 through any of the associated RLOCs are received. In this way, RLOC 989 liveness detection exactly parallels IPv6 Neighbor Unreachability 990 Detection ([RFC4861], Section 3). 992 5.5. IPv4 Router Discovery and Prefix Registration 994 When IPv4 is used as the inner IP protocol, router discovery and 995 prefix registration exactly parallels the mechanisms specified for 996 IPv6 in Section 5.4. To support this, modifications to the ICMPv4 997 Router Advertisement [RFC1256] function to include SEND constructs, 998 and modifications to the ICMPv4 Redirect [RFC0792] function to 999 support router-to-router redirects will be specified in a future 1000 document. Additionally, publications for IPv4 prefixes will be in 1001 dotted-nibble format in the 'ip4.isatap.example.com' domain. For 1002 example, the IPv4 prefix 192.0.2/24 would be represented as: 1003 '2.0.0.0.0.c.ip4.isatap.example.com'. 1005 5.6. VET Encapsulation 1007 VET nodes forward packets by consulting the FIB to determine a 1008 specific EBR/EBG as the next-hop router on a VET interface. When 1009 multiple next-hop routers are available, VET nodes can use default 1010 router preferences, routing protocol information, traffic engineering 1011 configurations, etc. to select the best exit router. When there is 1012 no FIB information other than "default" available, VET nodes can 1013 discover the next-hop EBR/EBG through the mechanisms specified in 1014 Section 5.4 and Section 5.5. 1016 VET interfaces encapsulate inner IP packets in any mid-layer headers 1017 followed by an outer IP header according to the specific 1018 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal], 1019 etc.); they next submit the encapsulated packet to the outer IP 1020 forwarding engine for transmission on an underlying enterprise- 1021 interior interface. 1023 For forwarding to next-hop addresses over VET interfaces that use 1024 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 1025 address (i.e., the IPv4 RLOC of the next-hop EBR) through static 1026 extraction of the IPv4 address embedded in the next-hop ISATAP 1027 address. For other IP-in-IP encapsulations, determination of the 1028 outer destination address is through administrative configuration or 1029 through an unspecified alternate method. When there are multiple 1030 candidate destination RLOCs available, the VET node should only 1031 select an RLOC for which there is current forwarding information in 1032 the outer IP protocol FIB. 1034 5.7. SEAL Encapsulation 1036 VET nodes should use SEAL encapsulation [I-D.templin-seal] over VET 1037 interfaces to accommdate path MTU diversity, to defeat source address 1038 spoofing, and to monitor next-hop EBR reachability. SEAL 1039 encapsulation maintains a unidirectional and monotonically- 1040 incrementing per-packet identification value known as the 'SEAL_ID'. 1041 When a VET node that uses SEAL encapsulation sends a SEND-protected 1042 Router Advertisement (RA) or Router Solicitation (RS) message to 1043 another VET node, both nodes cache the new SEAL_ID as per-tunnel 1044 state used for maintaining a window of unacknowledged SEAL_IDs. 1046 In terms of security, when a VET node receives an ICMP message, it 1047 can confirm that the packet-in-error within the ICMP message 1048 corresponds to one of its recently-sent packets by examining the 1049 SEAL_ID along with source and destination addresses, etc. 1050 Additionally, a next-hop EBR can track the SEAL_ID in packets 1051 received from EBRs for which there is an ingress filter entry and 1052 discard packets that have SEAL_ID values outside of the current 1053 window. 1055 In terms of next-hop reachability, an EBR can set the SEAL 1056 "Acknowledgement Requested" bit in messages to receive confirmation 1057 that a next-hop EBR is reachable. Setting the "Acknowledgement 1058 Requested" bit is also used as the method for maintaining the window 1059 of outstanding SEAL_ID's. 1061 5.8. Generating Errors 1063 When an EBR receives a packet over a VET interface and there is no 1064 matching ingress filter entry, it drops the packet and returns an 1065 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 1066 ingress/egress policy" message to the previous hop EBR subject to 1067 rate limiting. 1069 When an EBR receives a packet over a VET interface, and there is no 1070 longest-prefix-match FIB entry for the destination, it returns an 1071 ICMPv6 "Destination Unreachable; No route to destination" message to 1072 the previous hop EBR subject to rate limiting. 1074 When an EBR receives a packet over a VET interface and the longest- 1075 prefix-match FIB entry for the destination is via a next-hop 1076 configured over the same VET interface the packet arrived on, the EBR 1077 forwards the packet then (if the FIB prefix is longer than ::/0) 1078 sends a router-to-router ICMPv6 Redirect message (using SEND, if 1079 necessary) to the previous hop EBR as specified in Section 5.4.4. 1081 Generation of other ICMPv6 messages (e.g., ICMPv6 "Packet Too Big") 1082 is the same as for any IPv6 interface. 1084 5.9. Processing Errors 1086 When an EBR receives an ICMPv6 "Destination Unreachable; Source 1087 address failed ingress/egress policy" message from a next-hop EBR, 1088 and there is a longest-prefix-match FIB entry for the original 1089 packet's destination that is more-specific than ::/0, the EBR 1090 discards the message and marks the FIB entry for the destination as 1091 "forwarding suspended" for the RLOC taken from the source address of 1092 the ICMPv6 message. The EBR should then allow subsequent packets to 1093 flow through different RLOCs associated with the FIB entry until it 1094 forwards a new RA to the suspended RLOC. If the EBR receives 1095 excessive ICMPv6 ingress policy errors through multiple RLOCs 1096 associated with the same FIB entry, it should delete the FIB entry 1097 and allow subsequent packets to flow through an EBG if supported in 1098 the specific enterprise scenario. 1100 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1101 to destination" message from a next-hop EBR, it forwards the ICMPv6 1102 message to the source of the original packet as normal. If the EBR 1103 has longest-prefix-match FIB entry for the original packet's 1104 destination that is more-specific than ::/0, the EBR also deletes the 1105 FIB entry. 1107 When an EBR receives an authentic ICMPv6 Redirect, it processes the 1108 packet as specified in Section 5.4.4. 1110 When an EBG receives new mapping information for a specific 1111 destination prefix, it can propagate the update to other EBRs/EBGs by 1112 sending an ICMPv6 redirect message to the 'All Routers' link-local 1113 multicast address with a LLAO with the TTL for the unreachable LLAO 1114 set to zero, and with a NULL packet in error. 1116 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 1117 Unreachable; net / host unreachable" messages from an ER indicating 1118 that the path to a VET neighbor may be failing. The EBR should first 1119 check, e.g., the SEAL_ID, IPsec sequence number, source address of 1120 the original packet if available, etc. to obtain reasonable assurance 1121 that the ICMP message is authentic, then should mark the longest- 1122 prefix-match FIB entry for the destination as "forwarding suspended" 1123 for the RLOC destination address of the ICMPv4 packet-in-error. If 1124 the EBR receives excessive ICMPv4 unreachable errors through multiple 1125 RLOCs associated with the same FIB entry, it should delete the FIB 1126 entry and allow subsequent packets to flow through a different route. 1128 5.10. Mobility and Multihoming Considerations 1130 EBRs that travel between distinct enterprise networks must either 1131 abandon their PA prefixes that are relative to the "old" enterprise 1132 and obtain new ones relative to the "new" enterprise, or somehow 1133 coordinate with a "home" enterprise to retain ownership of the 1134 prefixes. In the first instance, the EBR would be required to 1135 coordinate a network renumbering event using the new PA prefixes 1136 [RFC4192]. In the second instance, an ancillary mobilitiy management 1137 mechanism must be used. 1139 EBRs can retain their PI prefixes as they travel between distinct 1140 enterprise networks as long as they register the prefixes with new 1141 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 1142 departure. Prefix registration with new EBGs is coordinated exactly 1143 as specified in Section 5.4.3; prefix withdrawl from old EBGs is 1144 simply through re-announcing the PI prefixes with zero lifetimes. 1146 Since EBRs can move about independently of one another, stale FIB 1147 entry state may be left in VET nodes when a neighboring EBR departs. 1148 Additionally, EBRs can lose state for various reasons, e.g., power 1149 failure, machine reboot, etc. For this reason, EBRs are advised to 1150 set relatively short PI prefix lifetimes in RIO options, and to send 1151 additional RAs to refresh lifetimes before they expire. (EBRs should 1152 place conservative limits on the RAs they send to reduce congestion, 1153 however.) 1155 EBRs may register their PI prefixes with multiple EBGs for 1156 multihoming purposes. EBRs should only forward packets via EBGs with 1157 which it has registered its PI prefixes, since other EBGs may drop 1158 the packets and return ICMPv6 "Destination Unreachable; Source 1159 address failed ingress/egress policy" messages. 1161 EBRs can also act as delegating routers to sub-delegate portions of 1162 their PI prefixes to requesting routers on their enterprise edge 1163 interfaces and on VET interfaces for which they are configured as 1164 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1165 become the PA prefixes for downstream-dependent nodes. Downstream- 1166 dependent nodes that travel with a mobile provider EBR can continue 1167 to use addresses configured from PA prefixes; downstream-dependent 1168 nodes that move away from their provider EBR must perform address/ 1169 prefix renumbering when they assocate with a new provider. 1171 The EBGs of a multi-homed enterprise should participate in a private 1172 inner IP routing protocol instance between themselves (possibly over 1173 an alternate topology) to accommodate enterprise partitions/merges as 1174 well as intra-enterprise mobility events. These peer EBGs should 1175 accept packets from one another without respect to the destination 1176 (i.e., ingress filtering is based on the peering relationship rather 1177 than a prefix-specific ingress filter entry). 1179 5.11. Multicast 1181 In multicast-capable deployments, ERs provide an enterprise-wide 1182 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1183 [I-D.ietf-manet-smf], PIM routing, DVMRP routing, etc.) over their 1184 enterprise-interior interfaces such that outer IP multicast messages 1185 of site- or greater scope will be propagated across the enterprise. 1186 For such deployments, VET nodes can also provide an inner IP 1187 multicast/broadcast capability over their VET interfaces through 1188 mapping of the inner IP multicast address space to the outer IP 1189 multicast address space. In that case, operation of link- or greater 1190 scoped inner IP multicasting services (e.g., a link-scoped neighbor 1191 discovery protocol) over the VET interface is available, but link- 1192 scoped services should be used sparingly to minimize enterprise-wide 1193 flooding. 1195 VET nodes encapsulate inner IP multicast messages sent over the VET 1196 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1197 outer IP header with a site-scoped outer IP multicast address as the 1198 destination. For the case of IPv6 and IPv4 as the inner/outer 1199 protocols (respectively), [RFC2529] provides mappings from the IPv6 1200 multicast address space to a site-scoped IPv4 multicast address space 1201 (for other IP-in-IP encapsulations, mappings are established through 1202 administrative configuration or through an unspecified alternate 1203 static mapping). 1205 Multicast mapping for inner IP multicast groups over outer IP 1206 multicast groups can be accommodated, e.g. through VET interface 1207 snooping of inner multicast group membership and routing protocol 1208 control messages. To support inner-to-outer IP multicast mappinging, 1209 the VET interface acts as a virtual outer IP multicast host connected 1210 to its underlying enterprise-interior interfaces. When the VET 1211 interface detects inner IP multicast group joins or leaves, it 1212 forwards corresponding outer IP multicast group membership reports 1213 for each enterprise-interior interface over which the VET interface 1214 is configured. If the VET node is configured as an outer IP 1215 multicast router on the underlying enterprise-interior interfaces, 1216 the VET interface forwards locally looped-back group membership 1217 reports to the outer IP multicast routing process. If the VET node 1218 is configued as a simple outer IP multicast host, the VET interface 1219 instead fowards actual group membership reports (e.g., IGMP messages) 1220 directly over each of the underlying enterprise-interior interfaces. 1222 Since inner IP multicast groups are mapped to site-scoped outer IP 1223 multicast groups, the VET node must ensure that the site-scope outer 1224 IP multicast messages received on the enterprise-interior interfaces 1225 for one VET interface do not "leak out" to the enterprise-interior 1226 interfaces of another VET interface. This is accomodated through 1227 normal site-scoped outer IP multicast group filtering at enterprise- 1228 interior interface boundaries. 1230 5.12. Service Discovery 1232 VET nodes can peform enterprise-wide service discovery using a 1233 suitable name-to-address resolution service. Examples of flooding- 1234 based services include the use of LLMNR [RFC4759] over the VET 1235 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1236 underlying enterprise-interior interface. More scalable and 1237 efficient service discovery mechanisms are for further study. 1239 5.13. Enterprise Partitioning 1241 EBGs can physically partition an enterprise by configuring multiple 1242 VET interfaces over multiple distinct sets of underlying interfaces. 1243 In that case, each partition (i.e., each VET interface) must 1244 configure its own distinct 'PRLNAME' (e.g., 1245 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1247 EBGs can logically partition an enterprise using a single VET 1248 interface by sending RAs with PIOs containing different IPv6 PA 1249 prefixes to group nodes into different logical partitions. EBGs can 1250 identify partitions, e.g., by examining IPv4 RLOC prefixes, observing 1251 the interfaces over which RSs are received, etc. In that case, a 1252 single 'PRLNAME' can cover all partitions. 1254 5.14. EBG Prefix State Recovery 1256 EBGs must retain explicit state that tracks the inner IP prefixes 1257 owned by EBRs within the enterprise, e.g., so that packets are 1258 delivered to the correct EBRs and not incorrectly "leaked out" of the 1259 enterprise via a default route. For PA prefixes the state is 1260 maintained via an EBR's DHCP prefix delegation lease renewals, while 1261 for PI prefixes the state is maintained via an EBR's periodic prefix 1262 registration RAs. 1264 When an EBG loses some or all of its state (e.g., due to a power 1265 failure), it must recover the state before allowing packets to flow 1266 over incorrect routes. If the EBG aggregates PA prefixes from which 1267 the IP prefixes of all EBRs in the enterprise are sub-delegated, then 1268 the EBG can recover state through DHCP prefix delegation lease 1269 renewals, through bulk lease queries, or through on-demand name 1270 service lookups based due to IP packet forwarding. If the EBG serves 1271 as an anchor for PI prefixes, however, care must be taken to avoid 1272 looping while state is recovered through prefix registration RAs from 1273 EBRs. In that case, when the EBG that is recovering state forwards 1274 an IP packet for which it has no explicit route other than ::/0, it 1275 must first perform an on-demand name service lookup to refresh state. 1277 6. IANA Considerations 1279 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1280 DHCPv4 server discovery is requested. The allocation should be taken 1281 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1282 the IANA 'multicast-addresses' registry. 1284 7. Security Considerations 1286 Security considerations for MANETs are found in [RFC2501]. 1288 Security considerations with tunneling that apply also to VET are 1289 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1290 that the outer IP source address of a packet received on a VET 1291 interface is correct for the inner IP source address using the 1292 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1293 the ingress filtering mechanisms specified in this document. 1295 SEND [RFC3971], IPsec [RFC4301] and SEAL [I-D.templin-seal] provide 1296 additional securing mitigations to detect source address spoofing and 1297 bogus RA messages sent by rogue routers. 1299 Rogue routers can send bogus RA messages with spoofed RLOC source 1300 addresses that can consume network resources and cause EBGs to 1301 perform extra work. Nonetheless, EBGs should not "blacklist" such 1302 RLOCs, as that may result in a denial of service to the RLOCs' 1303 legitimate owners. 1305 8. Related Work 1307 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1308 automatic tunneling in [RFC2529]; this concept was later called: 1309 "Virtual Ethernet" and investigated by Quang Nguyen under the 1310 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1311 their colleagues have motivated a number of foundational concepts on 1312 which this work is based. 1314 Telcordia has proposed DHCP-related solutions for MANETs through the 1315 CECOM MOSAIC program. 1317 The Naval Research Lab (NRL) Information Technology Division uses 1318 DHCP in their MANET research testbeds. 1320 Security concerns pertaining to tunneling mechanisms are discussed in 1321 [I-D.ietf-v6ops-tunnel-security-concerns]. 1323 Default router and prefix information options for DHCPv6 are 1324 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1326 An automated IPv4 prefix delegation mechanism is proposed in 1327 [I-D.ietf-dhc-subnet-alloc]. 1329 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1330 [I-D.clausen-manet-autoconf-recommendations]. 1332 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1334 Various proposals within the IETF have suggested similar mechanisms. 1336 9. Acknowledgements 1338 The following individuals gave direct and/or indirect input that was 1339 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1340 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1341 Ralph Droms, Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, 1342 Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe 1343 Macker, David Meyer, Thomas Narten, Pekka Nikander, Dave Oran, 1344 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole 1345 Troan, Michaela Vanderveen, Lixia Zhang and others in the IETF 1346 AUTOCONF and MANET working groups. Many others have provided 1347 guidance over the course of many years. 1349 10. Contributors 1351 The following individuals have contributed to this document: 1353 Eric Fleischman (eric.fleischman@boeing.com) 1354 Thomas Henderson (thomas.r.henderson@boeing.com) 1355 Steven Russert (steven.w.russert@boeing.com) 1356 Seung Yi (seung.yi@boeing.com) 1358 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1359 of the document. 1361 Jim Bound's foundational work on enterprise networks provided 1362 significant guidance for this effort. We mourn his loss and honor 1363 his contributions. 1365 11. References 1367 11.1. Normative References 1369 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1370 September 1981. 1372 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1373 RFC 792, September 1981. 1375 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1376 converting network protocol addresses to 48.bit Ethernet 1377 address for transmission on Ethernet hardware", STD 37, 1378 RFC 826, November 1982. 1380 [RFC1035] Mockapetris, P., "Domain names - implementation and 1381 specification", STD 13, RFC 1035, November 1987. 1383 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1384 RFC 2131, March 1997. 1386 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1387 (IPv6) Specification", RFC 2460, December 1998. 1389 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1390 Update", RFC 3007, November 2000. 1392 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1393 and M. Carney, "Dynamic Host Configuration Protocol for 1394 IPv6 (DHCPv6)", RFC 3315, July 2003. 1396 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1397 "DNS Extensions to Support IP Version 6", RFC 3596, 1398 October 2003. 1400 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1401 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1402 December 2003. 1404 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1405 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1407 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1408 RFC 3972, March 2005. 1410 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1411 More-Specific Routes", RFC 4191, November 2005. 1413 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1414 Architecture", RFC 4291, February 2006. 1416 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1417 Message Protocol (ICMPv6) for the Internet Protocol 1418 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1420 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1421 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1422 September 2007. 1424 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1425 Address Autoconfiguration", RFC 4862, September 2007. 1427 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1428 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1429 March 2008. 1431 11.2. Informative References 1433 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1434 Switching Networks", May 1974. 1436 [I-D.cheshire-dnsext-multicastdns] 1437 Cheshire, S. and M. Krochmal, "Multicast DNS", 1438 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1439 September 2008. 1441 [I-D.clausen-manet-autoconf-recommendations] 1442 Clausen, T. and U. Herberg, "MANET Router Configuration 1443 Recommendations", 1444 draft-clausen-manet-autoconf-recommendations-00 (work in 1445 progress), February 2009. 1447 [I-D.clausen-manet-linktype] 1448 Clausen, T., "The MANET Link Type", 1449 draft-clausen-manet-linktype-00 (work in progress), 1450 October 2008. 1452 [I-D.droms-dhc-dhcpv6-default-router] 1453 Droms, R. and T. Narten, "Default Router and Prefix 1454 Advertisement Options for DHCPv6", 1455 draft-droms-dhc-dhcpv6-default-router-00 (work in 1456 progress), March 2009. 1458 [I-D.ietf-autoconf-manetarch] 1459 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1460 Network Architecture", draft-ietf-autoconf-manetarch-07 1461 (work in progress), November 2007. 1463 [I-D.ietf-csi-proxy-send] 1464 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1465 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1466 in progress), November 2008. 1468 [I-D.ietf-dhc-subnet-alloc] 1469 Johnson, R., "Subnet Allocation Option", 1470 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1471 July 2008. 1473 [I-D.ietf-ipv6-ula-central] 1474 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1475 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1476 progress), June 2007. 1478 [I-D.ietf-manet-smf] 1479 Macker, J. and S. Team, "Simplified Multicast Forwarding 1480 for MANET", draft-ietf-manet-smf-08 (work in progress), 1481 November 2008. 1483 [I-D.ietf-v6ops-tunnel-security-concerns] 1484 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1485 Concerns With IP Tunneling", 1486 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1487 progress), October 2008. 1489 [I-D.jen-apt] 1490 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1491 L. Zhang, "APT: A Practical Transit Mapping Service", 1492 draft-jen-apt-01 (work in progress), November 2007. 1494 [I-D.templin-seal] 1495 Templin, F., "The Subnetwork Encapsulation and Adaptation 1496 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1497 August 2008. 1499 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1500 July 1978. 1502 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1503 Protocol Specification", October 2008. 1505 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1506 Communication Layers", STD 3, RFC 1122, October 1989. 1508 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1509 September 1991. 1511 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1512 Routing and Addressing Architecture", RFC 1753, 1513 December 1994. 1515 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1516 E. Lear, "Address Allocation for Private Internets", 1517 BCP 5, RFC 1918, February 1996. 1519 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1520 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1522 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1523 (MANET): Routing Protocol Performance Issues and 1524 Evaluation Considerations", RFC 2501, January 1999. 1526 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1527 Domains without Explicit Tunnels", RFC 2529, March 1999. 1529 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1530 February 2000. 1532 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1533 via IPv4 Clouds", RFC 3056, February 2001. 1535 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1536 Networks", BCP 84, RFC 3704, March 2004. 1538 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1539 RFC 3753, June 2004. 1541 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1542 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1543 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1544 RFC 3819, July 2004. 1546 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1547 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1548 May 2005. 1550 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1551 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1552 September 2005. 1554 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1555 Addresses", RFC 4193, October 2005. 1557 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1558 Internet Protocol", RFC 4301, December 2005. 1560 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1561 Network Address Translations (NATs)", RFC 4380, 1562 February 2006. 1564 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1565 Proxies (ND Proxy)", RFC 4389, April 2006. 1567 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1568 Indicator Parameter for the "tel" URI", RFC 4759, 1569 December 2006. 1571 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1572 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1573 Focus", RFC 4852, April 2007. 1575 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1576 June 2007. 1578 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1579 Extensions for Stateless Address Autoconfiguration in 1580 IPv6", RFC 4941, September 2007. 1582 Appendix A. Duplicate Address Detection (DAD) Considerations 1584 A-priori uniqueness determination (also known as "pre-service DAD") 1585 for an RLOC assigned on an enterprise-interior interface would 1586 require either flooding the entire enterprise or somehow discovering 1587 a link in the enterprise on which a node that configures a duplicate 1588 address is attached and performing a localized DAD exchange on that 1589 link. But, the control message overhead for such an enterprise-wide 1590 DAD would be substantial and prone to false-negatives due to packet 1591 loss and intermittent connectivity. An alternative to pre-service 1592 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1593 interfaces and employ a passive in-service DAD (e.g., one that 1594 monitors routing protocol messages for duplicate assignments). 1596 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1597 CGAs, IPv6 privacy addresses, etc. with very small probability of 1598 collision. Pseudo-random IPv4 RLOCs can be generated through random 1599 assignment from a suitably large IPv4 prefix space. 1601 Consistent operational practices can assure uniqueness for EBG- 1602 aggregated addresses/prefixes, while statistical properties for 1603 pseudo-random address self-generation can assure uniqueness for the 1604 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1605 RLOC delegation authority should be used when available, while a 1606 passive in-service DAD mechanism should be used to detect RLOC 1607 duplications when there is no RLOC delegation authority. 1609 Appendix B. Change Log 1611 (Note to RFC editor - this section to be removed before publication 1612 as an RFC.) 1614 Changes from -35 to 36: 1616 o DHCP updates 1618 Changes from -34 to 35: 1620 o Introduced EID and RLOC terminology 1622 o RLOC-based prefix delegation 1624 Changes from -33 to 34: 1626 o Enterprise management models described 1628 o Enterprise security models described 1630 o Clarification of mechanisms based on enterprise management/ 1631 security models 1633 Changes from -32 to 33:: 1635 o Secure Neighbor Discovery Proxy 1637 Changes from -28 to 29: 1639 o Updates on processing/receiving errors. 1641 Changes from -27 to 28: 1643 o Introduced concept of a default mapper. 1645 Changes from -26 to 27: 1647 o Introduced new model for PI prefix management. 1649 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1650 "isado"?) 1652 Changes from -25 to 26: 1654 o Clarifications on Router Discovery and Ingress FIltering. 1656 o Mechanisms for detecting locator liveness 1658 o Mechanisms for avoiding state synchonization requirements. 1660 Changes from -23 to 24: 1662 o Clarifications on router discovery. 1664 Changes from -22 to 23: 1666 o Clarifications on prefix mapping. 1668 Changes from -21 to 22: 1670 o Using SEAL to secure VET 1672 Changes from -20 to 21: 1674 o Enterprise partitioning. 1676 o Mapping and name service management. 1678 Changes from -18 to 20: 1680 o Added support for simple hosts. 1682 o Added EBG name service maintenace procedures 1684 o Added router and prefix maintenace procedures 1686 Changes from -17 to 18: 1688 o adjusted section headings to group autoconf operations under EIR/ 1689 EBR/EBG. 1691 o clarified M/O bits 1693 o clarified EBG roles 1694 Changes from -15 to 17: 1696 o title change to "Virtual Enterprise Traversal (VET)". 1698 o changed document focus from MANET-centric to the much-broader 1699 Enterprise-centric, where "Enterprise" is understood to also cover 1700 a wide range of MANET types. 1702 Changes from -14 to 15: 1704 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1706 o Address review comments 1708 Changes from -12 to 14: 1710 o title change to "The MANET Virtual Ethernet Abstraction". 1712 o Minor section rearrangement. 1714 o Clartifications on portable and self-configured prefixes. 1716 o Clarifications on DHCPv6 prefix delegation procedures. 1718 Changes from -11 to 12: 1720 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1722 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1723 delegation mechanism. 1725 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1727 o fixed editorials based on comments received. 1729 Changes from -10 to 11: 1731 o removed the transparent/opaque VET portal abstractions. 1733 o removed routing header as an option for MANET exit router 1734 selection. 1736 o included IPv6 SLAAC as an endorsed address configuration mechanism 1737 for the VET interface. 1739 Changes from -08 to -09: 1741 o Introduced the term "VET". 1743 o Changed address delegation language to speak of "MNBR-aggregated" 1744 instead of global/local. 1746 o Updated figures 1-3. 1748 o Explained why a MANET interface is "neutral". 1750 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1751 DHCPv4 servers; not relays. 1753 Changes from -07 to -08: 1755 o changed terms "unenhanced" and "enhanced" to "transparent" and 1756 "opaque". 1758 o revised MANET Router diagram. 1760 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1761 interface. 1763 o changed abbreviations to "MNR" and "MNBR". 1765 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1767 o rearranged Section 3.1. 1769 o various minor text cleanups 1771 Changes from -06 to -07: 1773 o added MANET Router diagram. 1775 o added new references 1777 o various minor text cleanups 1779 Changed from -05 to -06: 1781 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1783 o minor changes to preserve generality 1785 Changed from -04 to -05: 1787 o introduced conceptual "virtual ethernet" model. 1789 o support "raw" and "cooked" modes as equivalent access methods on 1790 the virutal ethernet. 1792 Changed from -03 to -04: 1794 o introduced conceptual "imaginary shared link" as a representation 1795 for a MANET. 1797 o discussion of autonomous system and site abstractions for MANETs 1799 o discussion of autoconfiguration of CGAs 1801 o new appendix on IPv6 StateLess Address AutoConfiguration 1803 Changes from -02 to -03: 1805 o updated terminology based on RFC2461 "asymmetric reachability" 1806 link type; IETF67 MANET Autoconf wg discussions. 1808 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1809 Address Detection 1811 o relaxed DHCP server deployment considerations allow DHCP servers 1812 within the MANET itself 1814 Changes from -01 to -02: 1816 o minor updates for consistency with recent developments 1818 Changes from -00 to -01: 1820 o new text on DHCPv6 prefix delegation and multilink subnet 1821 considerations. 1823 o various editorial changes 1825 Author's Address 1827 Fred L. Templin (editor) 1828 Boeing Research and Technology 1829 P.O. Box 3707 MC 7L-49 1830 Seattle, WA 98124 1831 USA 1833 Email: fltemplin@acm.org