idnits 2.17.1 draft-templin-autoconf-dhcp-35.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 699: '...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 2, 2009) is 5527 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 1397, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1516, 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 2, 2009 5 Expires: September 3, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-35.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 3, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 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 . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . 18 78 5.4.3. IPv6 PI Prefix Registration . . . . . . . . . . . . . 19 79 5.4.4. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . 20 80 5.5. IPv4 Router Discovery and Prefix Registration . . . . . . 22 81 5.6. VET Encapsulation . . . . . . . . . . . . . . . . . . . . 23 82 5.7. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 23 83 5.8. Generating Errors . . . . . . . . . . . . . . . . . . . . 24 84 5.9. Processing Errors . . . . . . . . . . . . . . . . . . . . 24 85 5.10. Mobility and Multihoming Considerations . . . . . . . . . 25 86 5.11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 26 87 5.12. Service Discovery . . . . . . . . . . . . . . . . . . . . 27 88 5.13. Enterprise Partitioning . . . . . . . . . . . . . . . . . 28 89 5.14. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 28 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 94 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 98 Appendix A. Duplicate Address Detection (DAD) Considerations . . 35 99 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 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 and/or through the Potential Router List (PRL) 575 discovery mechanisms outlined in ([RFC5214], Section 8.3.2). In 576 multicast-capable enterprises, EBRs can also listen for 577 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 a provider network 681 via ordinay provider-edge interfaces and/or VET interfaces configured 682 over parent enterprises. EBGs perform the EBR autoconfiguration 683 procedures specified in Section 4.2. EBGs that support PA prefix 684 delegation also configure a DHCP relay/server. 686 EBGs autoconfigure provider-edge interfaces in a manner that is 687 specific to their provider connections, and autoconfigure VET 688 interfaces as specified in Section 4.2.1. For each VET interface on 689 which it is configured as an EBG, the EBG must arrange to add one or 690 more of its RLOCs associated with the enterprise to the PRL (see: 691 Section 4.2.1.2), and must maintain these resource records in 692 accordance with ([RFC5214], Section 9). In particular, for each such 693 VET interface the EBG adds the RLOCs to name service resource records 694 for 'PRLNAME'. 696 For enterprises with a distributed management structure, EBGs respond 697 to LLMNR queries for 'PRLNAME'. 699 To avoid looping, EBGs MUST NOT configure a default route over a VET 700 interface on which it is configured as an EBG. 702 4.4. VET Host Autoconfiguration 704 Nodes that cannot be attached via an EBR's enterprise-edge interface 705 (e.g., nomadic laptops that connect to a home office via a Virtual 706 Private Network (VPN)) can instead be configured for operation as a 707 simple host connected to the VET interface. Such VET hosts perform 708 the same VET interface autoconfiguration procedures as specified for 709 EBRs in Section 4.2.1, but they configure their VET interfaces as 710 host interfaces (and not router interfaces). VET hosts can then send 711 packets to the EID addresses of other hosts on the VET interface, or 712 to off-enterprise EID destinations via a next-hop EBR. 714 Note that a node may be configured as a host on some VET interfaces 715 and as an EBR/EBG on other VET interfaces. 717 5. Internetworking Operation 719 Following the autoconfiguration procedures specified in Section 4, 720 ERs, EBRs, EBGs and VET hosts engage in normal internetworking 721 operations as discussed in the following sections: 723 5.1. Routing Protocol Participation 725 Following autoconfiguration, ERs engage in any RLOC-based IP routing 726 protocols and forward IP packets with RLOC addresses. EBRs can 727 additionally engage in any EID-based IP routing protocols and forward 728 IP packets with EID addresses. Note that the EID-based IP routing 729 domains are separate and distinct from any RLOC-based IP routing 730 domains. 732 5.2. RLOC-based Communications 734 When permitted by policy and supported by routing, end systems can 735 avoid VET interface encapsulation through communications that 736 directly invoke the outer IP protocol using RLOC addresses instead of 737 EID addresses. End systems can use source address selection rules to 738 determine whether to use EID or RLOC addresses based on, e.g., name 739 service records. 741 5.3. EID-based Communications 743 In many enterprise scenarios, the use of EID-based communications 744 (i.e., instead of RLOC-based communications) may be necessary and/or 745 beneficial to support address scaling, NAT avoidance, security domain 746 separation, site multi-homing, traffic engineering, etc. 748 The remainder of this section discusses internetworking operation for 749 EID-based communications using the VET interface abstraction. 751 5.4. IPv6 Router Discovery and Prefix Registration 753 The following sections discuss router and prefix discovery 754 considerations for the case of IPv6 as the inner IP protocol: 756 5.4.1. IPv6 Router and Prefix Discovery 758 EBGs follow the router and prefix discovery procedures specified in 759 ([RFC5214], Section 8.2). They send solicited RAs over VET 760 interfaces for which they are configured as gateways with default 761 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 762 with any other required options/parameters. EBGs must set the 'M' 763 flag in RAs to 0, since the use of DHCPv6 for address configuration 764 on VET interfaces is undefined. EBGs can also include PIOs with the 765 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 766 of an aggregated prefix from which it is willing to delegate longer 767 PA prefixes. 769 VET nodes follow the router and prefix discovery procedures specified 770 in ([RFC5214], Section 8.3). They discover EBGs within the 771 enterprise as specified in Section 4.2.1.2, then perform RS/RA 772 exchanges with the EBGs to establish and maintain default routes. In 773 particular the VET node sends unicast RS messages to EBGs over its 774 VET interface(s) to receive RAs. Depending on the enterprise network 775 trust basis, VET nodes may be required to use SEND to secure the 776 RS/RA exchanges. 778 When the VET node receives an RA, it authenticates the message then 779 configures a default route based on the Router Lifetime. If the RA 780 contains Prefix Information Options (PIOs) with the 'A' and 'L' bits 781 set to 1, the VET node also autoconfigures IPv6 addresses from the 782 advertised prefixes using SLAAC and assigns them to the VET 783 interface. Thereafter, the VET node accepts packets that are 784 fowarded by EBGs for which it has current default routing information 785 (i.e., ingress filtering is based on the default router trust 786 relationship rather than a prefix-specific ingress filter entry). 788 5.4.2. IPv6 PA Prefix Registration 790 After an EBR discovers default routes, it can use DHCP prefix 791 delegation to obtain PA prefixes via an EBG as specified in 792 Section 4.2.2. The DHCP server ensures that the delegations are 793 unique and that the EBG's router function will forward IP packets 794 over the VET interface to the correct EBR. In particular, the EBG 795 must register and track the PA prefixes that are delegated to each 796 EBR. 798 The PA prefix registrations remain active in the EBGs as long as the 799 EBR continues to issue DHCP renewals over the VET interface before 800 lease lifetimes expire. The lease lifetime also keeps the delegation 801 state active even if communications between the EBR and DHCP server 802 are disrupted for a period of time (e.g., due to an enterprise 803 network partition) before being reestablished (e.g., due to an 804 enterprise network merge). 806 5.4.3. IPv6 PI Prefix Registration 808 After an EBR discovers default routes, it must register its PI 809 prefixes by sending RAs to a set of one or more EBGs with Route 810 information Options (RIOs) [RFC4191] that contain the EBR's PI 811 prefixes. Each RA must include the RLOC of an EBG as the outer IP 812 destination address and a link-local address assigned to the VET 813 interface as the inner IP destination address. For enterprises that 814 use SEND, the RAs also include a CGA link-local inner source address 815 along with SEND credentials plus any certificates needed to prove 816 ownership of the PI prefixes. The EBR additionally tracks the set of 817 EBGs that it sends RAs to so that it can send subsequent RAs to the 818 same set. 820 When the EBG receives the RA, it first authenticates the message; if 821 the authentication fails, the EBG discards the RA. Otherwise, the 822 EBG installs the PI prefixes with their respective lifetimes in its 823 Forwarding Information Base (FIB) and configures them for both 824 ingress filtering [RFC3704] and forwarding purposes. In particular, 825 the EBG configures the FIB entries as ingress filter rules to accept 826 packets received on the VET interface that have a source address 827 taken from the PI prefixes. It also configures the FIB entries to 828 forward packets received on other interfaces with a destination 829 address taken from the PI prefixes to the EBR that registered the 830 prefixes on the VET interface. 832 The EBG then publishes the PI prefixes in a distributed database 833 (e.g., in a private instance of a routing protocol in which only EBGs 834 participate, via an automated name service update mechanism 835 [RFC3007], etc.). For enterprises that are managed under a 836 centralized administrative authority, the EBG also publishes the PI 837 prefixes in the enterprise-local name service (e.g., the enterprise- 838 local DNS [RFC1035]). 840 In particular, the EBG publishes each /56 prefix taken from the PI 841 prefixes as a seperate FQDN that consists of a sequence of 14 nibbles 842 in reverse order (i.e., the same as in [RFC3596], Section 2.5) 843 followed by the string 'ip6' followed by the string 'PRLNAME'. For 844 example, when 'PRLNAME' is "isatap.example.com", the EBG publishes 845 the prefix '2001:DB8::/56' as: 846 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. The EBG 847 includes the outer RLOC source address of the RA (e.g., in a DNS A 848 resource record) in each prefix publication. For enterprises that 849 use SEND, the EBG also includes the inner IPv6 CGA source address 850 (e.g., in a DNS AAAA record) in each prefix publication. If the 851 prefix was already installed in the distributed database, the EBG 852 instead adds the outer RLOC source address (e.g., in an additional 853 DNS A records) to the pre-existing publication to support PI prefixes 854 that are multihomed. For enterprises that use SEND, this latter 855 provision requires all EBRs of a multihomed site that advertise the 856 same PI prefixes in RAs to use the same CGA and the same SEND 857 credentials. 859 After the EBG authenticates the RA and publishes the PI prefixes, it 860 next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the 861 VET interfaces configured over any of its parent enterprises and 862 relays a proxied RA to the EBGs on those interfaces. (For 863 enterprises that use SEND, the EBG additionally acts as a SEcure 864 Neighbor Discovery Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) 865 EBGs in parent enterprises that receive the proxied RAs in turn act 866 as NDProxys/SENDProxys to relay the RAs to EBGs on their parent 867 enterprises, etc. The RA proxying and PI prefix publication recurses 868 in this fashion and ends when an EBR attached to an interdomain 869 routing core is reached. 871 After the initial PI prefix registration, the EBR that owns the 872 prefix(es) must periodically send additional RAs to its set of EBGs 873 to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in 874 parent enterprises that it relays the proxied RAs to, and should 875 relay subsequent RAs to the same set. 877 This procedure has a direct analogy in the Teredo method of 878 maintaining state in network middleboxes through the periodic 879 transmission of "bubbles" [RFC4380]. 881 5.4.4. IPv6 Next-Hop EBR Discovery 883 VET nodes discover destination-specific next-hop EBRs within the 884 enterprise by querying the name service for the /56 IPv6 PI prefix 885 taken from a packet's destination address, by forwarding packets via 886 a default route to an EBG, or by some other inner IP to outer IP 887 address mapping mechansim. For example, for the IPv6 destination 888 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 889 node can lookup the domain name: 890 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. If the name 891 service lookup succeeds, it will return RLOC addresses (e.g., in DNS 892 A records) that correspond to the RLOCs assigned to enterprise 893 interior interfaces of next-hop EBRs to which the VET node can 894 forward packets. (In enterprises that use SEND, it will also return 895 an IPv6 CGA address, e.g., in a DNS AAAA record.) 897 Name service lookups in enterprises with a centralized management 898 structure use an infrastructure-based service, e.g., an enterprise- 899 local DNS. Name service lookups in enterprises with a distributed 900 management structure and/or that lack an infrastructure-based name 901 service instead use LLMNR over the VET interface. When LLMNR is 902 used, the EBR that performs the lookup sends an LLMNR query (with the 903 /56 prefix taken from the IP destination address encoded in dotted- 904 nibble format as shown above) and accepts the union of all replies it 905 receives from other EBRs on the VET interface. When an EBR receives 906 an LLMNR query, it responds to the query IFF it aggregates an IP 907 prefix that covers the prefix in the query. 909 Alternatively, in enterprises with a stable and highly-available set 910 of EBGs, the VET node can simply forward an initial packet via a 911 default route to an EBG. The EBG will forward the packet to a next- 912 hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] 913 (using SEND, if necessary). If the packet's source address is on- 914 link on the VET interface, the EBG returns an ordinary "router-to- 915 host" redirects with the source address of the packet as its 916 destination. If the packet's source address is not on-link, the EBG 917 instead returns a "router-to-router" redirect with the link-local 918 ISATAP address of the previous-hop EBR as its destination. When IPv4 919 is used as the outer IP protocol, the EBG also includes in the 920 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 921 contain the IPv4 RLOCs of potential next-hop EBRs arranged in order 922 from highest to lowest priority (i.e., the first LLAO contains the 923 highest priority RLOC and the final LLAO option contains the lowest 924 priority). These LLAOs are formatted using a modified version of the 925 form specified in ( [RFC2529], Section 5) as shown in Figure 2 (the 926 LLAO format for IPv6 as the outer IP protocol is out of scope): 928 +-------+-------+-------+-------+-------+-------+-------+-------+ 929 | Type |Length | TTL | IPv4 Address | 930 +-------+-------+-------+-------+-------+-------+-------+-------+ 932 Figure 2: VET Link-Layer Address Option Format 934 For each such IPv6/IPv4 LLAO, the Type is set to 2 (for Target Link- 935 Layer Address Option), Length is set to 1, and IPv4 Address is set to 936 the IPv4 RLOC of the next-hop EBR. TTL is set to the time in seconds 937 that the recipient may cache the RLOC, where the value 65535 938 represents infinity and the value 0 suspends forwarding through this 939 RLOC. 941 When a VET host receives an ordinay "router-to-host" redirect, it 942 processes the redirect exacly as specified in [RFC4861], Section 8. 943 When an EBR receives a "router-to-router" redirect, it discovers the 944 RLOC addresses of potential next-hop EBRs by examining the LLAOs 945 included in the redirect. The EBR then installs a FIB entry that 946 contains the /56 prefix of the destination address encoded in the 947 redirect and the list of RLOCs of potential next-hop EBRs. The EBR 948 then enables the FIB entry for forwarding to next-hop EBRs but DOES 949 NOT enable it for ingress filtering acceptance of packets from next- 950 hop EBRs (i.e., the forwarding determination is unidirectional). 952 In enterprises in which spoofing is possible, after discovering 953 potential next-hop EBRs (either through name service lookup or ICMP 954 redirect) the EBR must send authenticating credentials before 955 forwarding packets via the next-hops. To do so, the EBR must send 956 RAs over the VET interface (using SEND, if necessary) to one or more 957 of the potential next-hop EBRs with an RLOC as the outer IP 958 destination address. The RAs must include a Route Information Option 959 (RIO) [RFC4191] that contains the /56 PI prefix of the original 960 packet's source address. After sending the RAs, the EBR can either 961 enable the new FIB entry for forwarding immediately or delay until it 962 receives an explicit acknowledgement that a next-hop EBR received the 963 RA (e.g., using the SEAL explicit acknowledgement mechanism - see: 964 Section 5.7). 966 When a next-hop EBR receives the RA, it authenticates the message 967 then performs a name service lookup on the prefix in the RIO if 968 further authenticating evidence is required. If the name service 969 returns resource records that are consistent with the inner and outer 970 IP addresses of the RA, the next-hop EBR then installs the prefix in 971 the RIO in its FIB and enables the FIB entry for ingress filtering 972 but DOES NOT enable it for forwarding purposes. After an EBR sends 973 initial RAs following a redirect, it should send periodic RAs to 974 refresh the next-hop EBR's ingress filter prefix lifetimes as long as 975 traffic is flowing. 977 EBRs retain the FIB entrys created as result of an ICMP redirect 978 until all RLOC TTLs expire, or until no hints of forward progress 979 through any of the associated RLOCs are received. In this way, RLOC 980 liveness detection exactly parallels IPv6 Neighbor Unreachability 981 Detection ([RFC4861], Section 3). 983 5.5. IPv4 Router Discovery and Prefix Registration 985 When IPv4 is used as the inner IP protocol, router discovery and 986 prefix registration exactly parallels the mechanisms specified for 987 IPv6 in Section 5.4. To support this, modifications to the ICMPv4 988 Router Advertisement [RFC1256] function to include SEND constructs, 989 and modifications to the ICMPv4 Redirect [RFC0792] function to 990 support router-to-router redirects will be specified in a future 991 document. Additionally, publications for IPv4 prefixes will be in 992 dotted-nibble format in the 'ip4.isatap.example.com' domain. For 993 example, the IPv4 prefix 192.0.2/24 would be represented as: 994 '2.0.0.0.0.c.ip4.isatap.example.com'. 996 5.6. VET Encapsulation 998 VET nodes forward packets by consulting the FIB to determine a 999 specific EBR/EBG as the next-hop router on a VET interface. When 1000 multiple next-hop routers are available, VET nodes can use default 1001 router preferences, routing protocol information, traffic engineering 1002 configurations, etc. to select the best exit router. When there is 1003 no FIB information other than "default" available, VET nodes can 1004 discover the next-hop EBR/EBG through the mechanisms specified in 1005 Section 5.4 and Section 5.5. 1007 VET interfaces encapsulate inner IP packets in any mid-layer headers 1008 followed by an outer IP header according to the specific 1009 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal], 1010 etc.); they next submit the encapsulated packet to the outer IP 1011 forwarding engine for transmission on an underlying enterprise- 1012 interior interface. 1014 For forwarding to next-hop addresses over VET interfaces that use 1015 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 1016 address (i.e., the IPv4 RLOC of the next-hop EBR) through static 1017 extraction of the IPv4 address embedded in the next-hop ISATAP 1018 address. For other IP-in-IP encapsulations, determination of the 1019 outer destination address is through administrative configuration or 1020 through an unspecified alternate method. When there are multiple 1021 candidate destination RLOCs available, the VET node should only 1022 select an RLOC for which there is current forwarding information in 1023 the outer IP protocol FIB. 1025 5.7. SEAL Encapsulation 1027 VET nodes should use SEAL encapsulation [I-D.templin-seal] over VET 1028 interfaces to accommdate path MTU diversity, to defeat source address 1029 spoofing, and to monitor next-hop EBR reachability. SEAL 1030 encapsulation maintains a unidirectional and monotonically- 1031 incrementing per-packet identification value known as the 'SEAL_ID'. 1032 When a VET node that uses SEAL encapsulation sends a SEND-protected 1033 Router Advertisement (RA) or Router Solicitation (RS) message to 1034 another VET node, both nodes cache the new SEAL_ID as per-tunnel 1035 state used for maintaining a window of unacknowledged SEAL_IDs. 1037 In terms of security, when a VET node receives an ICMP message, it 1038 can confirm that the packet-in-error within the ICMP message 1039 corresponds to one of its recently-sent packets by examining the 1040 SEAL_ID along with source and destination addresses, etc. 1041 Additionally, a next-hop EBR can track the SEAL_ID in packets 1042 received from EBRs for which there is an ingress filter entry and 1043 discard packets that have SEAL_ID values outside of the current 1044 window. 1046 In terms of next-hop reachability, an EBR can set the SEAL 1047 "Acknowledgement Requested" bit in messages to receive confirmation 1048 that a next-hop EBR is reachable. Setting the "Acknowledgement 1049 Requested" bit is also used as the method for maintaining the window 1050 of outstanding SEAL_ID's. 1052 5.8. Generating Errors 1054 When an EBR receives a packet over a VET interface and there is no 1055 matching ingress filter entry, it drops the packet and returns an 1056 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 1057 ingress/egress policy" message to the previous hop EBR subject to 1058 rate limiting. 1060 When an EBR receives a packet over a VET interface, and there is no 1061 longest-prefix-match FIB entry for the destination, it returns an 1062 ICMPv6 "Destination Unreachable; No route to destination" message to 1063 the previous hop EBR subject to rate limiting. 1065 When an EBR receives a packet over a VET interface and the longest- 1066 prefix-match FIB entry for the destination is via a next-hop 1067 configured over the same VET interface the packet arrived on, the EBR 1068 forwards the packet then (if the FIB prefix is longer than ::/0) 1069 sends a router-to-router ICMPv6 Redirect message (using SEND, if 1070 necessary) to the previous hop EBR as specified in Section 5.4.4. 1072 Generation of other ICMPv6 messages (e.g., ICMPv6 "Packet Too Big") 1073 is the same as for any IPv6 interface. 1075 5.9. Processing Errors 1077 When an EBR receives an ICMPv6 "Destination Unreachable; Source 1078 address failed ingress/egress policy" message from a next-hop EBR, 1079 and there is a longest-prefix-match FIB entry for the original 1080 packet's destination that is more-specific than ::/0, the EBR 1081 discards the message and marks the FIB entry for the destination as 1082 "forwarding suspended" for the RLOC taken from the source address of 1083 the ICMPv6 message. The EBR should then allow subsequent packets to 1084 flow through different RLOCs associated with the FIB entry until it 1085 forwards a new RA to the suspended RLOC. If the EBR receives 1086 excessive ICMPv6 ingress policy errors through multiple RLOCs 1087 associated with the same FIB entry, it should delete the FIB entry 1088 and allow subsequent packets to flow through an EBG if supported in 1089 the specific enterprise scenario. 1091 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1092 to destination" message from a next-hop EBR, it forwards the ICMPv6 1093 message to the source of the original packet as normal. If the EBR 1094 has longest-prefix-match FIB entry for the original packet's 1095 destination that is more-specific than ::/0, the EBR also deletes the 1096 FIB entry. 1098 When an EBR receives an authentic ICMPv6 Redirect, it processes the 1099 packet as specified in Section 5.4.4. 1101 When an EBG receives new mapping information for a specific 1102 destination prefix, it can propagate the update to other EBRs/EBGs by 1103 sending an ICMPv6 redirect message to the 'All Routers' link-local 1104 multicast address with a LLAO with the TTL for the unreachable LLAO 1105 set to zero, and with a NULL packet in error. 1107 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 1108 Unreachable; net / host unreachable" messages from an ER indicating 1109 that the path to a VET neighbor may be failing. The EBR should first 1110 check, e.g., the SEAL_ID, IPsec sequence number, source address of 1111 the original packet if available, etc. to obtain reasonable assurance 1112 that the ICMP message is authentic, then should mark the longest- 1113 prefix-match FIB entry for the destination as "forwarding suspended" 1114 for the RLOC destination address of the ICMPv4 packet-in-error. If 1115 the EBR receives excessive ICMPv4 unreachable errors through multiple 1116 RLOCs associated with the same FIB entry, it should delete the FIB 1117 entry and allow subsequent packets to flow through a different route. 1119 5.10. Mobility and Multihoming Considerations 1121 EBRs that travel between distinct enterprise networks must either 1122 abandon their PA prefixes that are relative to the "old" enterprise 1123 and obtain new ones relative to the "new" enterprise, or somehow 1124 coordinate with a "home" enterprise to retain ownership of the 1125 prefixes. In the first instance, the EBR would be required to 1126 coordinate a network renumbering event using the new PA prefixes 1127 [RFC4192]. In the second instance, an ancillary mobilitiy management 1128 mechanism must be used. 1130 EBRs can retain their PI prefixes as they travel between distinct 1131 enterprise networks as long as they register the prefixes with new 1132 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 1133 departure. Prefix registration with new EBGs is coordinated exactly 1134 as specified in Section 5.4.3; prefix withdrawl from old EBGs is 1135 simply through re-announcing the PI prefixes with zero lifetimes. 1137 Since EBRs can move about independently of one another, stale FIB 1138 entry state may be left in VET nodes when a neighboring EBR departs. 1139 Additionally, EBRs can lose state for various reasons, e.g., power 1140 failure, machine reboot, etc. For this reason, EBRs are advised to 1141 set relatively short PI prefix lifetimes in RIO options, and to send 1142 additional RAs to refresh lifetimes before they expire. (EBRs should 1143 place conservative limits on the RAs they send to reduce congestion, 1144 however.) 1146 EBRs may register their PI prefixes with multiple EBGs for 1147 multihoming purposes. EBRs should only forward packets via EBGs with 1148 which it has registered its PI prefixes, since other EBGs may drop 1149 the packets and return ICMPv6 "Destination Unreachable; Source 1150 address failed ingress/egress policy" messages. 1152 EBRs can also act as delegating routers to sub-delegate portions of 1153 their PI prefixes to requesting routers on their enterprise edge 1154 interfaces and on VET interfaces for which they are configured as 1155 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1156 become the PA prefixes for downstream-dependent nodes. Downstream- 1157 dependent nodes that travel with a mobile provider EBR can continue 1158 to use addresses configured from PA prefixes; downstream-dependent 1159 nodes that move away from their provider EBR must perform address/ 1160 prefix renumbering when they assocate with a new provider. 1162 The EBGs of a multi-homed enterprise should participate in a private 1163 inner IP routing protocol instance between themselves (possibly over 1164 an alternate topology) to accommodate enterprise partitions/merges as 1165 well as intra-enterprise mobility events. These peer EBGs should 1166 accept packets from one another without respect to the destination 1167 (i.e., ingress filtering is based on the peering relationship rather 1168 than a prefix-specific ingress filter entry). 1170 5.11. Multicast 1172 In multicast-capable deployments, ERs provide an enterprise-wide 1173 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1174 [I-D.ietf-manet-smf], PIM routing, DVMRP routing, etc.) over their 1175 enterprise-interior interfaces such that outer IP multicast messages 1176 of site- or greater scope will be propagated across the enterprise. 1177 For such deployments, VET nodes can also provide an inner IP 1178 multicast/broadcast capability over their VET interfaces through 1179 mapping of the inner IP multicast address space to the outer IP 1180 multicast address space. In that case, operation of link- or greater 1181 scoped inner IP multicasting services (e.g., a link-scoped neighbor 1182 discovery protocol) over the VET interface is available, but link- 1183 scoped services should be used sparingly to minimize enterprise-wide 1184 flooding. 1186 VET nodes encapsulate inner IP multicast messages sent over the VET 1187 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1188 outer IP header with a site-scoped outer IP multicast address as the 1189 destination. For the case of IPv6 and IPv4 as the inner/outer 1190 protocols (respectively), [RFC2529] provides mappings from the IPv6 1191 multicast address space to a site-scoped IPv4 multicast address space 1192 (for other IP-in-IP encapsulations, mappings are established through 1193 administrative configuration or through an unspecified alternate 1194 static mapping). 1196 Multicast mapping for inner IP multicast groups over outer IP 1197 multicast groups can be accommodated, e.g. through VET interface 1198 snooping of inner multicast group membership and routing protocol 1199 control messages. To support inner-to-outer IP multicast mappinging, 1200 the VET interface acts as a virtual outer IP multicast host connected 1201 to its underlying enterprise-interior interfaces. When the VET 1202 interface detects inner IP multicast group joins or leaves, it 1203 forwards corresponding outer IP multicast group membership reports 1204 for each enterprise-interior interface over which the VET interface 1205 is configured. If the VET node is configured as an outer IP 1206 multicast router on the underlying enterprise-interior interfaces, 1207 the VET interface forwards locally looped-back group membership 1208 reports to the outer IP multicast routing process. If the VET node 1209 is configued as a simple outer IP multicast host, the VET interface 1210 instead fowards actual group membership reports (e.g., IGMP messages) 1211 directly over each of the underlying enterprise-interior interfaces. 1213 Since inner IP multicast groups are mapped to site-scoped outer IP 1214 multicast groups, the VET node must ensure that the site-scope outer 1215 IP multicast messages received on the enterprise-interior interfaces 1216 for one VET interface do not "leak out" to the enterprise-interior 1217 interfaces of another VET interface. This is accomodated through 1218 normal site-scoped outer IP multicast group filtering at enterprise- 1219 interior interface boundaries. 1221 5.12. Service Discovery 1223 VET nodes can peform enterprise-wide service discovery using a 1224 suitable name-to-address resolution service. Examples of flooding- 1225 based services include the use of LLMNR [RFC4759] over the VET 1226 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1227 underlying enterprise-interior interface. More scalable and 1228 efficient service discovery mechanisms are for further study. 1230 5.13. Enterprise Partitioning 1232 EBGs can physically partition an enterprise by configuring multiple 1233 VET interfaces over multiple distinct sets of underlying interfaces. 1234 In that case, each partition (i.e., each VET interface) must 1235 configure its own distinct 'PRLNAME' (e.g., 1236 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1238 EBGs can logically partition an enterprise using a single VET 1239 interface by sending RAs with PIOs containing different IPv6 PA 1240 prefixes to group nodes into different logical partitions. EBGs can 1241 identify partitions, e.g., by examining IPv4 RLOC prefixes, observing 1242 the interfaces over which RSs are received, etc. In that case, a 1243 single 'PRLNAME' can cover all partitions. 1245 5.14. EBG Prefix State Recovery 1247 EBGs must retain explicit state that tracks the inner IP prefixes 1248 owned by EBRs within the enterprise, e.g., so that packets are 1249 delivered to the correct EBRs and not incorrectly "leaked out" of the 1250 enterprise via a default route. For PA prefixes the state is 1251 maintained via an EBR's DHCP prefix delegation lease renewals, while 1252 for PI prefixes the state is maintained via an EBR's periodic prefix 1253 registration RAs. 1255 When an EBG loses some or all of its state (e.g., due to a power 1256 failure), it must recover the state before allowing packets to flow 1257 over incorrect routes. If the EBG aggregates PA prefixes from which 1258 the IP prefixes of all EBRs in the enterprise are sub-delegated, then 1259 the EBG can recover state through DHCP prefix delegation lease 1260 renewals, through bulk lease queries, or through on-demand name 1261 service lookups based due to IP packet forwarding. If the EBG serves 1262 as an anchor for PI prefixes, however, care must be taken to avoid 1263 looping while state is recovered through prefix registration RAs from 1264 EBRs. In that case, when the EBG that is recovering state forwards 1265 an IP packet for which it has no explicit route other than ::/0, it 1266 must first perform an on-demand name service lookup to refresh state. 1268 6. IANA Considerations 1270 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1271 DHCPv4 server discovery is requested. The allocation should be taken 1272 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1273 the IANA 'multicast-addresses' registry. 1275 7. Security Considerations 1277 Security considerations for MANETs are found in [RFC2501]. 1279 Security considerations with tunneling that apply also to VET are 1280 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1281 that the outer IP source address of a packet received on a VET 1282 interface is correct for the inner IP source address using the 1283 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1284 the ingress filtering mechanisms specified in this document. 1286 SEND [RFC3971], IPsec [RFC4301] and SEAL [I-D.templin-seal] provide 1287 additional securing mitigations to detect source address spoofing and 1288 bogus RA messages sent by rogue routers. 1290 Rogue routers can send bogus RA messages with spoofed RLOC source 1291 addresses that can consume network resources and cause EBGs to 1292 perform extra work. Nonetheless, EBGs should not "blacklist" such 1293 RLOCs, as that may result in a denial of service to the RLOCs' 1294 legitimate owners. 1296 8. Related Work 1298 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1299 automatic tunneling in [RFC2529]; this concept was later called: 1300 "Virtual Ethernet" and investigated by Quang Nguyen under the 1301 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1302 their colleagues have motivated a number of foundational concepts on 1303 which this work is based. 1305 Telcordia has proposed DHCP-related solutions for MANETs through the 1306 CECOM MOSAIC program. 1308 The Naval Research Lab (NRL) Information Technology Division uses 1309 DHCP in their MANET research testbeds. 1311 Security concerns pertaining to tunneling mechanisms are discussed in 1312 [I-D.ietf-v6ops-tunnel-security-concerns]. 1314 An automated IPv4 prefix delegation mechanism is proposed in 1315 [I-D.ietf-dhc-subnet-alloc]. 1317 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1318 [I-D.clausen-manet-autoconf-recommendations]. 1320 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1322 Various proposals within the IETF have suggested similar mechanisms. 1324 9. Acknowledgements 1326 The following individuals gave direct and/or indirect input that was 1327 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1328 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1329 Ralph Droms, Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, 1330 Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe 1331 Macker, David Meyer, Thomas Narten, Pekka Nikander, Dave Oran, 1332 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole 1333 Troan, Michaela Vanderveen, Lixia Zhang and others in the IETF 1334 AUTOCONF and MANET working groups. Many others have provided 1335 guidance over the course of many years. 1337 10. Contributors 1339 The following individuals have contributed to this document: 1341 Eric Fleischman (eric.fleischman@boeing.com) 1342 Thomas Henderson (thomas.r.henderson@boeing.com) 1343 Steven Russert (steven.w.russert@boeing.com) 1344 Seung Yi (seung.yi@boeing.com) 1346 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1347 of the document. 1349 11. References 1351 11.1. Normative References 1353 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1354 September 1981. 1356 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1357 RFC 792, September 1981. 1359 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1360 converting network protocol addresses to 48.bit Ethernet 1361 address for transmission on Ethernet hardware", STD 37, 1362 RFC 826, November 1982. 1364 [RFC1035] Mockapetris, P., "Domain names - implementation and 1365 specification", STD 13, RFC 1035, November 1987. 1367 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1368 RFC 2131, March 1997. 1370 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1371 (IPv6) Specification", RFC 2460, December 1998. 1373 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1374 Update", RFC 3007, November 2000. 1376 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1377 and M. Carney, "Dynamic Host Configuration Protocol for 1378 IPv6 (DHCPv6)", RFC 3315, July 2003. 1380 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1381 "DNS Extensions to Support IP Version 6", RFC 3596, 1382 October 2003. 1384 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1385 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1386 December 2003. 1388 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1389 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1391 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1392 RFC 3972, March 2005. 1394 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1395 More-Specific Routes", RFC 4191, November 2005. 1397 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1398 Architecture", RFC 4291, February 2006. 1400 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1401 Message Protocol (ICMPv6) for the Internet Protocol 1402 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1404 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1405 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1406 September 2007. 1408 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1409 Address Autoconfiguration", RFC 4862, September 2007. 1411 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1412 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1413 March 2008. 1415 11.2. Informative References 1417 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1418 Switching Networks", May 1974. 1420 [I-D.cheshire-dnsext-multicastdns] 1421 Cheshire, S. and M. Krochmal, "Multicast DNS", 1422 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1423 September 2008. 1425 [I-D.clausen-manet-autoconf-recommendations] 1426 Clausen, T. and U. Herberg, "MANET Router Configuration 1427 Recommendations", 1428 draft-clausen-manet-autoconf-recommendations-00 (work in 1429 progress), February 2009. 1431 [I-D.clausen-manet-linktype] 1432 Clausen, T., "The MANET Link Type", 1433 draft-clausen-manet-linktype-00 (work in progress), 1434 October 2008. 1436 [I-D.ietf-autoconf-manetarch] 1437 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1438 Network Architecture", draft-ietf-autoconf-manetarch-07 1439 (work in progress), November 2007. 1441 [I-D.ietf-csi-proxy-send] 1442 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1443 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1444 in progress), November 2008. 1446 [I-D.ietf-dhc-subnet-alloc] 1447 Johnson, R., "Subnet Allocation Option", 1448 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1449 July 2008. 1451 [I-D.ietf-ipv6-ula-central] 1452 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1453 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1454 progress), June 2007. 1456 [I-D.ietf-manet-smf] 1457 Macker, J. and S. Team, "Simplified Multicast Forwarding 1458 for MANET", draft-ietf-manet-smf-08 (work in progress), 1459 November 2008. 1461 [I-D.ietf-v6ops-tunnel-security-concerns] 1462 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1463 Concerns With IP Tunneling", 1464 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1465 progress), October 2008. 1467 [I-D.jen-apt] 1468 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1469 L. Zhang, "APT: A Practical Transit Mapping Service", 1470 draft-jen-apt-01 (work in progress), November 2007. 1472 [I-D.templin-seal] 1473 Templin, F., "The Subnetwork Encapsulation and Adaptation 1474 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1475 August 2008. 1477 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1478 July 1978. 1480 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1481 Protocol Specification", October 2008. 1483 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1484 Communication Layers", STD 3, RFC 1122, October 1989. 1486 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1487 September 1991. 1489 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1490 Routing and Addressing Architecture", RFC 1753, 1491 December 1994. 1493 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1494 E. Lear, "Address Allocation for Private Internets", 1495 BCP 5, RFC 1918, February 1996. 1497 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1498 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1500 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1501 (MANET): Routing Protocol Performance Issues and 1502 Evaluation Considerations", RFC 2501, January 1999. 1504 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1505 Domains without Explicit Tunnels", RFC 2529, March 1999. 1507 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1508 February 2000. 1510 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1511 via IPv4 Clouds", RFC 3056, February 2001. 1513 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1514 Networks", BCP 84, RFC 3704, March 2004. 1516 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1517 RFC 3753, June 2004. 1519 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1520 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1521 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1522 RFC 3819, July 2004. 1524 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1525 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1526 May 2005. 1528 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1529 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1530 September 2005. 1532 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1533 Addresses", RFC 4193, October 2005. 1535 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1536 Internet Protocol", RFC 4301, December 2005. 1538 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1539 Network Address Translations (NATs)", RFC 4380, 1540 February 2006. 1542 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1543 Proxies (ND Proxy)", RFC 4389, April 2006. 1545 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1546 Indicator Parameter for the "tel" URI", RFC 4759, 1547 December 2006. 1549 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1550 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1551 Focus", RFC 4852, April 2007. 1553 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1554 June 2007. 1556 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1557 Extensions for Stateless Address Autoconfiguration in 1558 IPv6", RFC 4941, September 2007. 1560 Appendix A. Duplicate Address Detection (DAD) Considerations 1562 A-priori uniqueness determination (also known as "pre-service DAD") 1563 for an RLOC assigned on an enterprise-interior interface would 1564 require either flooding the entire enterprise or somehow discovering 1565 a link in the enterprise on which a node that configures a duplicate 1566 address is attached and performing a localized DAD exchange on that 1567 link. But, the control message overhead for such an enterprise-wide 1568 DAD would be substantial and prone to false-negatives due to packet 1569 loss and intermittent connectivity. An alternative to pre-service 1570 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1571 interfaces and employ a passive in-service DAD (e.g., one that 1572 monitors routing protocol messages for duplicate assignments). 1574 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1575 CGAs, IPv6 privacy addresses, etc. with very small probability of 1576 collision. Pseudo-random IPv4 RLOCs can be generated through random 1577 assignment from a suitably large IPv4 prefix space. 1579 Consistent operational practices can assure uniqueness for EBG- 1580 aggregated addresses/prefixes, while statistical properties for 1581 pseudo-random address self-generation can assure uniqueness for the 1582 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1583 RLOC delegation authority should be used when available, while a 1584 passive in-service DAD mechanism should be used to detect RLOC 1585 duplications when there is no RLOC delegation authority. 1587 Appendix B. Change Log 1589 (Note to RFC editor - this section to be removed before publication 1590 as an RFC.) 1592 Changes from -34 to 35: 1594 o Introduced EID and RLOC terminology 1596 o RLOC-based prefix delegation 1598 Changes from -33 to 34: 1600 o Enterprise management models described 1602 o Enterprise security models described 1604 o Clarification of mechanisms based on enterprise management/ 1605 security models 1607 Changes from -32 to 33:: 1609 o Secure Neighbor Discovery Proxy 1611 Changes from -28 to 29: 1613 o Updates on processing/receiving errors. 1615 Changes from -27 to 28: 1617 o Introduced concept of a default mapper. 1619 Changes from -26 to 27: 1621 o Introduced new model for PI prefix management. 1623 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1624 "isado"?) 1626 Changes from -25 to 26: 1628 o Clarifications on Router Discovery and Ingress FIltering. 1630 o Mechanisms for detecting locator liveness 1632 o Mechanisms for avoiding state synchonization requirements. 1634 Changes from -23 to 24: 1636 o Clarifications on router discovery. 1638 Changes from -22 to 23: 1640 o Clarifications on prefix mapping. 1642 Changes from -21 to 22: 1644 o Using SEAL to secure VET 1646 Changes from -20 to 21: 1648 o Enterprise partitioning. 1650 o Mapping and name service management. 1652 Changes from -18 to 20: 1654 o Added support for simple hosts. 1656 o Added EBG name service maintenace procedures 1658 o Added router and prefix maintenace procedures 1660 Changes from -17 to 18: 1662 o adjusted section headings to group autoconf operations under EIR/ 1663 EBR/EBG. 1665 o clarified M/O bits 1667 o clarified EBG roles 1669 Changes from -15 to 17: 1671 o title change to "Virtual Enterprise Traversal (VET)". 1673 o changed document focus from MANET-centric to the much-broader 1674 Enterprise-centric, where "Enterprise" is understood to also cover 1675 a wide range of MANET types. 1677 Changes from -14 to 15: 1679 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1681 o Address review comments 1683 Changes from -12 to 14: 1685 o title change to "The MANET Virtual Ethernet Abstraction". 1687 o Minor section rearrangement. 1689 o Clartifications on portable and self-configured prefixes. 1691 o Clarifications on DHCPv6 prefix delegation procedures. 1693 Changes from -11 to 12: 1695 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1697 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1698 delegation mechanism. 1700 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1702 o fixed editorials based on comments received. 1704 Changes from -10 to 11: 1706 o removed the transparent/opaque VET portal abstractions. 1708 o removed routing header as an option for MANET exit router 1709 selection. 1711 o included IPv6 SLAAC as an endorsed address configuration mechanism 1712 for the VET interface. 1714 Changes from -08 to -09: 1716 o Introduced the term "VET". 1718 o Changed address delegation language to speak of "MNBR-aggregated" 1719 instead of global/local. 1721 o Updated figures 1-3. 1723 o Explained why a MANET interface is "neutral". 1725 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1726 DHCPv4 servers; not relays. 1728 Changes from -07 to -08: 1730 o changed terms "unenhanced" and "enhanced" to "transparent" and 1731 "opaque". 1733 o revised MANET Router diagram. 1735 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1736 interface. 1738 o changed abbreviations to "MNR" and "MNBR". 1740 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1742 o rearranged Section 3.1. 1744 o various minor text cleanups 1746 Changes from -06 to -07: 1748 o added MANET Router diagram. 1750 o added new references 1752 o various minor text cleanups 1754 Changed from -05 to -06: 1756 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1758 o minor changes to preserve generality 1760 Changed from -04 to -05: 1762 o introduced conceptual "virtual ethernet" model. 1764 o support "raw" and "cooked" modes as equivalent access methods on 1765 the virutal ethernet. 1767 Changed from -03 to -04: 1769 o introduced conceptual "imaginary shared link" as a representation 1770 for a MANET. 1772 o discussion of autonomous system and site abstractions for MANETs 1774 o discussion of autoconfiguration of CGAs 1776 o new appendix on IPv6 StateLess Address AutoConfiguration 1778 Changes from -02 to -03: 1780 o updated terminology based on RFC2461 "asymmetric reachability" 1781 link type; IETF67 MANET Autoconf wg discussions. 1783 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1784 Address Detection 1786 o relaxed DHCP server deployment considerations allow DHCP servers 1787 within the MANET itself 1789 Changes from -01 to -02: 1791 o minor updates for consistency with recent developments 1793 Changes from -00 to -01: 1795 o new text on DHCPv6 prefix delegation and multilink subnet 1796 considerations. 1798 o various editorial changes 1800 Author's Address 1802 Fred L. Templin (editor) 1803 Boeing Research and Technology 1804 P.O. Box 3707 MC 7L-49 1805 Seattle, WA 98124 1806 USA 1808 Email: fltemplin@acm.org