idnits 2.17.1 draft-templin-autoconf-dhcp-38.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 507: '..._Servers', which SHOULD be set to 239....' RFC 2119 keyword, line 710: '...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 (April 14, 2009) is 5484 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 1416, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1461, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1535, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1541, 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-09 == 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 April 14, 2009 5 Expires: October 16, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-38.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 October 16, 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 . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 18 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 activities 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-in-IP encapsulation. The terms "inner" and "outer" 201 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 outer IP packets over 248 one or more sets of enterprise-interior interfaces, where each set 249 connects to 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 is a tunnel 254 endpoint router, and configures a separate VET interface over each 255 set of enterprise-interior interfaces that connect the EBR to each 256 distinct enterprise. In particular, an EBR may configure multiple 257 VET interfaces - one for each distinct enterprise. All EBRs are 258 also ERs. 260 Enterprise Border Gateway (EBG) 261 an EBR that connects VET interfaces configured over child 262 enterprises to a provider network - either directly via a 263 provider-edge interface, or indirectly via another VET interface 264 configured over a parent enterprise. EBRs may act as EBGs on some 265 VET interfaces and as ordinary EBRs on other VET interfaces. All 266 EBGs are also EBRs. 268 enterprise-interior interface 269 a ER's attachment to a link within an enterprise. Packets sent 270 over enterprise-interior interfaces may be forwarded over multiple 271 additional enterprise-interior interfaces within the enterprise 272 before they are forwarded via an enterprise-edge interface, 273 provider-edge interface or a VET interface configured over a 274 different enterprise. 276 enterprise-edge interface 277 an EBR's attachment to a link (e.g., an ethernet, a wireless 278 personal area network, etc.) on an arbitrarily-complex edge 279 network that the EBR connects to an enterprise and/or to provider 280 networks. 282 internal-virtual interface 283 a virtual interface that is a special case of either an 284 enterprise-edge or an enterprise-interior interface. Internal- 285 virtual interfaces that are also enterprise-edge interfaces are 286 often loopback interfaces of some form. Internal-virtual 287 interfaces that are also enterprise-interior interfaces are often 288 tunnel interfaces of some form configured over another enterprise- 289 interior interface. 291 provider-edge interface 292 an EBR's attachment to the Internet, or to a provider network 293 outside of the enterprise via which the Internet can be reached. 295 Virtual Enterprise Traversal (VET) 296 an abstraction that uses IP-in-IP encapsulation to create an 297 overlay that spans an enterprise in a single (inner) IP hop. 299 VET interface 300 an EBR's tunnel virtual interface used for Virtual Enterprise 301 Traversal. The EBR configures a VET interface over a set of 302 underlying enterprise-interior interface(s) belonging to the same 303 enterprise. When there are multiple distinct enterprises (each 304 with their own distinct set of enterprise-interior interfaces), 305 the EBR configures a separate VET interface over each set of 306 enterprise-interior interfaces, i.e., the EBR configures multiple 307 VET interfaces. 309 The VET interface encapsulates each inner IP packet in any mid- 310 layer headers plus an outer IP header then forwards it on an 311 underlying enterprise-interior interface such that the TTL/Hop 312 Limit in the inner header is not decremented as the packet 313 traverses the enterprise. The VET interface therefore presents an 314 automatic tunneling abstraction that represents the enterprise as 315 a single IP hop. 317 VET interfaces in non-multicast environments are Non-Broadcast, 318 Multiple Access (NBMA); VET interfaces in multicast environments 319 are multicast capable. 321 VET host 322 any node (host or router) that configures a VET interface for host 323 operation only. Note that a single node may configure some of its 324 VET interfaces as host interfaces and others as router interfaces. 326 VET node 327 any node that configures and uses a VET interface. 329 Provider-Independent (PI) prefix 330 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 331 that is either self-generated by an ER or delegated to an 332 enterprise by a registry. 334 Provider Aggregated (PA) prefix 335 an IPv6 or IPv4 prefix that is delegated to an enterprise by a 336 provider network. 338 Routing Locator (RLOC) 339 a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix 340 that can appear in enterprise-interior and/or interdomain routing 341 tables. Global-scope RLOC prefixes are delegated to specific 342 enterprises and routable within both the enterprise-interior and 343 interdomain routing regions. Enterprise-local-scope RLOC prefixes 344 (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 privacy 345 addresses [RFC1918], etc.) are self-generated by individual 346 enterprises and routable only within the enterprise-interior 347 routing region. 349 ERs use RLOCs for operating the enterprise-interior routing 350 protocol and for next-hop determination in forwarding packets 351 addressed to other RLOCs. End systems use RLOCs as addresses for 352 end-to-end communications that do not require VET encapsulation. 353 VET interfaces treat RLOCs as *outer* IP addresses during IP-in-IP 354 encapsulation. 356 Endpoint Interface iDentifier (EID) 357 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 358 within an enterprise-edge or VET overlay network scope, and may 359 also appear in enterprise-interior and/or interdomain mapping 360 tables. EID prefixes are typically seperate and distinct from any 361 RLOC prefix space. 363 Edge network routers use EIDs for operating the enterprise-edge or 364 VET overlay network routing protocol and for next-hop 365 determination in forwarding packets addressed to other EIDs. End 366 systems use EIDs as addresses for end-to-end communications that 367 require VET encapsulation. VET interfaces treat EIDs as *inner* 368 IP addresses during IP-in-IP encapsulation. 370 The following additional acronyms are used throughout the document: 372 CGA - Cryptographically Generated Address 373 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 374 FIB - Forwarding Information Base 375 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 376 NBMA - Non-Broadcast, Multiple Access 377 ND - Neighbor Discovery 378 PIO - Prefix Information Option 379 PRL - Potential Router List 380 PRLNAME - Identifying name for the PRL (default is "isatap") 381 RIO - Route Information Option 382 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 383 SEAL - Subnetwork Encapsulation and Adaptation Layer 384 SLAAC - IPv6 StateLess Address AutoConfiguation 386 3. Enterprise Characteristics 388 Enterprises consist of links that are connected by Enterprise Routers 389 (ERs) as depicted in Figure 1. ERs typically participate in a 390 routing protocol over enterprise-interior interfaces to discover 391 routes that may include multiple Layer-2 or Layer-3 forwarding hops. 392 Enterprise Border Routers (EBRs) are ERs that connect edge networks 393 to the enterprise and/or join multiple enterprises together. 394 Enterprise Border Gateways (EBGs) are EBRs that either directly or 395 indirectly connect enterprises to provider networks. 397 An enterprise may be as simple as a small collection of ERs and their 398 attached edge networks; an enterprise may also contain other 399 enterprises and/or be a subnetwork of a larger enterprise. An 400 enterprise may further encompass a set of branch offices and/or 401 nomadic hosts connected to a home office over one or several service 402 providers, e.g., through Virtual Private Network (VPN) tunnels. 404 Enterprises that comprise link types with sufficiently similar 405 properties (e.g., Layer-2 (L2) address formats, maximum transmission 406 units (MTUs), etc.) can configure a sub-IP layer routing service such 407 that IP sees the enterprise as an ordinary shared link the same as 408 for a (bridged) campus LAN. In that case, a single IP hop is 409 sufficient to traverse the enterprise without IP layer encapsulation. 411 Enterprises that comprise link types with diverse properties and/or 412 configure multiple IP subnets must also provide a routing service 413 that operates as an IP layer mechanism. In that case, multiple IP 414 hops may be necessary to traverse the enterprise such that care must 415 be taken to avoid multilink subnet issues [RFC4903]. 417 Conceptually, an ER embodies both a host function and router 418 function. The host function supports Endpoint Interface iDentifier 419 (EID)-based and/or Routing LOCator (RLOC)-based communications 420 according to the weak end system model [RFC1122]. The router 421 function engages in the enterprise-interior routing protocol, 422 connects any of the ER's edge networks to the enterprise and may also 423 connect the enterprise to provider networks (see: Figure 1). 425 In addition to other interface types, VET nodes configure VET 426 interfaces that view all other VET nodes in an enterprise as single- 427 hop neighbors attached to a virtual link. VET nodes configure a 428 separate VET interface for each distinct enterprise to which they 429 connect, and discover other EBRs on each VET interface that can be 430 used for forwarding packets to off-enterprise destinations. 432 For each distinct enterprise, an enterprise trust basis must be 433 established and consistently applied. For example, in enterprises in 434 which EBRs establish symmetric security associations, mechanisms such 435 as IPsec [RFC4301] can be used to assure authentication and 436 confidentiality. In other enterprise network scenarios, asymmetric 437 securing mechanisms such as SEcure Neighbor Discovery (SEND) 438 [RFC3971] may be necessary to authenticate exchanges based on trust 439 anchors. 441 Finally, in enterprises with a centralized management structure 442 (e.g., a corporate campus network), the enterprise name service and a 443 synchronized set of EBGs can provide infrastructure support for 444 virtual enterprise traversal. In that case, the EBGs can provide a 445 "default mapper" [I-D.jen-apt] service used for short term packet 446 forwarding until EBR neighbor relationships can be established. In 447 enterprises with a distributed management structure (e.g., MANETs), 448 peer-to-peer coordination between the EBRs themselves may be 449 required. Recognizing that various use cases will entail a continuum 450 between a fully-distributed and fully-centralized approach, the 451 following sections present the mechanisms of Virtual Enterprise 452 Traversal as they apply to a wide variety of scenarios. 454 4. Autoconfiguration 456 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 457 specified in the following subsections: 459 4.1. Enterprise Router (ER) Autoconfiguration 461 ERs configure enterprise-interior interfaces and engage in any 462 routing protocols over those interfaces. 464 When an ER joins an enterprise, it first configures a unique IPv6 465 link-local address on each enterprise-interior interface and 466 configures an IPv4 link-local address on each enterprise-interior 467 interface that requires an IPv4 link-local capability. IPv6 link- 468 local address generation mechanisms that provide sufficient 469 uniqueness include Cryptographically Generated Addresses (CGAs) 470 [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 471 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 472 [RFC4862], etc. The mechanisms specified in [RFC3927] provide an 473 IPv4 link-local address generation capability. 475 Next, the ER configures an RLOC on each of its enterprise-interior 476 interfaces and engages in any routing protocols on those interfaces. 477 The ER can configure an RLOC via explicit management, DHCP 478 autoconfiguration, pseudo-random self-generation from a suitably 479 large address pool, or through an alternate autoconfiguration 480 mechanism. 482 Alternatively (or in addition), the ER can request RLOC prefix 483 delegations via an automated prefix delegation exchange over an 484 enterprise-interior interface, and can assign the prefix(es) on 485 enterprise edge interfaces. In that case, the ER can use an RLOC 486 assigned to an enterprise-edge interface for enterprise-interior 487 routing protocol operation and next-hop determination purposes. Note 488 that in some cases, the same enterprise edge interfaces may assign 489 both RLOC and an EID addresses if there is a means for source address 490 selection. In other cases (e.g., for separation of security 491 domains), RLOCs and EIDs must be assigned on separate sets of 492 enterprise edge interfaces. 494 Self-generation of RLOCs for IPv6 can be from a large IPv6 local-use 495 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 496 generation of RLOCs for IPv4 can be from a large IPv4 private address 497 range (e.g., [RFC1918]). When self-generation is used alone, the ER 498 must continuously monitor the RLOCs for uniqueness, e.g., by 499 monitoring the routing protocol. 501 DHC generation of RLOCs may require support from relays within the 502 enterprise. For DHCPv6, relays that do not already know the RLOC of 503 a server within the enterprise relay requests to the 504 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For 505 DHCPv4, relays that do not already know the RLOC of a server within 506 the enterprise relay requests to the site-scoped IPv4 multicast group 507 address 'All_DHCPv4_Servers', which SHOULD be set to 239.255.2.1 508 unless an alternate multicast group for the site is known. DHCPv4 509 servers that delegate RLOCs should therefore join the 510 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 511 received for that group. 513 A combined approach using both DHCP and self-generation is also 514 possible when the ER configures both a DHCP client and relay that are 515 connected, e.g., via a pair of back-to-back connected ethernet 516 interfaces, a tun/tap interface, a loopback interface, inter-process 517 communication, etc. The ER first self-generates a temporary RLOC 518 used only for the purpose of procuring an actual RLOC taken from a 519 disjoint addressing range. The ER then engages in the routing 520 protocol and performs a DHCP client/relay exchange using the 521 temporary RLOC as the address of the relay. When the DHCP server 522 delegates an actual RLOC addres/prefix, the ER abandons the temporary 523 RLOC and re-engages in the routing protocol using an RLOC taken from 524 the delegation. 526 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 527 enterprise-interior interfaces as singleton addresses (i.e., as /32s 528 for IPv4 and /128s for IPv6) may be necessary to avoid multilink 529 subnet issues. 531 4.2. Enterprise Border Router (EBR) Autoconfiguration 533 EBRs are ERs that configure VET interfaces over distinct sets of 534 underlying enterprise-interior interfaces; an EBR can connect to 535 multiple enterprises, in which case it would configure multiple VET 536 interfaces. In addition to the ER autoconfiguration procedures 537 specified in Section 4.1 EBRs perform the following autoconfiguration 538 operations: 540 4.2.1. VET Interface Autoconfiguration 542 VET interface autoconfiguration entails: 1) interface initialization, 543 2) EBG discovery and enterprise identification, and 3) EID 544 configuration. These functions are specified in the following 545 sections: 547 4.2.1.1. Interface Initialization 549 EBRs configure a VET interface over a set of underlying enterprise- 550 interior interfaces belonging to the same enterprise, where the VET 551 interface presents a virtual link abstraction in which all EBRs in 552 the enterprise appear as single hop neighbors through the use of IP- 553 in-IP encapsulation. After the EBR configures a VET interface, it 554 initializes the interface and assigns an IPv6 link-local address and 555 an IPv4 link-local address if necessary. 557 When IPv6 and IPv4 are used as the inner/outer protocols 558 (respectively), the EBR autoconfigures an ISATAP link-local address 559 ([RFC5214], Section 6.2) on the VET interface to support packet 560 forwarding and operation of the IPv6 neighbor discovery protocol. 561 The ISATAP link-local address embeds an IPv4 RLOC, and need not be 562 checked for uniqueness since the IPv4 RLOC itself is managed for 563 uniqueness (see: Section 4.1). 565 Link-local address configuration for other inner/outer IP protocol 566 combinations is through administrative configuration or through an 567 unspecified alternate method. Link local address configuration for 568 other inner/outer IP protocol combinations may not be necessary if an 569 EID can be configured through other means (see: Section 4.2.1.3). 571 After the EBR initializes a VET interface, it can communicate with 572 other VET nodes as single-hop neighbors on the VET interface from the 573 viewpoint of the inner IP protocol. 575 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 576 Identification 578 The EBR next discovers a list of EBGs for each of its VET interfaces. 579 The list can be discovered through information conveyed in the 580 routing protocol, through the Potential Router List (PRL) discovery 581 mechanisms outlined in ([RFC5214], Section 8.3.2), through DHCP 582 options, etc. In multicast-capable enterprises, EBRs can also listen 583 for advertisements on the 'rasadv' [RASADV] multicast group address. 585 In particular, whether or not routing information is available the 586 EBR can discover the list of EBGs by resolving an identifying name 587 for the PRL ('PRLNAME') formed as 'hostname.domainname', where 588 'hostname' is an enterprise-specific name string and 'domainname' is 589 an enterprise-specific DNS suffix. The EBR discovers 'PRLNAME' 590 through manual configuration, a DHCP option, 'rasadv' protocol 591 advertisements, link-layer information (e.g., an IEEE 802.11 SSID) or 592 through some other means specific to the enterprise. In the absence 593 of other information, the EBR sets the 'hostname' component of 594 'PRLNAME' to "isatap" and sets the 'domainname' component only if an 595 enterprise-specifc DNS suffix "example.com" is known (e.g., as 596 "isatap.example.com"). 598 The global Internet interdomain routing core represents a specific 599 example of an enterprise network scenario, albeit on an enormous 600 scale. The 'PRLNAME' assigned to the global Internet interdomain 601 routing core is "isatap.net". 603 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 604 resolving 'PRLNAME' to a list of RLOC addresses through a name 605 service lookup. For centrally-managed enterprises, the EBR resolves 606 'PRLNAME' using an enterprise-local name service (e.g., the 607 enterprise-local DNS). For enterprises with a distributed management 608 structure, the EBR resolves 'PRLNAME' using LLMNR [RFC4759] over the 609 VET interface. In that case, all EBGs in the PRL respond to the 610 LLMNR query, and the EBR accepts the union of all responses. 612 Each distinct enterprise must have a unique identity that EBRs can 613 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 614 well as the RLOCs of EBGs and the IP prefixes they aggregate serve as 615 an identifier for the enterprise. 617 4.2.1.3. EID Configuration 619 After EBG discovery, the EBR configures EIDs on its VET interfaces. 620 When IPv6 and IPv4 are used as the inner/outer protocols 621 (respectively), the EBR autoconfigures EIDs as specified in 622 Section 5.4.1. In particular, the EBR acts as a host on its VET 623 interfaces for router and prefix discovery purposes but acts as a 624 router on its VET interfaces for routing protocol operation and 625 packet forwarding purposes. 627 EID configuration for other inner/outer IP protocol combinations is 628 through administrative configuration or through an unspecified 629 alternate method; in some cases, such EID configuration can be 630 performed independently of EBG discovery. 632 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration 634 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 635 autoconfiguration exchanges with EBGs over VET interfaces, where each 636 EBG may be configured as either a DHCP relay or DHCP server. 638 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 639 delegation exchange, explicit management, etc. 641 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 642 exchanges. In particular, the EBR (acting as a requesting router) 643 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 644 obtain IPv6 EID prefixes from the server (acting as a delegating 645 router). 647 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 648 exchange [RFC3315]. For example, to perform the 2-message exchange 649 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 650 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 651 relay (see: Section 4.1). The relay then forwards the message over 652 the VET interface to an EBG, which either services the request or 653 relays it further. The forwarded Solicit message will elicit a reply 654 from the server containing PA IPv6 prefix delegations. 656 The EBR can propose a specific prefix to the DHCPv6 server per 657 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 658 available. The server will check the proposed prefix for consistency 659 and uniqueness, then return it in the reply to the EBR if it was able 660 to perform the delegation. 662 After the EBR receives PA prefix delegations, it can provision the 663 prefixes on enterprise-edge interfaces as well as on other VET 664 interfaces for which it is configured as an EBG. 666 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration 668 Independent of any PA prefixes, EBRs can acquire and use Provider- 669 Independent (PI) EID prefixes that are self-configured (e.g., using 670 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 671 using [I-D.ietf-ipv6-ula-central], etc.). When an EBR acquires a PI 672 prefix, it must also obtain credentials that it can use to prove 673 prefix ownership when it registers the prefixes with EBGs within an 674 enterprise (see: Section 5.4 and Section 5.5). 676 After the EBR receives PI prefix delegations, it can provision the 677 prefixes on enterprise-edge interfaces as well as on other VET 678 interfaces for which it is configured as an EBG. 680 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 682 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 684 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 686 EBGs are EBRs that connect child enterprises to provider networks via 687 provider-edge interfaces and/or via VET interfaces configured over 688 parent enterprises. EBGs autoconfigure their provider-edge 689 interfaces in a manner that is specific to the provider connections, 690 and autoconfigure their VET interfaces configured over parent 691 interfaces using the EBR autoconfiguration procedures specified in 692 Section 4.2. 694 For each of its VET interfaces configured over a child enterprise, 695 the EBG initializes the interface and configures an EID the same as 696 for an ordinary EBR (see: Section 4.2.1). It must then arrange to 697 add one or more of its RLOCs associated with the child enterprise to 698 the PRL, and must maintain these resource records in accordance with 699 ([RFC5214], Section 9). In particular, for each VET interface 700 configured over a child enterprise the EBG adds the RLOCs to name 701 service resource records for 'PRLNAME'. 703 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 704 configured over child enterprises with a distributed management 705 structure. 707 EBGs configure a DHCP relay/server on VET interfaces configured over 708 child enterprises that require DHCP services. 710 To avoid looping, EBGs MUST NOT configure a default route on a VET 711 interface configured over a child interface. 713 4.4. VET Host Autoconfiguration 715 Nodes that cannot be attached via an EBR's enterprise-edge interface 716 (e.g., nomadic laptops that connect to a home office via a Virtual 717 Private Network (VPN)) can instead be configured for operation as a 718 simple host connected to the VET interface. Such VET hosts perform 719 the same VET interface autoconfiguration procedures as specified for 720 EBRs in Section 4.2.1, but they configure their VET interfaces as 721 host interfaces (and not router interfaces). VET hosts can then send 722 packets to the EID addresses of other hosts on the VET interface, or 723 to off-enterprise EID destinations via a next-hop EBR. 725 Note that a node may be configured as a host on some VET interfaces 726 and as an EBR/EBG on other VET interfaces. 728 5. Internetworking Operation 730 Following the autoconfiguration procedures specified in Section 4, 731 ERs, EBRs, EBGs and VET hosts engage in normal internetworking 732 operations as discussed in the following sections: 734 5.1. Routing Protocol Participation 736 Following autoconfiguration, ERs engage in any RLOC-based IP routing 737 protocols and forward IP packets with RLOC addresses. EBRs can 738 additionally engage in any EID-based IP routing protocols and forward 739 IP packets with EID addresses. Note that the EID-based IP routing 740 domains are separate and distinct from any RLOC-based IP routing 741 domains. 743 5.2. RLOC-based Communications 745 When permitted by policy and supported by routing, end systems can 746 avoid VET interface encapsulation through communications that 747 directly invoke the outer IP protocol using RLOC addresses instead of 748 EID addresses. End systems can use source address selection rules to 749 determine whether to use EID or RLOC addresses based on, e.g., name 750 service records. 752 5.3. EID-based Communications 754 In many enterprise scenarios, the use of EID-based communications 755 (i.e., instead of RLOC-based communications) may be necessary and/or 756 beneficial to support address scaling, NAT avoidance, security domain 757 separation, site multi-homing, traffic engineering, etc. 759 The remainder of this section discusses internetworking operation for 760 EID-based communications using the VET interface abstraction. 762 5.4. IPv6 Router Discovery and Prefix Registration 764 The following sections discuss router and prefix discovery 765 considerations for the case of IPv6 as the inner IP protocol: 767 5.4.1. IPv6 Router and Prefix Discovery 769 EBGs follow the router and prefix discovery procedures specified in 770 ([RFC5214], Section 8.2). They send solicited RAs over VET 771 interfaces for which they are configured as gateways with default 772 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 773 with any other required options/parameters. The RAs can also include 774 PIOs with the 'L' bit set to 0 and with a prefix such as '2001: 775 DB8::/48' as a hint of an aggregated prefix from which the EBG is 776 willing to delegate longer PA prefixes. When PIOs that contain PA 777 prefixes for SLAAC are included, the 'M' flag in the RA should also 778 be set to 0. 780 VET nodes follow the router and prefix discovery procedures specified 781 in ([RFC5214], Section 8.3). They discover EBGs within the 782 enterprise as specified in Section 4.2.1.2, then perform RS/RA 783 exchanges with the EBGs to establish and maintain default routes. In 784 particular the VET node sends unicast RS messages to EBGs over its 785 VET interface(s) to receive RAs. Depending on the enterprise network 786 trust basis, VET nodes may be required to use SEND to secure the 787 RS/RA exchanges. 789 When the VET node receives an RA, it authenticates the message then 790 configures a default route based on the Router Lifetime. If the RA 791 contains Prefix Information Options (PIOs) with the 'A' and 'L' bits 792 set to 1, the VET node also autoconfigures IPv6 addresses from the 793 advertised prefixes using SLAAC and assigns them to the VET 794 interface. Thereafter, the VET node accepts packets that are 795 forwarded by EBGs for which it has current default routing 796 information (i.e., ingress filtering is based on the default router 797 trust relationship rather than a prefix-specific ingress filter 798 entry). 800 In enterprises in which DHCPv6 is preferred, DHCPv6 exchanges between 801 EBRs and EBGs may be sufficient to convey default router and prefix 802 information. In that case, RS/RA exchanges may not be necessary. 804 5.4.2. IPv6 PA Prefix Registration 806 After an EBR discovers default routes, it can use DHCP prefix 807 delegation to obtain PA prefixes via an EBG as specified in 808 Section 4.2.2. The DHCP server ensures that the delegations are 809 unique and that the EBG's router function will forward IP packets 810 over the VET interface to the correct EBR. In particular, the EBG 811 must register and track the PA prefixes that are delegated to each 812 EBR. 814 The PA prefix registrations remain active in the EBGs as long as the 815 EBR continues to issue DHCP renewals over the VET interface before 816 lease lifetimes expire. The lease lifetime also keeps the delegation 817 state active even if communications between the EBR and DHCP server 818 are disrupted for a period of time (e.g., due to an enterprise 819 network partition) before being reestablished (e.g., due to an 820 enterprise network merge). 822 5.4.3. IPv6 PI Prefix Registration 824 After an EBR discovers default routes, it must register its PI 825 prefixes by sending RAs to a set of one or more EBGs with Route 826 information Options (RIOs) [RFC4191] that contain the EBR's PI 827 prefixes. Each RA must include the RLOC of an EBG as the outer IP 828 destination address and a link-local address assigned to the VET 829 interface as the inner IP destination address. For enterprises that 830 use SEND, the RAs also include a CGA link-local inner source address 831 along with SEND credentials plus any certificates needed to prove 832 ownership of the PI prefixes. The EBR additionally tracks the set of 833 EBGs that it sends RAs to so that it can send subsequent RAs to the 834 same set. 836 When the EBG receives the RA, it first authenticates the message; if 837 the authentication fails, the EBG discards the RA. Otherwise, the 838 EBG installs the PI prefixes with their respective lifetimes in its 839 Forwarding Information Base (FIB) and configures them for both 840 ingress filtering [RFC3704] and forwarding purposes. In particular, 841 the EBG configures the FIB entries as ingress filter rules to accept 842 packets received on the VET interface that have a source address 843 taken from the PI prefixes. It also configures the FIB entries to 844 forward packets received on other interfaces with a destination 845 address taken from the PI prefixes to the EBR that registered the 846 prefixes on the VET interface. 848 The EBG then publishes the PI prefixes in a distributed database 849 (e.g., in a private instance of a routing protocol in which only EBGs 850 participate, via an automated name service update mechanism 851 [RFC3007], etc.). For enterprises that are managed under a 852 centralized administrative authority, the EBG also publishes the PI 853 prefixes in the enterprise-local name service (e.g., the enterprise- 854 local DNS [RFC1035]). 856 In particular, the EBG publishes each /56 prefix taken from the PI 857 prefixes as a separate FQDN that consists of a sequence of 14 nibbles 858 in reverse order (i.e., the same as in [RFC3596], Section 2.5) 859 followed by the string 'ip6' followed by the string 'PRLNAME'. For 860 example, when 'PRLNAME' is "isatap.example.com", the EBG publishes 861 the prefix '2001:DB8::/56' as: 862 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. The EBG 863 includes the outer RLOC source address of the RA (e.g., in a DNS A 864 resource record) in each prefix publication. For enterprises that 865 use SEND, the EBG also includes the inner IPv6 CGA source address 866 (e.g., in a DNS AAAA record) in each prefix publication. If the 867 prefix was already installed in the distributed database, the EBG 868 instead adds the outer RLOC source address (e.g., in an additional 869 DNS A records) to the pre-existing publication to support PI prefixes 870 that are multihomed. For enterprises that use SEND, this latter 871 provision requires all EBRs of a multihomed site that advertise the 872 same PI prefixes in RAs to use the same CGA and the same SEND 873 credentials. 875 After the EBG authenticates the RA and publishes the PI prefixes, it 876 next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the 877 VET interfaces configured over any of its parent enterprises and 878 relays a proxied RA to the EBGs on those interfaces. (For 879 enterprises that use SEND, the EBG additionally acts as a SEcure 880 Neighbor Discovery Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) 881 EBGs in parent enterprises that receive the proxied RAs in turn act 882 as NDProxys/SENDProxys to relay the RAs to EBGs on their parent 883 enterprises, etc. The RA proxying and PI prefix publication recurses 884 in this fashion and ends when an EBR attached to an interdomain 885 routing core is reached. 887 After the initial PI prefix registration, the EBR that owns the 888 prefix(es) must periodically send additional RAs to its set of EBGs 889 to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in 890 parent enterprises that it relays the proxied RAs to, and should 891 relay subsequent RAs to the same set. 893 This procedure has a direct analogy in the Teredo method of 894 maintaining state in network middleboxes through the periodic 895 transmission of "bubbles" [RFC4380]. 897 5.4.4. IPv6 Next-Hop EBR Discovery 899 VET nodes discover destination-specific next-hop EBRs within the 900 enterprise by querying the name service for the /56 IPv6 PI prefix 901 taken from a packet's destination address, by forwarding packets via 902 a default route to an EBG, or by some other inner IP to outer IP 903 address mapping mechanism. For example, for the IPv6 destination 904 address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET 905 node can lookup the domain name: 906 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. If the name 907 service lookup succeeds, it will return RLOC addresses (e.g., in DNS 908 A records) that correspond to the RLOCs assigned to enterprise 909 interior interfaces of next-hop EBRs to which the VET node can 910 forward packets. (In enterprises that use SEND, it will also return 911 an IPv6 CGA address, e.g., in a DNS AAAA record.) 913 Name service lookups in enterprises with a centralized management 914 structure use an infrastructure-based service, e.g., an enterprise- 915 local DNS. Name service lookups in enterprises with a distributed 916 management structure and/or that lack an infrastructure-based name 917 service instead use LLMNR over the VET interface. When LLMNR is 918 used, the EBR that performs the lookup sends an LLMNR query (with the 919 /56 prefix taken from the IP destination address encoded in dotted- 920 nibble format as shown above) and accepts the union of all replies it 921 receives from other EBRs on the VET interface. When an EBR receives 922 an LLMNR query, it responds to the query IFF it aggregates an IP 923 prefix that covers the prefix in the query. 925 Alternatively, in enterprises with a stable and highly-available set 926 of EBGs, the VET node can simply forward an initial packet via a 927 default route to an EBG. The EBG will forward the packet to a next- 928 hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] 929 (using SEND, if necessary). If the packet's source address is on- 930 link on the VET interface, the EBG returns an ordinary "router-to- 931 host" redirects with the source address of the packet as its 932 destination. If the packet's source address is not on-link, the EBG 933 instead returns a "router-to-router" redirect with the link-local 934 ISATAP address of the previous-hop EBR as its destination. When IPv4 935 is used as the outer IP protocol, the EBG also includes in the 936 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 937 contain the IPv4 RLOCs of potential next-hop EBRs arranged in order 938 from lowest to highest priority (i.e., the first LLAO contains the 939 lowest priority RLOC and the final LLAO option contains the highest 940 priority). These LLAOs are formatted using a modified version of the 941 form specified in ( [RFC2529], Section 5) as shown in Figure 2 (the 942 LLAO format for IPv6 as the outer IP protocol is out of scope): 944 +-------+-------+-------+-------+-------+-------+-------+-------+ 945 | Type |Length | TTL | IPv4 Address | 946 +-------+-------+-------+-------+-------+-------+-------+-------+ 948 Figure 2: VET Link-Layer Address Option Format 950 For each such IPv6/IPv4 LLAO, the Type is set to 2 (for Target Link- 951 Layer Address Option), Length is set to 1, and IPv4 Address is set to 952 the IPv4 RLOC of the next-hop EBR. TTL is set to the time in seconds 953 that the recipient may cache the RLOC, where the value 65535 954 represents infinity and the value 0 suspends forwarding through this 955 RLOC. 957 When a VET host receives an ordinary "router-to-host" redirect, it 958 processes the redirect exactly as specified in [RFC4861], Section 8. 959 When an EBR receives a "router-to-router" redirect, it discovers the 960 RLOC addresses of potential next-hop EBRs by examining the LLAOs 961 included in the redirect. The EBR then installs a FIB entry that 962 contains the /56 prefix of the destination address encoded in the 963 redirect and the list of RLOCs of potential next-hop EBRs. The EBR 964 then enables the FIB entry for forwarding to next-hop EBRs but DOES 965 NOT enable it for ingress filtering acceptance of packets from next- 966 hop EBRs (i.e., the forwarding determination is unidirectional). 968 In enterprises in which spoofing is possible, after discovering 969 potential next-hop EBRs (either through name service lookup or ICMP 970 redirect) the EBR must send authenticating credentials before 971 forwarding packets via the next-hops. To do so, the EBR must send 972 RAs over the VET interface (using SEND, if necessary) to one or more 973 of the potential next-hop EBRs with an RLOC as the outer IP 974 destination address. The RAs must include a Route Information Option 975 (RIO) [RFC4191] that contains the /56 PI prefix of the original 976 packet's source address. After sending the RAs, the EBR can either 977 enable the new FIB entry for forwarding immediately or delay until it 978 receives an explicit acknowledgement that a next-hop EBR received the 979 RA (e.g., using the SEAL explicit acknowledgement mechanism - see: 980 Section 5.7). 982 When a next-hop EBR receives the RA, it authenticates the message 983 then performs a name service lookup on the prefix in the RIO if 984 further authenticating evidence is required. If the name service 985 returns resource records that are consistent with the inner and outer 986 IP addresses of the RA, the next-hop EBR then installs the prefix in 987 the RIO in its FIB and enables the FIB entry for ingress filtering 988 but DOES NOT enable it for forwarding purposes. After an EBR sends 989 initial RAs following a redirect, it should send periodic RAs to 990 refresh the next-hop EBR's ingress filter prefix lifetimes as long as 991 traffic is flowing. 993 EBRs retain the FIB entries created as result of an ICMP redirect 994 until all RLOC TTLs expire, or until no hints of forward progress 995 through any of the associated RLOCs are received. In this way, RLOC 996 liveness detection exactly parallels IPv6 Neighbor Unreachability 997 Detection ([RFC4861], Section 3). 999 5.5. IPv4 Router Discovery and Prefix Registration 1001 When IPv4 is used as the inner IP protocol, router discovery and 1002 prefix registration exactly parallels the mechanisms specified for 1003 IPv6 in Section 5.4. To support this, modifications to the ICMPv4 1004 Router Advertisement [RFC1256] function to include SEND constructs, 1005 and modifications to the ICMPv4 Redirect [RFC0792] function to 1006 support router-to-router redirects will be specified in a future 1007 document. Additionally, publications for IPv4 prefixes will be in 1008 dotted-nibble format in the 'ip4.isatap.example.com' domain. For 1009 example, the IPv4 prefix 192.0.2/24 would be represented as: 1010 '2.0.0.0.0.c.ip4.isatap.example.com'. 1012 5.6. VET Encapsulation 1014 VET nodes forward packets by consulting the FIB to determine a 1015 specific EBR/EBG as the next-hop router on a VET interface. When 1016 multiple next-hop routers are available, VET nodes can use default 1017 router preferences, routing protocol information, traffic engineering 1018 configurations, etc. to select the best exit router. When there is 1019 no FIB information other than "default" available, VET nodes can 1020 discover the next-hop EBR/EBG through the mechanisms specified in 1021 Section 5.4 and Section 5.5. 1023 VET interfaces encapsulate inner IP packets in any mid-layer headers 1024 followed by an outer IP header according to the specific 1025 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal], 1026 etc.); they next submit the encapsulated packet to the outer IP 1027 forwarding engine for transmission on an underlying enterprise- 1028 interior interface. 1030 For forwarding to next-hop addresses over VET interfaces that use 1031 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 1032 address (i.e., the IPv4 RLOC of the next-hop EBR) through static 1033 extraction of the IPv4 address embedded in the next-hop ISATAP 1034 address. For other IP-in-IP encapsulations, determination of the 1035 outer destination address is through administrative configuration or 1036 through an unspecified alternate method. When there are multiple 1037 candidate destination RLOCs available, the VET node should only 1038 select an RLOC for which there is current forwarding information in 1039 the outer IP protocol FIB. 1041 5.7. SEAL Encapsulation 1043 VET nodes should use SEAL encapsulation [I-D.templin-seal] over VET 1044 interfaces to accommodate path MTU diversity, to defeat source 1045 address spoofing, and to monitor next-hop EBR reachability. SEAL 1046 encapsulation maintains a unidirectional and monotonically- 1047 incrementing per-packet identification value known as the 'SEAL_ID'. 1048 When a VET node that uses SEAL encapsulation sends a SEND-protected 1049 Router Advertisement (RA) or Router Solicitation (RS) message to 1050 another VET node, both nodes cache the new SEAL_ID as per-tunnel 1051 state used for maintaining a window of unacknowledged SEAL_IDs. 1053 In terms of security, when a VET node receives an ICMP message, it 1054 can confirm that the packet-in-error within the ICMP message 1055 corresponds to one of its recently-sent packets by examining the 1056 SEAL_ID along with source and destination addresses, etc. 1057 Additionally, a next-hop EBR can track the SEAL_ID in packets 1058 received from EBRs for which there is an ingress filter entry and 1059 discard packets that have SEAL_ID values outside of the current 1060 window. 1062 In terms of next-hop reachability, an EBR can set the SEAL 1063 "Acknowledgement Requested" bit in messages to receive confirmation 1064 that a next-hop EBR is reachable. Setting the "Acknowledgement 1065 Requested" bit is also used as the method for maintaining the window 1066 of outstanding SEAL_ID's. 1068 5.8. Generating Errors 1070 When an EBR receives an IPv6 packet over a VET interface and there is 1071 no matching ingress filter entry, it drops the packet and returns an 1072 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 1073 ingress/egress policy" message to the previous hop EBR subject to 1074 rate limiting. 1076 When an EBR receives an IPv6 packet over a VET interface, and there 1077 is no longest-prefix-match FIB entry for the destination, it returns 1078 an ICMPv6 "Destination Unreachable; No route to destination" message 1079 to the previous hop EBR subject to rate limiting. 1081 When an EBR receives an IPv6 packet over a VET interface and the 1082 longest-prefix-match FIB entry for the destination is via a next-hop 1083 configured over the same VET interface the packet arrived on, the EBR 1084 forwards the packet then (if the FIB prefix is longer than ::/0) 1085 sends a router-to-router ICMPv6 Redirect message (using SEND, if 1086 necessary) to the previous hop EBR as specified in Section 5.4.4. 1088 Generation of other ICMP messages [RFC0792][RFC4443] is the same as 1089 for any IP interface. 1091 5.9. Processing Errors 1093 When an EBR receives an ICMPv6 "Destination Unreachable; Source 1094 address failed ingress/egress policy" message from a next-hop EBR, 1095 and there is a longest-prefix-match FIB entry for the original 1096 packet's destination that is more-specific than ::/0, the EBR 1097 discards the message and marks the FIB entry for the destination as 1098 "forwarding suspended" for the RLOC taken from the source address of 1099 the ICMPv6 message. The EBR should then allow subsequent packets to 1100 flow through different RLOCs associated with the FIB entry until it 1101 forwards a new RA to the suspended RLOC. If the EBR receives 1102 excessive ICMPv6 ingress/egress policy errors through multiple RLOCs 1103 associated with the same FIB entry, it should delete the FIB entry 1104 and allow subsequent packets to flow through an EBG if supported in 1105 the specific enterprise scenario. 1107 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1108 to destination" message from a next-hop EBR, it forwards the ICMPv6 1109 message to the source of the original packet as normal. If the EBR 1110 has longest-prefix-match FIB entry for the original packet's 1111 destination that is more-specific than ::/0, the EBR also deletes the 1112 FIB entry. 1114 When an EBR receives an authentic ICMPv6 Redirect, it processes the 1115 packet as specified in Section 5.4.4. 1117 When an EBG receives new mapping information for a specific 1118 destination prefix, it can propagate the update to other EBRs/EBGs by 1119 sending an ICMPv6 redirect message to the 'All Routers' link-local 1120 multicast address with a LLAO with the TTL for the unreachable LLAO 1121 set to zero, and with a NULL packet in error. 1123 Additionally, a VET node may receive ICMP "Destination Unreachable; 1124 net / host unreachable" messages from an ER indicating that the path 1125 to a VET neighbor may be failing. The VET node should first check, 1126 e.g., the SEAL_ID, IPsec sequence number, source address of the 1127 original packet if available, etc. to obtain reasonable assurance 1128 that the ICMP message is authentic, then should mark the longest- 1129 prefix-match FIB entry for the destination as "forwarding suspended" 1130 for the RLOC destination address of the ICMP packet-in-error. If the 1131 VET node receives excessive ICMP unreachable errors through multiple 1132 RLOCs associated with the same FIB entry, it should delete the FIB 1133 entry and allow subsequent packets to flow through a different route. 1135 5.10. Mobility and Multihoming Considerations 1137 EBRs that travel between distinct enterprise networks must either 1138 abandon their PA prefixes that are relative to the "old" enterprise 1139 and obtain new ones relative to the "new" enterprise, or somehow 1140 coordinate with a "home" enterprise to retain ownership of the 1141 prefixes. In the first instance, the EBR would be required to 1142 coordinate a network renumbering event using the new PA prefixes 1143 [RFC4192]. In the second instance, an ancillary mobility management 1144 mechanism must be used. 1146 EBRs can retain their PI prefixes as they travel between distinct 1147 enterprise networks as long as they register the prefixes with new 1148 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1149 departure. Prefix registration with new EBGs is coordinated exactly 1150 as specified in Section 5.4.3; prefix withdrawal from old EBGs is 1151 simply through re-announcing the PI prefixes with zero lifetimes. 1153 Since EBRs can move about independently of one another, stale FIB 1154 entry state may be left in VET nodes when a neighboring EBR departs. 1155 Additionally, EBRs can lose state for various reasons, e.g., power 1156 failure, machine reboot, etc. For this reason, EBRs are advised to 1157 set relatively short PI prefix lifetimes in RIO options, and to send 1158 additional RAs to refresh lifetimes before they expire. (EBRs should 1159 place conservative limits on the RAs they send to reduce congestion, 1160 however.) 1162 EBRs may register their PI prefixes with multiple EBGs for 1163 multihoming purposes. EBRs should only forward packets via EBGs with 1164 which it has registered its PI prefixes, since other EBGs may drop 1165 the packets and return ICMPv6 "Destination Unreachable; Source 1166 address failed ingress/egress policy" messages. 1168 EBRs can also act as delegating routers to sub-delegate portions of 1169 their PI prefixes to requesting routers on their enterprise edge 1170 interfaces and on VET interfaces for which they are configured as 1171 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1172 become the PA prefixes for downstream-dependent nodes. Downstream- 1173 dependent nodes that travel with a mobile provider EBR can continue 1174 to use addresses configured from PA prefixes; downstream-dependent 1175 nodes that move away from their provider EBR must perform address/ 1176 prefix renumbering when they associate with a new provider. 1178 The EBGs of a multi-homed enterprise should participate in a private 1179 inner IP routing protocol instance between themselves (possibly over 1180 an alternate topology) to accommodate enterprise partitions/merges as 1181 well as intra-enterprise mobility events. These peer EBGs should 1182 accept packets from one another without respect to the destination 1183 (i.e., ingress filtering is based on the peering relationship rather 1184 than a prefix-specific ingress filter entry). 1186 5.11. Multicast 1188 In multicast-capable deployments, ERs provide an enterprise-wide 1189 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1190 [I-D.ietf-manet-smf], PIM routing, DVMRP routing, etc.) over their 1191 enterprise-interior interfaces such that outer IP multicast messages 1192 of site- or greater scope will be propagated across the enterprise. 1193 For such deployments, VET nodes can also provide an inner IP 1194 multicast/broadcast capability over their VET interfaces through 1195 mapping of the inner IP multicast address space to the outer IP 1196 multicast address space. In that case, operation of link- or greater 1197 scoped inner IP multicasting services (e.g., a link-scoped neighbor 1198 discovery protocol) over the VET interface is available, but link- 1199 scoped services should be used sparingly to minimize enterprise-wide 1200 flooding. 1202 VET nodes encapsulate inner IP multicast messages sent over the VET 1203 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1204 outer IP header with a site-scoped outer IP multicast address as the 1205 destination. For the case of IPv6 and IPv4 as the inner/outer 1206 protocols (respectively), [RFC2529] provides mappings from the IPv6 1207 multicast address space to a site-scoped IPv4 multicast address space 1208 (for other IP-in-IP encapsulations, mappings are established through 1209 administrative configuration or through an unspecified alternate 1210 static mapping). 1212 Multicast mapping for inner IP multicast groups over outer IP 1213 multicast groups can be accommodated, e.g. through VET interface 1214 snooping of inner multicast group membership and routing protocol 1215 control messages. To support inner-to-outer IP multicast mapping, 1216 the VET interface acts as a virtual outer IP multicast host connected 1217 to its underlying enterprise-interior interfaces. When the VET 1218 interface detects inner IP multicast group joins or leaves, it 1219 forwards corresponding outer IP multicast group membership reports on 1220 an enterprise-interior interface over which the VET interface is 1221 configured. If the VET node is configured as an outer IP multicast 1222 router on the underlying enterprise-interior interfaces, the VET 1223 interface forwards locally looped-back group membership reports to 1224 the outer IP multicast routing process. If the VET node is 1225 configured as a simple outer IP multicast host, the VET interface 1226 instead forwards actual group membership reports (e.g., IGMP 1227 messages) directly over an underlying enterprise-interior interface. 1229 Since inner IP multicast groups are mapped to site-scoped outer IP 1230 multicast groups, the VET node must ensure that the site-scope outer 1231 IP multicast messages received on the enterprise-interior interfaces 1232 for one VET interface do not "leak out" to the enterprise-interior 1233 interfaces of another VET interface. This is accommodated through 1234 normal site-scoped outer IP multicast group filtering at enterprise- 1235 interior interface boundaries. 1237 5.12. Service Discovery 1239 VET nodes can perform enterprise-wide service discovery using a 1240 suitable name-to-address resolution service. Examples of flooding- 1241 based services include the use of LLMNR [RFC4759] over the VET 1242 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1243 underlying enterprise-interior interface. More scalable and 1244 efficient service discovery mechanisms are for further study. 1246 5.13. Enterprise Partitioning 1248 EBGs can physically partition an enterprise by configuring multiple 1249 VET interfaces over multiple distinct sets of underlying interfaces. 1250 In that case, each partition (i.e., each VET interface) must 1251 configure its own distinct 'PRLNAME' (e.g., 1252 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1254 EBGs can logically partition an enterprise using a single VET 1255 interface by sending RAs with PIOs containing different IPv6 PA 1256 prefixes to group nodes into different logical partitions. EBGs can 1257 identify partitions, e.g., by examining RLOC prefixes, observing the 1258 interfaces over which RSs are received, etc. In that case, a single 1259 'PRLNAME' can cover all partitions. 1261 5.14. EBG Prefix State Recovery 1263 EBGs must retain explicit state that tracks the inner IP prefixes 1264 owned by EBRs within the enterprise, e.g., so that packets are 1265 delivered to the correct EBRs and not incorrectly "leaked out" of the 1266 enterprise via a default route. For PA prefixes the state is 1267 maintained via an EBR's DHCP prefix delegation lease renewals, while 1268 for PI prefixes the state is maintained via an EBR's periodic prefix 1269 registration RAs. 1271 When an EBG loses some or all of its state (e.g., due to a power 1272 failure), it must recover the state before allowing packets to flow 1273 over incorrect routes. If the EBG aggregates PA prefixes from which 1274 the IP prefixes of all EBRs in the enterprise are sub-delegated, then 1275 the EBG can recover state through DHCP prefix delegation lease 1276 renewals, through bulk lease queries, or through on-demand name 1277 service lookups based due to IP packet forwarding. If the EBG serves 1278 as an anchor for PI prefixes, however, care must be taken to avoid 1279 looping while state is recovered through prefix registration RAs from 1280 EBRs. In that case, when the EBG that is recovering state forwards 1281 an IP packet for which it has no explicit route other than ::/0, it 1282 must first perform an on-demand name service lookup to refresh state. 1284 6. IANA Considerations 1286 There are no IANA considerations for this document. 1288 7. Security Considerations 1290 Security considerations for MANETs are found in [RFC2501]. 1292 Security considerations with tunneling that apply also to VET are 1293 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1294 that the outer IP source address of a packet received on a VET 1295 interface is correct for the inner IP source address using the 1296 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1297 the ingress filtering mechanisms specified in this document. 1299 SEND [RFC3971], IPsec [RFC4301] and SEAL [I-D.templin-seal] provide 1300 additional securing mitigations to detect source address spoofing and 1301 bogus RA messages sent by rogue routers. 1303 Rogue routers can send bogus RA messages with spoofed RLOC source 1304 addresses that can consume network resources and cause EBGs to 1305 perform extra work. Nonetheless, EBGs should not "blacklist" such 1306 RLOCs, as that may result in a denial of service to the RLOCs' 1307 legitimate owners. 1309 8. Related Work 1311 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1312 automatic tunneling in [RFC2529]; this concept was later called: 1313 "Virtual Ethernet" and investigated by Quang Nguyen under the 1314 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1315 their colleagues have motivated a number of foundational concepts on 1316 which this work is based. 1318 Telcordia has proposed DHCP-related solutions for MANETs through the 1319 CECOM MOSAIC program. 1321 The Naval Research Lab (NRL) Information Technology Division uses 1322 DHCP in their MANET research testbeds. 1324 Security concerns pertaining to tunneling mechanisms are discussed in 1325 [I-D.ietf-v6ops-tunnel-security-concerns]. 1327 Default router and prefix information options for DHCPv6 are 1328 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1330 An automated IPv4 prefix delegation mechanism is proposed in 1331 [I-D.ietf-dhc-subnet-alloc]. 1333 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1334 [I-D.clausen-manet-autoconf-recommendations]. 1336 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1338 Various proposals within the IETF have suggested similar mechanisms. 1340 9. Acknowledgements 1342 The following individuals gave direct and/or indirect input that was 1343 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1344 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1345 Ralph Droms, Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, 1346 Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe 1347 Macker, David Meyer, Thomas Narten, Pekka Nikander, Dave Oran, 1348 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole 1349 Troan, Michaela Vanderveen, Lixia Zhang and others in the IETF 1350 AUTOCONF and MANET working groups. Many others have provided 1351 guidance over the course of many years. 1353 10. Contributors 1355 The following individuals have contributed to this document: 1357 Eric Fleischman (eric.fleischman@boeing.com) 1358 Thomas Henderson (thomas.r.henderson@boeing.com) 1359 Steven Russert (steven.w.russert@boeing.com) 1360 Seung Yi (seung.yi@boeing.com) 1361 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1362 of the document. 1364 Jim Bound's foundational work on enterprise networks provided 1365 significant guidance for this effort. We mourn his loss and honor 1366 his contributions. 1368 11. References 1370 11.1. Normative References 1372 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1373 September 1981. 1375 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1376 RFC 792, September 1981. 1378 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1379 converting network protocol addresses to 48.bit Ethernet 1380 address for transmission on Ethernet hardware", STD 37, 1381 RFC 826, November 1982. 1383 [RFC1035] Mockapetris, P., "Domain names - implementation and 1384 specification", STD 13, RFC 1035, November 1987. 1386 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1387 RFC 2131, March 1997. 1389 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1390 (IPv6) Specification", RFC 2460, December 1998. 1392 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1393 Update", RFC 3007, November 2000. 1395 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1396 and M. Carney, "Dynamic Host Configuration Protocol for 1397 IPv6 (DHCPv6)", RFC 3315, July 2003. 1399 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1400 "DNS Extensions to Support IP Version 6", RFC 3596, 1401 October 2003. 1403 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1404 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1405 December 2003. 1407 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1408 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1410 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1411 RFC 3972, March 2005. 1413 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1414 More-Specific Routes", RFC 4191, November 2005. 1416 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1417 Architecture", RFC 4291, February 2006. 1419 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1420 Message Protocol (ICMPv6) for the Internet Protocol 1421 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1423 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1424 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1425 September 2007. 1427 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1428 Address Autoconfiguration", RFC 4862, September 2007. 1430 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1431 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1432 March 2008. 1434 11.2. Informative References 1436 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1437 Switching Networks", May 1974. 1439 [I-D.cheshire-dnsext-multicastdns] 1440 Cheshire, S. and M. Krochmal, "Multicast DNS", 1441 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1442 September 2008. 1444 [I-D.clausen-manet-autoconf-recommendations] 1445 Clausen, T. and U. Herberg, "MANET Router Configuration 1446 Recommendations", 1447 draft-clausen-manet-autoconf-recommendations-00 (work in 1448 progress), February 2009. 1450 [I-D.clausen-manet-linktype] 1451 Clausen, T., "The MANET Link Type", 1452 draft-clausen-manet-linktype-00 (work in progress), 1453 October 2008. 1455 [I-D.droms-dhc-dhcpv6-default-router] 1456 Droms, R. and T. Narten, "Default Router and Prefix 1457 Advertisement Options for DHCPv6", 1458 draft-droms-dhc-dhcpv6-default-router-00 (work in 1459 progress), March 2009. 1461 [I-D.ietf-autoconf-manetarch] 1462 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1463 Network Architecture", draft-ietf-autoconf-manetarch-07 1464 (work in progress), November 2007. 1466 [I-D.ietf-csi-proxy-send] 1467 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1468 ND Support for SEND", draft-ietf-csi-proxy-send-00 (work 1469 in progress), November 2008. 1471 [I-D.ietf-dhc-subnet-alloc] 1472 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1473 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-09 1474 (work in progress), March 2009. 1476 [I-D.ietf-ipv6-ula-central] 1477 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1478 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1479 progress), June 2007. 1481 [I-D.ietf-manet-smf] 1482 Macker, J. and S. Team, "Simplified Multicast Forwarding 1483 for MANET", draft-ietf-manet-smf-08 (work in progress), 1484 November 2008. 1486 [I-D.ietf-v6ops-tunnel-security-concerns] 1487 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1488 Concerns With IP Tunneling", 1489 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1490 progress), October 2008. 1492 [I-D.jen-apt] 1493 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1494 L. Zhang, "APT: A Practical Transit Mapping Service", 1495 draft-jen-apt-01 (work in progress), November 2007. 1497 [I-D.templin-seal] 1498 Templin, F., "The Subnetwork Encapsulation and Adaptation 1499 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1500 August 2008. 1502 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1503 July 1978. 1505 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1506 Protocol Specification", October 2008. 1508 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1509 Communication Layers", STD 3, RFC 1122, October 1989. 1511 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1512 September 1991. 1514 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1515 Routing and Addressing Architecture", RFC 1753, 1516 December 1994. 1518 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1519 E. Lear, "Address Allocation for Private Internets", 1520 BCP 5, RFC 1918, February 1996. 1522 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1523 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1525 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1526 (MANET): Routing Protocol Performance Issues and 1527 Evaluation Considerations", RFC 2501, January 1999. 1529 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1530 Domains without Explicit Tunnels", RFC 2529, March 1999. 1532 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1533 February 2000. 1535 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1536 via IPv4 Clouds", RFC 3056, February 2001. 1538 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1539 Networks", BCP 84, RFC 3704, March 2004. 1541 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1542 RFC 3753, June 2004. 1544 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1545 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1546 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1547 RFC 3819, July 2004. 1549 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1550 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1551 May 2005. 1553 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1554 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1555 September 2005. 1557 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1558 Addresses", RFC 4193, October 2005. 1560 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1561 Internet Protocol", RFC 4301, December 2005. 1563 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1564 Network Address Translations (NATs)", RFC 4380, 1565 February 2006. 1567 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1568 Proxies (ND Proxy)", RFC 4389, April 2006. 1570 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1571 Indicator Parameter for the "tel" URI", RFC 4759, 1572 December 2006. 1574 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1575 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1576 Focus", RFC 4852, April 2007. 1578 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1579 June 2007. 1581 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1582 Extensions for Stateless Address Autoconfiguration in 1583 IPv6", RFC 4941, September 2007. 1585 Appendix A. Duplicate Address Detection (DAD) Considerations 1587 A-priori uniqueness determination (also known as "pre-service DAD") 1588 for an RLOC assigned on an enterprise-interior interface would 1589 require either flooding the entire enterprise or somehow discovering 1590 a link in the enterprise on which a node that configures a duplicate 1591 address is attached and performing a localized DAD exchange on that 1592 link. But, the control message overhead for such an enterprise-wide 1593 DAD would be substantial and prone to false-negatives due to packet 1594 loss and intermittent connectivity. An alternative to pre-service 1595 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1596 interfaces and employ a passive in-service DAD (e.g., one that 1597 monitors routing protocol messages for duplicate assignments). 1599 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1600 CGAs, IPv6 privacy addresses, etc. with very small probability of 1601 collision. Pseudo-random IPv4 RLOCs can be generated through random 1602 assignment from a suitably large IPv4 prefix space. 1604 Consistent operational practices can assure uniqueness for EBG- 1605 aggregated addresses/prefixes, while statistical properties for 1606 pseudo-random address self-generation can assure uniqueness for the 1607 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1608 RLOC delegation authority should be used when available, while a 1609 passive in-service DAD mechanism should be used to detect RLOC 1610 duplications when there is no RLOC delegation authority. 1612 Appendix B. Change Log 1614 (Note to RFC editor - this section to be removed before publication 1615 as an RFC.) 1617 Changes from -35 to 36: 1619 o DHCP updates 1621 Changes from -34 to 35: 1623 o Introduced EID and RLOC terminology 1625 o RLOC-based prefix delegation 1627 Changes from -33 to 34: 1629 o Enterprise management models described 1631 o Enterprise security models described 1633 o Clarification of mechanisms based on enterprise management/ 1634 security models 1636 Changes from -32 to 33:: 1638 o Secure Neighbor Discovery Proxy 1640 Changes from -28 to 29: 1642 o Updates on processing/receiving errors. 1644 Changes from -27 to 28: 1646 o Introduced concept of a default mapper. 1648 Changes from -26 to 27: 1650 o Introduced new model for PI prefix management. 1652 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1653 "isado"?) 1655 Changes from -25 to 26: 1657 o Clarifications on Router Discovery and Ingress FIltering. 1659 o Mechanisms for detecting locator liveness 1661 o Mechanisms for avoiding state synchonization requirements. 1663 Changes from -23 to 24: 1665 o Clarifications on router discovery. 1667 Changes from -22 to 23: 1669 o Clarifications on prefix mapping. 1671 Changes from -21 to 22: 1673 o Using SEAL to secure VET 1675 Changes from -20 to 21: 1677 o Enterprise partitioning. 1679 o Mapping and name service management. 1681 Changes from -18 to 20: 1683 o Added support for simple hosts. 1685 o Added EBG name service maintenace procedures 1687 o Added router and prefix maintenace procedures 1689 Changes from -17 to 18: 1691 o adjusted section headings to group autoconf operations under EIR/ 1692 EBR/EBG. 1694 o clarified M/O bits 1696 o clarified EBG roles 1698 Changes from -15 to 17: 1700 o title change to "Virtual Enterprise Traversal (VET)". 1702 o changed document focus from MANET-centric to the much-broader 1703 Enterprise-centric, where "Enterprise" is understood to also cover 1704 a wide range of MANET types. 1706 Changes from -14 to 15: 1708 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1710 o Address review comments 1712 Changes from -12 to 14: 1714 o title change to "The MANET Virtual Ethernet Abstraction". 1716 o Minor section rearrangement. 1718 o Clartifications on portable and self-configured prefixes. 1720 o Clarifications on DHCPv6 prefix delegation procedures. 1722 Changes from -11 to 12: 1724 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1726 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1727 delegation mechanism. 1729 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1731 o fixed editorials based on comments received. 1733 Changes from -10 to 11: 1735 o removed the transparent/opaque VET portal abstractions. 1737 o removed routing header as an option for MANET exit router 1738 selection. 1740 o included IPv6 SLAAC as an endorsed address configuration mechanism 1741 for the VET interface. 1743 Changes from -08 to -09: 1745 o Introduced the term "VET". 1747 o Changed address delegation language to speak of "MNBR-aggregated" 1748 instead of global/local. 1750 o Updated figures 1-3. 1752 o Explained why a MANET interface is "neutral". 1754 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1755 DHCPv4 servers; not relays. 1757 Changes from -07 to -08: 1759 o changed terms "unenhanced" and "enhanced" to "transparent" and 1760 "opaque". 1762 o revised MANET Router diagram. 1764 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1765 interface. 1767 o changed abbreviations to "MNR" and "MNBR". 1769 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1771 o rearranged Section 3.1. 1773 o various minor text cleanups 1775 Changes from -06 to -07: 1777 o added MANET Router diagram. 1779 o added new references 1781 o various minor text cleanups 1783 Changed from -05 to -06: 1785 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1787 o minor changes to preserve generality 1789 Changed from -04 to -05: 1791 o introduced conceptual "virtual ethernet" model. 1793 o support "raw" and "cooked" modes as equivalent access methods on 1794 the virutal ethernet. 1796 Changed from -03 to -04: 1798 o introduced conceptual "imaginary shared link" as a representation 1799 for a MANET. 1801 o discussion of autonomous system and site abstractions for MANETs 1803 o discussion of autoconfiguration of CGAs 1805 o new appendix on IPv6 StateLess Address AutoConfiguration 1807 Changes from -02 to -03: 1809 o updated terminology based on RFC2461 "asymmetric reachability" 1810 link type; IETF67 MANET Autoconf wg discussions. 1812 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1813 Address Detection 1815 o relaxed DHCP server deployment considerations allow DHCP servers 1816 within the MANET itself 1818 Changes from -01 to -02: 1820 o minor updates for consistency with recent developments 1822 Changes from -00 to -01: 1824 o new text on DHCPv6 prefix delegation and multilink subnet 1825 considerations. 1827 o various editorial changes 1829 Author's Address 1831 Fred L. Templin (editor) 1832 Boeing Research and Technology 1833 P.O. Box 3707 MC 7L-49 1834 Seattle, WA 98124 1835 USA 1837 Email: fltemplin@acm.org