idnits 2.17.1 draft-templin-intarea-vet-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 866: '...n each RA, but it MUST NOT include any...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2010) is 5213 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1035' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: 'RFC3007' is defined on line 1501, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 1508, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1575, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-dhcpv6-agentopt-delegate' is defined on line 1585, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1673, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1679, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-08 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** 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) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-08 == Outdated reference: A later version (-02) exists of draft-hain-ipv6-ulac-01 == Outdated reference: A later version (-05) exists of draft-ietf-csi-proxy-send-01 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-04 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-10 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-09 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 == Outdated reference: A later version (-03) exists of draft-nakibly-v6ops-tunnel-loops-00 == Outdated reference: A later version (-05) exists of draft-russert-rangers-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 7 errors (**), 0 flaws (~~), 20 warnings (==), 3 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 & Technology 4 Intended status: Standards Track January 14, 2010 5 Expires: July 18, 2010 7 Virtual Enterprise Traversal (VET) 8 draft-templin-intarea-vet-06.txt 10 Abstract 12 Enterprise networks connect hosts and routers over various link 13 types, and may also connect to provider networks and/or the global 14 Internet. Enterprise network nodes require a means to automatically 15 provision IP addresses/prefixes and support internetworking operation 16 in a wide variety of use cases including Small Office, Home Office 17 (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, 18 multi-organizational corporate networks and the interdomain core of 19 the global Internet itself. This document specifies a Virtual 20 Enterprise Traversal (VET) abstraction for autoconfiguration and 21 operation of nodes in enterprise networks. VET can also be 22 considered as version 2 of the Intra-Site Automatic Tunnel Addressing 23 Protocol (i.e., "ISATAPv2"). 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on July 18, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 11 67 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Enterprise Router (ER) Autoconfiguration . . . . . . . . . 12 69 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 14 70 4.2.1. VET Interface Initialization . . . . . . . . . . . . . 14 71 4.2.2. PRL Discovery and Enterprise Identification . . . . . 15 72 4.2.3. Provider-Aggregated (PA) EID Prefix 73 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 74 4.2.4. Provider-Independent (PI) EID Prefix 75 Autoconfiguration . . . . . . . . . . . . . . . . . . 17 76 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 17 77 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 18 78 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 18 79 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 19 80 5.2. Address Selection . . . . . . . . . . . . . . . . . . . . 19 81 5.3. VET interface Neighbor Discovery . . . . . . . . . . . . . 19 82 5.3.1. Router and Prefix Discovery . . . . . . . . . . . . . 20 83 5.3.2. Next Hop Determination . . . . . . . . . . . . . . . . 22 84 5.3.3. Redirect Function . . . . . . . . . . . . . . . . . . 23 85 5.3.4. Neighbor Unreachability Detection . . . . . . . . . . 24 86 5.3.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 25 87 5.3.6. IPv4 Neighbor Discovery . . . . . . . . . . . . . . . 25 88 5.4. Generating Errors . . . . . . . . . . . . . . . . . . . . 25 89 5.5. Processing Errors . . . . . . . . . . . . . . . . . . . . 26 90 5.6. Mobility and Multihoming Considerations . . . . . . . . . 27 91 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28 92 5.8. Service Discovery . . . . . . . . . . . . . . . . . . . . 29 93 5.9. Enterprise Partitioning . . . . . . . . . . . . . . . . . 29 94 5.10. EBG Prefix State Recovery . . . . . . . . . . . . . . . . 29 95 5.11. Support for Legacy ISATAP Services . . . . . . . . . . . . 29 96 5.12. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 29 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 99 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 101 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 105 Appendix A. Duplicate Address Detection (DAD) Considerations . . 38 106 Appendix B. Link-Layer Multiplexing and Traffic Engineering . . . 39 107 Appendix C. Anycast Services . . . . . . . . . . . . . . . . . . 41 108 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 42 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 111 1. Introduction 113 Enterprise networks [RFC4852] connect hosts and routers over various 114 link types (see [RFC4861], Section 2.2). The term "enterprise 115 network" in this context extends to a wide variety of use cases and 116 deployment scenarios. For example, an "enterprise" can be as small 117 as a SOHO network, as complex as a multi-organizational corporation, 118 or as large as the global Internet itself. ISP networks are another 119 example use case that fits well with the VET enterprise network 120 model. Mobile Ad hoc Networks (MANETs) [RFC2501] can also be 121 considered as a challenging example of an enterprise network, in that 122 their topologies may change dynamically over time and that they may 123 employ little/no active management by a centralized network 124 administrative authority. These specialized characteristics for 125 MANETs require careful consideration, but the same principles apply 126 equally to other enterprise network scenarios. 128 This document specifies a Virtual Enterprise Traversal (VET) 129 abstraction for autoconfiguration and internetworking operation, 130 where addresses of different scopes may be assigned on various types 131 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 132 [RFC2460] are discussed within this context. The use of standard 133 DHCP [RFC2131] [RFC3315] and neighbor discovery [RFC0826] [RFC1256] 134 [RFC4861] mechanisms is assumed unless otherwise specified. 136 Provider-Edge Interfaces 137 x x x 138 | | | 139 +--------------------+---+--------+----------+ E 140 | | | | | n 141 | I | | .... | | t 142 | n +---+---+--------+---+ | e 143 | t | +--------+ /| | r 144 | e I x----+ | Host | I /*+------+--< p I 145 | r n | |Function| n|**| | r n 146 | n t | +--------+ t|**| | i t 147 | a e x----+ V e|**+------+--< s e 148 | l r . | E r|**| . | e r 149 | f . | T f|**| . | f 150 | V a . | +--------+ a|**| . | I a 151 | i c . | | Router | c|**| . | n c 152 | r e x----+ |Function| e \*+------+--< t e 153 | t s | +--------+ \| | e s 154 | u +---+---+--------+---+ | r 155 | a | | .... | | i 156 | l | | | | o 157 +--------------------+---+--------+----------+ r 158 | | | 159 x x x 160 Enterprise-Edge Interfaces 162 Figure 1: Enterprise Router (ER) Architecture 164 Figure 1 above depicts the architectural model for an Enterprise 165 Router (ER). As shown in the figure, an ER may have a variety of 166 interface types including enterprise-edge, enterprise-interior, 167 provider-edge, internal-virtual, as well as VET interfaces used for 168 IP in IP encapsulation. The different types of interfaces are 169 defined, and the autoconfiguration mechanisms used for each type are 170 specified. This architecture applies equally for MANET routers, in 171 which enterprise-interior interfaces correspond to the wireless 172 multihop radio interfaces typically associated with MANETs. Out of 173 scope for this document is the autoconfiguration of provider 174 interfaces, which must be coordinated in a manner specific to the 175 service provider's network. 177 Enterprise networks must have a means for supporting both Provider- 178 Independent (PI) and Provider-Aggregated (PA) addressing. This is 179 especially true for enterprise scenarios that involve mobility and 180 multihoming. Also in scope are ingress filtering for multihomed 181 sites, adaptation based on authenticated ICMP feedback from on-path 182 routers, effective tunnel path MTU mitigations, and routing scaling 183 suppression as required in many enterprise network scenarios. The 184 VET specification provides adaptable mechanisms that address these 185 and other issues in a wide variety of enterprise network use cases. 187 VET represents a functional superset of 6over4 [RFC2529] and the 188 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], 189 and can be considered as version 2 of the ISATAP protocol (i.e., 190 "ISATAPv2"). VET works in conjunction with the Subnetwork 191 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal], 192 and is also compatible with additional encapsulations such as IPsec 193 [RFC4301]. VET further defines mechanisms that are very similar in 194 nature to those specified for IPv6 operation over Non-Broadcast 195 Multiple Access (NBMA) networks [RFC2491]. 197 VET and its associated technologies serve as functional building 198 blocks for a new Internetworking architecture known as Routing and 199 Addressing in Next Generation EnteRprises [I-D.templin-ranger] 200 [I-D.russert-rangers]. The VET principles can be either directly or 201 indirectly traced to the deliberations of the ROAD group in January 202 1992, and also to still earlier works including NIMROD [RFC1753] and 203 the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. 204 [RFC1955] captures the high-level architectural aspects of the ROAD 205 group deliberations in a "New Scheme for Internet Routing and 206 Addressing (ENCAPS) for IPNG". 208 VET is related to the present-day activities of the IETF INTAREA, 209 AUTOCONF, DHC, IPv6, MANET, and V6OPS working groups, as well as the 210 IRTF RRG working group. 212 2. Terminology 214 The mechanisms within this document build upon the fundamental 215 principles of IP in IP encapsulation. The terms "inner" and "outer" 216 are used to, respectively, refer to the innermost IP {address, 217 protocol, header, packet, etc.} *before* encapsulation, and the 218 outermost IP {address, protocol, header, packet, etc.} *after* 219 encapsulation. VET also uses the Subnetwork Encapsulation and 220 Adaptation Layer (SEAL) [I-D.templin-intarea-seal] as a "mid-layer" 221 encapsulation between the inner and outer IP headers, and also allows 222 for inclusion of other mid-layer encapsulations including IPSec 223 [RFC4301]. 225 The terminology in the normative references apply; the following 226 terms are defined within the scope of this document: 228 Virtual Enterprise Traversal (VET) 229 an abstraction that uses IP in IP encapsulation to create overlays 230 for traversing enterprise networks. VET can be considered as 231 version 2 of the ISATAP protocol (i.e., "ISATAPv2"). 233 enterprise 234 the same as defined in [RFC4852]. An enterprise is also 235 understood to refer to a cooperative networked collective of 236 devices within a common IP routing and addressing region and with 237 a commonality of business, social, political, etc., interests. 238 Minimally, the only commonality of interest in some enterprise 239 network scenarios may be the cooperative provisioning of 240 connectivity itself. 242 subnetwork 243 the same as defined in [RFC3819]. 245 site 246 a logical and/or physical grouping of interfaces that connect a 247 topological area less than or equal to an enterprise in scope. A 248 site within an enterprise can, in some sense, be considered as an 249 enterprise unto itself. 251 Mobile Ad hoc Network (MANET) 252 a connected topology of mobile or fixed routers that maintain a 253 routing structure among themselves over dynamic links. The 254 characteristics of MANETs are defined in [RFC2501], Section 3, and 255 a wide variety of MANETs share common properties with enterprise 256 networks. 258 enterprise/site/MANET 259 throughout the remainder of this document, the term "enterprise" 260 is used to collectively refer to any of {enterprise, site, MANET}, 261 i.e., the VET mechanisms and operational principles can be applied 262 to enterprises, sites, and MANETs of any size or shape. 264 Enterprise Router (ER) 265 As depicted in Figure 1, an Enterprise Router (ER) is a fixed or 266 mobile router that comprises a router function, a host function, 267 one or more enterprise-interior interfaces, and zero or more 268 internal virtual, enterprise-edge, provider-edge, and VET 269 interfaces. At a minimum, an ER forwards outer IP packets over 270 one or more sets of enterprise-interior interfaces, where each set 271 connects to a distinct enterprise. 273 Enterprise Border Router (EBR) 274 an ER that connects edge networks to the enterprise and/or 275 connects multiple enterprises together. An EBR is a tunnel 276 endpoint router, and it configures a separate VET interface over 277 each set of enterprise-interior interfaces that connect the EBR to 278 each distinct enterprise. In particular, an EBR may configure 279 multiple VET interfaces - one for each distinct enterprise. All 280 EBRs are also ERs. 282 Enterprise Border Gateway (EBG) 283 an EBR that connects VET interfaces configured over child 284 enterprises to a provider network - either directly via a 285 provider-edge interface or indirectly via another VET interface 286 configured over a parent enterprise. EBRs may act as EBGs on some 287 VET interfaces and as ordinary EBRs on other VET interfaces. All 288 EBGs are also EBRs. 290 VET host 291 any node (host or router) that configures a VET interface for 292 host-operation only. Note that a node may configure some of its 293 VET interfaces as host interfaces and others as router interfaces. 295 VET node 296 any node (host or router) that configures and uses a VET 297 interface. 299 enterprise-interior interface 300 an ER's attachment to a link within an enterprise. Packets sent 301 over enterprise-interior interfaces may be forwarded over multiple 302 additional enterprise-interior interfaces within the enterprise 303 before they are forwarded via an enterprise-edge interface, 304 provider-edge interface, or a VET interface configured over a 305 different enterprise. Enterprise-interior interfaces connect 306 laterally within the IP network hierarchy. 308 enterprise-edge interface 309 an EBR's attachment to a link (e.g., an Ethernet, a wireless 310 personal area network, etc.) on an arbitrarily complex edge 311 network that the EBR connects to an enterprise and/or provider 312 network. Enterprise-edge interfaces connect to lower levels 313 within the IP network hierarchy. 315 provider-edge interface 316 an EBR's attachment to the Internet or to a provider network 317 outside of the enterprise via which the Internet can be reached. 318 Provider-edge interfaces connect to higher levels within the IP 319 network hierarchy. 321 internal-virtual interface 322 an interface that is internal to an EBR and does not in itself 323 directly attach to a tangible physical link, e.g., an Ethernet 324 cable. Examples include a loopback interface, a virtual private 325 network interface, or some form of tunnel interface. 327 VET link 328 a virtual link that uses automatic tunneling to create an overlay 329 network that spans an enterprise-interior routing region. VET 330 links can be segmented (e.g., by IP in IP protocol filtering 331 gateways) into multiple distinct segments that can be joined 332 together by bridges or IP routers the same as for any link. 333 Bridging would view the multiple (bridged) segments as a single 334 VET link, whereas IP routing would view the multiple segments as 335 multiple distinct VET links. VET link segments can further be 336 partitioned into multiple logical areas, where each area is 337 identified by a distinct set of EBGs. 339 VET links in non-multicast enterprises are Non-Broadcast, Multiple 340 Access (NBMA); VET links in enterprises that support multicast are 341 multicast capable. 343 VET interface 344 a VET node's attachment to a VET link. VET nodes configure each 345 VET interface over a set of underlying interfaces that connect to 346 an enterprise-interior routing region spanned by a single VET 347 link. When there are multiple distinct VET links (each with their 348 own distinct set of underlying interfaces), the VET node 349 configures separate VET interfaces for each link. 351 The VET interface encapsulates each inner IP packet in any mid- 352 layer headers followed by an outer IP header, then forwards the 353 packet on an underlying interface such that the Time to Live (TTL) 354 - Hop Limit in the inner header is not decremented as the packet 355 traverses the link. The VET interface therefore presents an 356 automatic tunneling abstraction that represents the link as a 357 single IP hop. 359 VET address 360 an IPv6 address assigned to a VET interface that embeds an IPv4 361 address within the IPv6 address interface identifier. VET 362 addresses are formed exactly as specified for ISATAP addresses in 363 Sections 6.1 and 6.2 of [RFC5214]. 365 Provider-Independent (PI) prefix 366 an IPv6 prefix (e.g., 2001:DB8::/48) or IPv4 prefix (e.g., 367 192.0.2/24) that is either self-generated by an EBR or delegated 368 to an EBR by a registry. 370 Provider Aggregated (PA) prefix 371 an IPv6 or IPv4 prefix that is delegated to an EBR by a provider 372 network. 374 Routing Locator (RLOC) 375 a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix 376 that can appear in enterprise-interior and/or interdomain routing 377 tables. Global-scope RLOC prefixes are delegated to specific 378 enterprises and routable within both the enterprise-interior and 379 interdomain routing regions. Enterprise-local-scope RLOC prefixes 380 (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 privacy 381 addresses [RFC1918], etc.) are self-generated by individual 382 enterprises and routable only within the enterprise-interior 383 routing region. 385 ERs use RLOCs for operating the enterprise-interior routing 386 protocol and for next-hop determination in forwarding packets 387 addressed to other RLOCs. End systems use RLOCs as addresses for 388 end-to-end communications between peers within the same 389 enterprise. VET interfaces treat RLOCs as *outer* IP addresses 390 during IP in IP encapsulation. 392 Endpoint Interface iDentifier (EID) 393 an IPv4 or IPv6 address taken from a PI/PA prefix that is routable 394 within an enterprise-edge or VET overlay network scope, and may 395 also appear in enterprise-interior and/or interdomain mapping 396 tables. EID prefixes are separate and distinct from any RLOC 397 prefix space. 399 Edge network routers use EIDs for operating the enterprise-edge or 400 VET overlay network routing protocol and for next-hop 401 determination in forwarding packets addressed to other EIDs. End 402 systems use EIDs as addresses for end-to-end communications 403 between peers either within the same enterprise or within 404 different enterprises. VET interfaces treat EIDs as *inner* IP 405 addresses during IP in IP encapsulation. 407 The following additional acronyms are used throughout the document: 409 CGA - Cryptographically Generated Address 410 DHCP(v4, v6) - Dynamic Host Configuration Protocol 411 FIB - Forwarding Information Base 412 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 413 NBMA - Non-Broadcast, Multiple Access 414 ND - Neighbor Discovery 415 PIO - Prefix Information Option 416 PRL - Potential Router List 417 PRLNAME - Identifying name for the PRL (default is "isatapv2") 418 RIO - Route Information Option 419 RPF - Reverse Path Forwarding 420 RS/RA - IPv6 ND Router Solicitation/Advertisement 421 SEAL - Subnetwork Encapsulation and Adaptation Layer 422 SLAAC - IPv6 StateLess Address AutoConfiguation 424 3. Enterprise Characteristics 426 Enterprises consist of links that are connected by Enterprise Routers 427 (ERs) as depicted in Figure 1. ERs typically participate in a 428 routing protocol over enterprise-interior interfaces to discover 429 routes that may include multiple Layer 2 or Layer 3 forwarding hops. 430 Enterprise Border Routers (EBRs) are ERs that connect edge networks 431 to the enterprise and/or join multiple enterprises together. 432 Enterprise Border Gateways (EBGs) are EBRs that connect enterprises 433 to provider networks. 435 Conceptually, an ER embodies both a host function and router 436 function. The host function supports Endpoint Interface iDentifier 437 (EID)-based and/or Routing LOCator (RLOC)-based communications 438 according to the weak end-system model [RFC1122]. The router 439 function engages in the enterprise-interior routing protocol, 440 connects any of the ER's edge networks to the enterprise, and may 441 also connect the enterprise to provider networks (see Figure 1). 443 An enterprise may be as simple as a small collection of ERs and their 444 attached edge networks; an enterprise may also contain other 445 enterprises and/or be a subnetwork of a larger enterprise. An 446 enterprise may further encompass a set of branch offices and/or 447 nomadic hosts connected to a home office over one or several service 448 providers, e.g., through Virtual Private Network (VPN) tunnels. 449 Finally, an enterprise may contain many internal partitions that are 450 logical or physical groupings of nodes for the purpose of load 451 balancing, organizational separation, etc. In that case, each 452 internal partition resembles an individual segment of a bridged LAN. 454 Enterprises that comprise link types with sufficiently similar 455 properties (e.g., Layer 2 (L2) address formats, maximum transmission 456 units (MTUs), etc.) can configure a sub-IP layer routing service such 457 that IP sees the enterprise as an ordinary shared link the same as 458 for a (bridged) campus LAN. In that case, a single IP hop is 459 sufficient to traverse the enterprise without IP layer encapsulation. 460 Enterprises that comprise link types with diverse properties and/or 461 configure multiple IP subnets must also provide an enterprise- 462 interior routing service that operates as an IP layer mechanism. In 463 that case, multiple IP hops may be necessary to traverse the 464 enterprise such that care must be taken to avoid multi-link subnet 465 issues [RFC4903]. 467 In addition to other interface types, VET nodes configure VET 468 interfaces that view all other nodes on the VET link as single-hop 469 neighbors. VET nodes configure a separate VET interface for each 470 distinct VET link to which they connect, and discover other EBRs on 471 the link that can be used for forwarding packets to off-link 472 destinations. 474 For each distinct enterprise, an enterprise trust basis must be 475 established and consistently applied. For example, in enterprises in 476 which EBRs establish symmetric security associations, mechanisms such 477 as IPsec [RFC4301] can be used to assure authentication and 478 confidentiality. In other enterprise network scenarios, asymmetric 479 securing mechanisms such as SEcure Neighbor Discovery (SEND) 480 [RFC3971] may be necessary to authenticate exchanges based on trust 481 anchors. Still other enterprises may have sufficient infrastructure 482 trust basis (e.g., through proper deployment of filtering gateways at 483 enterprise borders) and may not require nodes to implement such 484 additional mechanisms. 486 Finally, in enterprises with a centralized management structure 487 (e.g., a corporate campus network), an enterprise mapping service and 488 a synchronized set of EBGs can provide sufficient infrastructure 489 support for virtual enterprise traversal. In that case, the EBGs can 490 provide a "default mapper" [I-D.jen-apt] service used for short-term 491 packet forwarding until EBR neighbor relationships can be 492 established. In enterprises with a distributed management structure 493 (e.g., MANETs), peer-to-peer coordination between the EBRs themselves 494 may be required. Recognizing that various use cases will entail a 495 continuum between a fully distributed and fully centralized approach, 496 the following sections present the mechanisms of Virtual Enterprise 497 Traversal as they apply to a wide variety of scenarios. 499 4. Autoconfiguration 501 ERs, EBRs, EBGs, and VET hosts configure themselves for operation as 502 specified in the following subsections. 504 4.1. Enterprise Router (ER) Autoconfiguration 506 ERs configure enterprise-interior interfaces and engage in any 507 routing protocols over those interfaces. 509 When an ER joins an enterprise, it first configures an IPv6 link- 510 local address on each enterprise-interior interface and configures an 511 IPv4 link-local address on each enterprise-interior interface that 512 requires an IPv4 link-local capability. IPv6 link-local address 513 generation mechanisms include Cryptographically Generated Addresses 514 (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address 515 AutoConfiguration (SLAAC) using EUI-64 interface identifiers 516 [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] 517 provide an IPv4 link-local address generation capability. 519 Next, the ER configures one or more RLOCs and engages in any routing 520 protocols on its enterprise-interior interfaces. The ER can 521 configure RLOCs via explicit management, DHCP autoconfiguration, 522 pseudo-random self-generation from a suitably large address pool, or 523 through an alternate autoconfiguration mechanism. The ER may 524 optionally configure and assign a separate RLOC for each underlying 525 interface, or it may configure only a single RLOC and assign it to a 526 VET interface configured over the underlying interfaces (see Section 527 4.2.1). In the latter case, the ER can use the VET interface for 528 link layer multiplexing and traffic engineering purposes as specified 529 in Appendix B. 531 Alternatively (or in addition), the ER can request RLOC prefix 532 delegations via an automated prefix delegation exchange over an 533 enterprise-interior interface and can assign the prefix(es) on 534 enterprise-edge interfaces. Note that in some cases, the same 535 enterprise-edge interfaces may assign both RLOC and EID addresses if 536 there is a means for source address selection. In other cases (e.g., 537 for separation of security domains), RLOCs and EIDs must be assigned 538 on separate sets of enterprise-edge interfaces. 540 Self-generation of RLOCs for IPv6 can be from a large public or 541 local-use IPv6 address range (e.g., IPv6 Unique Local Addresses 542 [RFC4193]). Self-generation of RLOCs for IPv4 can be from a large 543 public or local-use IPv4 address range (e.g., [RFC1918]). When self- 544 generation is used alone, the ER must continuously monitor the RLOCs 545 for uniqueness, e.g., by monitoring the enterprise-interior routing 546 protocol. 548 DHCP generation of RLOCs may require support from relays within the 549 enterprise. For DHCPv6, relays that do not already know the RLOC of 550 a server within the enterprise forward requests to the 551 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For 552 DHCPv4, relays that do not already know the RLOC of a server within 553 the enterprise forward requests to the site-scoped IPv4 multicast 554 group address 'All_DHCPv4_Servers', which should be set to 555 239.255.2.1 unless an alternate multicast group for the site is 556 known. DHCPv4 servers that delegate RLOCs should therefore join the 557 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 558 received for that group. 560 A combined approach using both DHCP and self-generation is also 561 possible when the ER configures both a DHCP client and relay that are 562 connected, e.g., via a pair of back-to-back connected Ethernet 563 interfaces, a tun/tap interface, a loopback interface, inter-process 564 communication, etc. The ER first self-generates a temporary RLOC 565 used only for the purpose of procuring an actual RLOC taken from a 566 disjoint addressing range. The ER then engages in the enterprise- 567 interior routing protocol and performs a DHCP client/relay exchange 568 using the temporary RLOC as the address of the relay. When the DHCP 569 server delegates an actual RLOC address/prefix, the ER abandons the 570 temporary RLOC and re-engages in the enterprise-interior routing 571 protocol using an RLOC taken from the delegation. 573 In some enterprise use cases (e.g., MANETs), assignment of RLOCs on 574 enterprise-interior interfaces as singleton addresses (i.e., as 575 addresses with /32 prefix lengths for IPv4, or as addresses with /128 576 prefix lengths for IPv6) may be necessary to avoid multi-link subnet 577 issues. In other use cases, assignment of an RLOC on a VET interface 578 as specified in Appendix B can provide link layer multiplexing and 579 traffic engineering over multiple underlying interfaces using only a 580 single IP address. 582 4.2. Enterprise Border Router (EBR) Autoconfiguration 584 EBRs are ERs that configure VET interfaces over distinct sets of 585 underlying interfaces belonging to the same enterprise; an EBR can 586 connect to multiple enterprises, in which case it would configure 587 multiple VET interfaces. In addition to the ER autoconfiguration 588 procedures specified in Section 4.1, EBRs perform the following 589 autoconfiguration operations. 591 4.2.1. VET Interface Initialization 593 EBRs configure a VET interface over a set of underlying interfaces 594 belonging to the same enterprise such that all other VET nodes in the 595 enterprise appear as single-hop neighbors through the use of IP in IP 596 encapsulation. After the EBR configures a VET interface, it 597 initializes the interface and assigns an IPv6 link-local address and 598 an IPv4 link-local address if necessary. The EBR also associates an 599 RLOC obtained as specified in Section 4.1 with the VET interface to 600 serve as the source address for outer IP packets. 602 When IPv6 and IPv4 are used as the inner/outer protocols 603 (respectively), the EBR autoconfigures an IPv6 link-local VET address 604 on the VET interface to support packet forwarding and operation of 605 the IPv6 neighbor discovery protocol. The link-local VET address is 606 formed exactly as specified in Sections 6.1 and 6.2 of [RFC5214]. 607 The link-local address need not be checked for uniqueness since the 608 IPv4 RLOC embedded in the address itself is managed for uniqueness 609 (see Section 4.1). 611 Link-local address configuration for other inner/outer IP protocol 612 combinations is through administrative configuration or through an 613 unspecified alternate method. However, link-local address 614 configuration for other inner/outer IP protocol combinations may not 615 be necessary if a non-link-local address can be configured through 616 other means (e.g., administrative configuration, DHCP, etc.). 618 After the EBR initializes a VET interface, it can communicate with 619 other VET nodes as single-hop neighbors on the VET link from the 620 viewpoint of the inner IP protocol. The EBR can also configure the 621 VET interface for link-layer multiplexing and traffic engineering 622 purposes as specified in Appendix B. 624 4.2.2. PRL Discovery and Enterprise Identification 626 Following VET interface initialization, the EBR next discovers a 627 Potential Router List (PRL) used to track the RLOC addresses of EBGs. 628 The PRL can be discovered through information conveyed in the 629 enterprise-interior routing protocol, through the mechanisms outlined 630 in Section 8.3.2 of [RFC5214], through a DHCP option 631 [I-D.templin-isatap-dhcp], etc. In multicast-capable enterprises, 632 EBRs can also listen for advertisements on the 'rasadv' [RASADV] 633 multicast group address. 635 Whether or not routing information is available, the EBR can discover 636 the list of EBGs by resolving an identifying name for the PRL 637 ('PRLNAME') formed as 'hostname.domainname', where 'hostname' is an 638 enterprise-specific name string and 'domainname' is an enterprise- 639 specific DNS suffix. The EBR discovers 'PRLNAME' through manual 640 configuration, the DHCP Domain Name option [RFC2132], 'rasadv' 641 protocol advertisements, link-layer information (e.g., an IEEE 802.11 642 Service Set Identifier (SSID)), or through some other means specific 643 to the enterprise. 645 In the absence of other information, the EBR sets the 'hostname' 646 component of 'PRLNAME' to "isatapv2" and sets the 'domainname' 647 component to the enterprise-specific DNS suffix "example.com" (e.g., 648 as "isatapv2.example.com"). Note that this naming convention is 649 intentionally distinct from the convention specified in [RFC5214], 650 and is used by the EBR to distinguish between ISATAP and VET virtual 651 interfaces. 653 The global Internet interdomain routing core represents a specific 654 example of an enterprise network scenario, albeit on an enormous 655 scale. The 'PRLNAME' assigned to the global Internet interdomain 656 routing core is "isatapv2.net". Isolated enterprise networks that do 657 not connect to the outside world may have no enterprise-specific DNS 658 suffix. In that case, the 'PRLNAME' consists only of the 'hostname' 659 component (e.g., "isatapv2"). 661 After discovering 'PRLNAME', the EBR resolves the name into a list of 662 RLOC addresses through a name service lookup. For centrally managed 663 enterprises, the EBR resolves 'PRLNAME' using an enterprise-local 664 name service (e.g., the DNS). For enterprises with a distributed 665 management structure, the EBR resolves 'PRLNAME' using Link-Local 666 Multicast Name Resolution (LLMNR) [RFC4795] over the VET interface. 667 In that case, all EBGs in the PRL respond to the LLMNR query, and the 668 EBR accepts the union of all responses. 670 Each distinct enterprise must have a unique identity that EBRs can 671 use to uniquely discern their enterprise affiliations. 'PRLNAME' as 672 well as the RLOCs of EBGs in the PRL serve as an identifier for the 673 enterprise. 675 4.2.3. Provider-Aggregated (PA) EID Prefix Autoconfiguration 677 EBRs can acquire Provider-Aggregated (PA) EID prefixes through 678 autoconfiguration exchanges with EBGs over VET interfaces, where each 679 EBG may be configured as either a DHCP relay or DHCP server. 681 For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix 682 delegation exchange, explicit management, etc. 684 For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation 685 exchanges. In particular, the EBR (acting as a requesting router) 686 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 687 obtain IPv6 EID prefixes from the server (acting as a delegating 688 router). 690 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 691 exchange [RFC3315]. For example, to perform the 2-message exchange, 692 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 693 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 694 relay (see Section 4.1). The relay then forwards the message over 695 the VET interface to an EBG, which either services the request or 696 relays it further. The forwarded Solicit message will elicit a reply 697 from the server containing PA IPv6 prefix delegations. 699 The EBR can also propose a specific prefix to the DHCPv6 server per 700 Section 7 of [RFC3633]. The server will check the proposed prefix 701 for consistency and uniqueness, then return it in the reply to the 702 EBR if it was able to perform the delegation. 704 After the EBR receives PA prefix delegations, it can provision the 705 prefixes on enterprise-edge interfaces as well as on other VET 706 interfaces for which it is configured as an EBG. It can also 707 provision the prefixes on enterprise-interior interfaces to service 708 any hosts attached to the link. 710 The PA prefix delegations remain active as long as the EBR continues 711 to issue DHCP renewals over the VET interface before lease lifetimes 712 expire. The lease lifetime also keeps the delegation state active 713 even if communications between the EBR and DHCP server are disrupted 714 for a period of time (e.g., due to an enterprise network partition, 715 power failure, etc.). 717 4.2.4. Provider-Independent (PI) EID Prefix Autoconfiguration 719 Independent of any PA prefixes, EBRs can acquire and use Provider- 720 Independent (PI) EID prefixes that are self-configured (e.g., using 721 [RFC4193], etc.) and/or delegated by a registration authority (e.g., 722 through a regional Internet registry, through a different provider, 723 through a centrally-assigned unique local address delegation 724 authority [I-D.hain-ipv6-ulac], etc.). When an EBR acquires a PI 725 prefix, it must also obtain credentials that it can use to prove 726 ownership when it registers the prefixes (see Section 5.3 and 727 Section 5.3.6). 729 After the EBR receives PI prefix delegations, it can provision the 730 prefixes on enterprise-edge interfaces as well as on other VET 731 interfaces for which it is configured as an EBG. It can also 732 provision the prefixes on enterprise-interior interfaces to service 733 any hosts attached to the link. 735 The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. 737 The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. 739 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 741 EBGs are EBRs that connect child enterprises to provider networks via 742 provider-edge interfaces and/or via VET interfaces configured over 743 parent enterprises. EBGs autoconfigure their provider-edge 744 interfaces in a manner that is specific to the provider connections, 745 and they autoconfigure their VET interfaces that were configured over 746 parent enterprises using the EBR autoconfiguration procedures 747 specified in Section 4.2. 749 For each of its VET interfaces configured over a child enterprise, 750 the EBG initializes the interface the same as for an ordinary EBR 751 (see Section 4.2.1). It must then arrange to add one or more of its 752 RLOCs associated with the child enterprise to the PRL as specified in 753 [RFC5214], Section 9. In particular, for each VET interface 754 configured over a child enterprise the EBG adds the RLOCs to name 755 service resource records for 'PRLNAME' ("isatapv2.example.com", by 756 default). 758 EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces 759 configured over child enterprises with a distributed management 760 structure. 762 EBGs configure a DHCP relay/server on VET interfaces configured over 763 child enterprises that require DHCP services. 765 To avoid looping, EBGs must not configure a default route on a VET 766 interface configured over a child interface. 768 4.4. VET Host Autoconfiguration 770 Nodes that cannot be attached via an EBR's enterprise-edge interface 771 (e.g., nomadic laptops that connect to a home office via a Virtual 772 Private Network (VPN)) can instead be configured for operation as a 773 simple host connected to the VET interface. Such VET hosts perform 774 the same VET interface initialization and border gateway discovery 775 procedures as specified for EBRs in Section 4.2.1, but they configure 776 their VET interfaces as host interfaces (and not router interfaces). 777 Note also that a node may be configured as a host on some VET 778 interfaces and as an EBR/EBG on other VET interfaces. 780 VET hosts perform address autoconfiguration on VET interfaces 781 according to [RFC4862]. When a VET host generates a VET address, it 782 first creates an interface identifier that embeds its IPv4 RLOC 783 address as specified in Section 6.1 of [RFC5214]. The host then 784 configures IPv6 unicast VET addresses from advertised on-link 785 prefixes received in RA messages and assigns them to the VET 786 interface, i.e., it does not perform Duplicate Address Detection 787 (DAD) on the addresses since the embedded IPv4 RLOC address already 788 provides uniqueness. 790 5. Internetworking Operation 792 Following the autoconfiguration procedures specified in Section 4, 793 ERs, EBRs, EBGs, and VET hosts engage in normal internetworking 794 operations as discussed in the following sections. 796 5.1. Routing Protocol Participation 798 ERs engage in any intra-enterpise routing protocols over enterprise- 799 interior interfaces to discover routing information for forwarding IP 800 packets with RLOC addresses. EBRs can additionally engage in any 801 inter-enterprise routing protocols over VET, enterprise-edge and 802 provider-edge interfaces to discover routing information for 803 forwarding IP packets with EID addresses. Note that the EID-based 804 inter-enterprise IP routing domains are separate and distinct from 805 any RLOC-based enterprise interior IP routing domains. 807 EBRs use the list of EBGs in the PRL (see: Section 4.2.2) as an 808 initial list of neighbors for inter-enterprise routing protocol 809 participation. Routing protocol participation on non-multicast VET 810 interfaces uses the NBMA model, e.g., in the same manner as for OSPF 811 over NBMA interfaces [RFC5340]. 813 5.2. Address Selection 815 When permitted by policy and supported by enterprise interior 816 routing, end systems can avoid VET interface encapsulation through 817 communications that directly invoke the outer IP protocol using RLOC 818 addresses instead of EID addresses for end-to-end communications. 819 For example, an enterprise that provides native IPv4 internal network 820 services can provide continued support for native IPv4 communications 821 even when encapsulated IPv6 services are available for inter- 822 enterprise communications. In other enterprise scenarios, the use of 823 EID-based communications (i.e., instead of RLOC-based communications) 824 may be necessary and/or beneficial to support address scaling, NAT 825 avoidance, security domain separation, site multihoming, traffic 826 engineering, etc. . 828 End systems can use source address selection rules to determine 829 whether to use EID-based or RLOC-based addressing based on, e.g., 830 name service information. The remainder of this section discusses 831 internetworking operation for EID-based communications using the VET 832 interface abstraction. 834 5.3. VET interface Neighbor Discovery 836 The following sections discuss IPv6 Neighbor Discovery (ND) 837 considerations for VET interfaces for the case of IPv6 as the inner 838 IP protocol and IPv4 as the outer IP protocol (ND considerations for 839 other protocol combinations are out of scope). Depending on the 840 enterprise network trust basis, VET nodes may be required to use 841 mechanisms such as SEND to secure their ND exchanges. 843 5.3.1. Router and Prefix Discovery 845 5.3.1.1. EBR Specification 847 EBRs discover the PRL for each VET interface as specified in 848 Section 4.2.2, and participate in a dynamic routing protocol over the 849 VET interface using the EBG addresses in the PRL as addresses of 850 potential neighboring routers. When a dynamic routing protocol 851 cannot be used, EBRs instead send RS messages to receive solicited 852 RAs from each EBG in the PRL. (Note that this will cause the EBG to 853 set the 'IsRouter' flag in the neighbor cache entry for this EBR to 854 FALSE - see: [RFC4861], Appendix D.) When the EBR receives a 855 solicited RA from an EBG (see Section 5.3.1.2), it authenticates the 856 message then processes any autoconfiguration information. (Note 857 however that the EBR should not configure prefixes received in Prefix 858 Information Options (PIOs) on its VET interfaces if it will have EID 859 addresses and prefixes configured on any of its other interfaces. 860 This prevents the EBR from sending packets directly to VET hosts 861 without first going through a default router, since VET hosts will 862 only accept routed packets that come through a PRL router.) 864 Next, the EBR creates RA messages to send to each EBG in the PRL. 865 The EBR includes Route Information Options (RIOs) [RFC4191] that 866 contain its EID prefixes in each RA, but it MUST NOT include any 867 other autoconfiguration parameters (e.g., non-zero Router Lifetime, 868 Prefix Information Options (PIOs), etc.) The EBR also 869 unconditionally sets the 'M' bit to 0 and the 'O' bit to 1 in order 870 to avoid conflicting with the information included in RA messages 871 from EBGs (see: Section 5.3.1.2). The EBR also includes an RLOC for 872 the EBG as the outer IP destination address and includes the IPv6 873 link-local "All Routers Multicast" address as the inner IP 874 destination address [RFC4291] of the RA. 876 The EBR next creates a CGA or IPv6 privacy link-local address and 877 includes it as the inner IP source address of the RA. When CGAs are 878 used, the EBR additionally includes SEND credentials plus any router 879 certificates needed to prove its ownership of the prefixes in its 880 Route Information Options (RIOs). Note that the CGA/privacy link- 881 local address is used only as the inner source address of unsolicited 882 RA messages, and therefore need not be checked for uniqueness on the 883 link. The EBR finally includes the RLOC assigned to an underlying 884 interface as the outer source address of the RA. 886 If the EBR has multiple RLOC addresses assigned to underlying 887 interfaces, it can either send multiple RA messages to each EBG (each 888 with a different RLOC) or send a single RA message that includes 889 multiple Source Link Layer Address Options (SLLAOs) formatted using a 890 modified version of the form specified in Section 5 of [RFC2529] as 891 shown in Figure 2: 893 +-------+-------+-------+-------+-------+-------+-------+-------+ 894 | Type |Length | Reserved | IPv4 RLOC Address | 895 +-------+-------+-------+-------+-------+-------+-------+-------+ 897 Figure 2: VET Link-Layer Address Option Format 899 Each SLLAO contains the IPv4 RLOC of an underlying interface. The 900 SLLAOs are arranged in order from lowest to highest priority (i.e., 901 the first SLLAO contains the lowest priority RLOC and the final SLLAO 902 option contains the highest priority). 904 The EBR then sends the RA message(s) to the EBG and must thereafter 905 periodically send new RA messages to refresh prefix lifetimes, where 906 an RA interval of 120 seconds is recommended. Each EBG that receives 907 an EBR's RA will in turn relay a proxied version of the RA to EBGs on 908 their parent enterprises. This procedure has a direct analogy in the 909 Teredo method of maintaining state in network middleboxes through the 910 periodic transmission of "bubbles" [RFC4380]. 912 5.3.1.2. EBG Specification 914 EBGs follow the router and prefix discovery procedures specified in 915 Section 8.2 of [RFC5214]. When an EBG receives an RS message, it 916 first authenticates the message. If the VET interface maintains a 917 neighbor cache, the EBG next creates or updates a neighbor cache 918 entry for the VET link-local source address corresponding to the 919 outer IP source address of the solicitation according to Section 920 6.2.6 of [RFC4861]. If the neighbor cache entry cannot be created or 921 updated (e.g., due to insufficient resources), the EBG silently 922 discards the solicitation and does not send an RA. Otherwise, the 923 EBG creates/updates the neighbor cache entry, sets a "Time To Live 924 (TTL)" on the entry that is no shorter than any of its advertised 925 router or prefix lifetimes, and sends an RA response to the 926 solicitation. If the neighbor cache entry TTL subsequently expires 927 before a new solicitation arrives, the EBG deletes the neighbor cache 928 entry. Note that if the VET interface does not maintain a neighbor 929 cache, the EBG simply omits these neighbor cache manipulations. 931 The EBG then prepares the RA response to the solicitation that 932 includes Router Lifetimes, PIOs, and any other options/parameters 933 that the EBG is configured to include. The EBG unconditionally sets 934 the 'M' bit to 0 and the 'O' bit to 1. Next, the EBG includes SEND 935 parameters if necessary and sets the inner and outer IP source and 936 destination addresses. The EBG sets the inner IP source address to 937 either a CGA address (i.e., if SEND is used) or a VET link-local 938 source address that embeds one of the EBG's RLOC addresses, then sets 939 the outer IP source address to one of its RLOC address. The EBG next 940 sets the inner IP source address to a VET link-local address that 941 embeds the EBR's RLOC addresses, then sets the outer IP destination 942 address to the EBR's RLOC address. Finally, the EBG sends the 943 solicited RA to the VET node that sent the solicitation. 945 In addition to RS messages, the EBG will receive RA messages sent by 946 EBRs as specified in Section 5.3.1.1. When an EBG receives the RA, 947 it first authenticates the message; if the authentication fails, the 948 EBG discards the RA. Otherwise, the EBG uses any EID prefixes in 949 PIOs with their respective lifetimes to updates its Forwarding 950 Information Base (FIB). The EBG also caches each RLOC received in 951 SLLAO options in the RA message as equivalent neighbors associated 952 with the FIB entries, i.e., each FIB entry may include multiple 953 potential next-hops. Finally, the EBG caches the RA message as 954 ancillary data attached to the FIB entries so that the message can be 955 replayed in the future to support router-to-router redirects (see: 956 Section 5.3.3). 958 After the EBG authenticates the RA and updates its FIB, it next acts 959 as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the VET 960 interfaces configured over any of its parent enterprises, and relays 961 a proxied RA to the EBGs on those interfaces. (For enterprises that 962 use SEND, the EBG additionally acts as a SEcure Neighbor Discovery 963 Proxy (SENDProxy) [I-D.ietf-csi-proxy-send].) EBGs in parent 964 enterprises that receive the proxied RAs in turn act as NDProxys/ 965 SENDProxys to relay the RAs to EBGs on their parent enterprises, etc. 966 The RA proxying recurses in this fashion and ends when an EBR 967 attached to an interdomain routing core is reached. 969 5.3.1.3. VET Host Specification 971 VET hosts follow the router and prefix discovery procedures specified 972 in [RFC5214], Section 8.3. They discover the addresses of EBGs for 973 each VET interface as specified in Section 4.2.2, and send an RS 974 message to each EBG in order to receive RAs with autoconfiguration 975 information. 977 When the VET host receives a solicited RA from an EBG, it 978 authenticates the message then performs autoconfiguration the same as 979 for any link (see also: Section 4.4). When the VET host receives an 980 unsolicited RA from an EBR, it authenticates the message then 981 processes any RIOs in order to update its FIB. 983 5.3.2. Next Hop Determination 985 VET nodes perform next-hop determination via longest prefix match the 986 same as for any IPv6 interface and sends packets according to the 987 most-specific matching entry in the FIB, i.e., even if the most 988 specific FIB entry is "default". When there is no matching entry in 989 the FIB (i.e., not even "default"), VET nodes can discover next-hop 990 EBRs within the enterprise by querying the name service for the /56 991 IPv6 EID prefix taken from a packet's destination address (or, by 992 some other inner-IP to outer-IP address mapping mechanism). For 993 example, for the IPv6 destination address '2001:DB8:1:2::1' and 994 'PRLNAME' "isatapv2.example.com" the VET node can lookup the domain 995 name: 996 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatapv2.example.com'. 998 Name-service lookups in enterprises with a centralized management 999 structure use an infrastructure-based service, e.g., an enterprise- 1000 local DNS. Name-service lookups in enterprises with a distributed 1001 management structure and/or that lack an infrastructure-based name 1002 service instead use LLMNR over the VET interface. When LLMNR is 1003 used, the EBR that performs the lookup sends an LLMNR query (with the 1004 /56 prefix taken from the IP destination address encoded in dotted- 1005 nibble format as shown above) and accepts the union of all replies it 1006 receives from other EBRs on the VET interface. When an EBR receives 1007 an LLMNR query, it responds to the query IFF it aggregates an IP 1008 prefix that covers the prefix in the query. 1010 If the name-service lookup succeeds, it will return RLOC addresses 1011 (e.g., in DNS A records) that correspond to next-hop EBRs to which 1012 the VET node can forward packets. 1014 5.3.3. Redirect Function 1016 In enterprises with a stable and highly-available set of EBGs, the 1017 VET node can simply forward initial packets via a default route to an 1018 EBG. The EBG will forward the packet and return an ICMPv6 Redirect 1019 as specified in Section 8 of [RFC4861] if the next-hop corresponds to 1020 a node on the same VET interface. If the source address of the 1021 packet causing the redirect is on-link on the VET interface, the EBG 1022 returns an ordinary "router-to-host" redirect with the source address 1023 of the packet as its destination. When a VET host receives the 1024 redirect, it processes the message exactly as specified in Section 8 1025 of [RFC4861]. 1027 If the source address of the packet causing the redirect is not on- 1028 link, the EBG instead prepares a "router-to-router" redirect with the 1029 link-local VET address of the EBR that sent the packet as its 1030 destination and with the destination address of the original packet 1031 as the redirected destination. If the destination address is on- 1032 link, the EBG sets the address of the VET host as the redirected 1033 target, includes the header of the redirected packet, and returns the 1034 redirect to the EBR that sent the packet. 1036 If the destination is not on link, however, the EBG sets the link- 1037 local address of the next-hop toward the destination as the 1038 redirected target. The EBG then includes in the redirect a Route 1039 Information Option (RIO) (i.e., the same as described for RA messages 1040 in [RFC4191]) that includes the routing information from the EBG's 1041 forwarding tables corresponding to the prefix that covers the 1042 packet's destination address. The EBG may also include in the 1043 redirect one or more IPv6 Target Link Layer Address Options (TLLAOs) 1044 formatted using the form shown in Figure 2. Each TLLAO contains the 1045 IPv4 RLOC of a potential next-hop EBR interface that can provide 1046 forwarding services toward the redirected destination. The TLLAOs 1047 are arranged in order from lowest to highest priority (i.e., the 1048 first TLLAO contains the lowest priority RLOC and the final TLLAO 1049 option contains the highest priority). Finally, the EBG includes the 1050 header of the redirected packet and returns the redirect to the EBR 1051 that sent the packet. 1053 When the EBR receives the "router-to-router" redirect, it caches the 1054 addresses included in the redirected target and TLLAO options in its 1055 neighbor cache for use as RLOCs associated with the redirected 1056 destination. The EBR then creates a FIB entry using the prefix 1057 information in the RIO option. The EBR then "replays" the cached RA 1058 message associated with the FIB entry corresponding to the packet's 1059 source address by proxying the message with the RLOC address from the 1060 redirected target as its outer IP destination address. This proxying 1061 process is otherwise the same as specified in Section 5.3.1.2. When 1062 a next-hop VET node receives the replayed RA, it authenticates the 1063 message (e.g., using SEND credentials) then installs any prefixes in 1064 RIOs in its FIB. 1066 VET nodes retain the FIB entries created as a result of receipt of an 1067 ICMP redirect until the route lifetimes expire, or until no hints of 1068 forward progress through any of the FIB entry's associated RLOCs are 1069 received. In this way, RLOC liveness detection exactly parallels 1070 IPv6 Neighbor Unreachability Detection ([RFC4861], Section 7). 1072 5.3.4. Neighbor Unreachability Detection 1074 VET nodes use their neighbor cache for Neighbor Unreachability 1075 Detection (NUD) the same as for any IPv6 link as described in Section 1076 7 of [RFC4861]. When a neighbor fails (or appears to be failing), 1077 FIB entries are updated to select a different next-hop when there are 1078 multiple next-hops available. 1080 The NUD mechanism uses hints of forward progress (i.e., evidence that 1081 the tunnel neighbor is receiving packets) coupled with the Neighbor 1082 Solicitation/Advertisement (NS/NA) process. When hints of forward 1083 progress are available, NS/NA messaging is suppressed; when no hints 1084 are available, NS/NA messages are used in the normal fashion the same 1085 as for any IPv6 link. The SEAL mechanism includes an explicit data 1086 packet acknowledgement mechanism that can provide hints of forward 1087 progress. 1089 Responsiveness to routing changes is directly related to the 1090 "REACHABLE_TIME" constant used for NUD as specified in [RFC4861]. In 1091 order to provide responsiveness comparable to dynamic routing 1092 protocols, a reasonably short "REACHABLE_TIME" value (e.g., 5sec) 1093 should be used. 1095 5.3.5. Reverse Path Forwarding Checks 1097 VET nodes determine whether a packet received on a VET interface can 1098 be accepted based on an ingress filtering check [RFC3704]. The VET 1099 node determines the previous hop router for a received packet by 1100 constructing a VET link-local address that embeds the outer IPv4 1101 source address. It then examines its FIB to determine whether there 1102 is an entry that matches the inner IPv6 source address and that has 1103 the VET link-local address as the next hop. If such a FIB entry 1104 exists, the VET host accepts the packet; otherwise, it discards the 1105 packet. 1107 5.3.6. IPv4 Neighbor Discovery 1109 When IPv4 is used as the inner IP protocol, router discovery and 1110 prefix registration exactly parallel the mechanisms specified for 1111 IPv6 in Section 5.3. To support this, modifications to the ICMPv4 1112 Router Advertisement [RFC1256] function to include SEND constructs 1113 and modifications to the ICMPv4 Redirect [RFC0792] function to 1114 support router-to-router redirects will be specified in a future 1115 document. Additionally, publications for IPv4 prefixes will be in 1116 dotted-nibble format in the 'ip4.isatapv2.example.com' domain. For 1117 example, the IPv4 prefix 192.0.2/24 would be represented as: 1118 '2.0.0.0.0.c.ip4.isatapv2.example.com' 1120 5.4. Generating Errors 1122 When an EBR receives an IPv6 packet over a VET interface and there is 1123 no matching ingress filter entry, it drops the packet and returns an 1124 ICMPv6 [RFC4443] "Destination Unreachable; Reject route to 1125 destination" message to the previous-hop EBR subject to rate 1126 limiting. 1128 When an EBR receives an IPv6 packet over a VET interface, and there 1129 is no longest-prefix-match FIB entry for the destination, it returns 1130 an ICMPv6 "Destination Unreachable; No route to destination" message 1131 to the previous hop EBR subject to rate limiting. 1133 When an EBR receives an IPv6 packet over a VET interface and the 1134 longest-prefix-match FIB entry for the destination is via a next-hop 1135 configured over the same VET interface the packet arrived on, the EBR 1136 forwards the packet. If the FIB prefix is longer than ::/0, the EBR 1137 then sends a router-to-router ICMPv6 Redirect message (using SEND, if 1138 necessary) to the previous-hop EBR as specified in Section 5.3.3. 1140 Generation of other ICMP messages [RFC0792] [RFC4443] is the same as 1141 for any IP interface. 1143 5.5. Processing Errors 1145 When a VET node receives an ICMPv6 "Destination Unreachable; Reject 1146 route to destination" message, and there is a longest-prefix-match 1147 FIB entry for the original packet's destination that is more specific 1148 than ::/0, the node discards the message and marks the FIB entry for 1149 the destination as "forwarding suspended" for the RLOC taken from the 1150 source address of the ICMPv6 message. The node should then allow 1151 subsequent packets to flow through different RLOCs associated with 1152 the FIB entry. If the node receives excessive ICMPv6 reject route to 1153 destination messages through multiple RLOCs associated with the same 1154 FIB entry, it should delete the FIB entry and allow subsequent 1155 packets to flow through an EBG if supported in the specific 1156 enterprise scenario. 1158 When a VET node receives an ICMPv6 "Destination Unreachable; No route 1159 to destination" message, it forwards the ICMPv6 message to the source 1160 of the original packet as normal. If the node has a longest-prefix- 1161 match FIB entry for the original packet's destination that is more 1162 specific than ::/0, the node also deletes the FIB entry. 1164 When a VET node receives an authentic ICMPv6 Redirect, it processes 1165 the packet as specified in Section 5.3.3. 1167 Additionally, a VET node may receive outer IP ICMP "Destination 1168 Unreachable; net / host unreachable" messages from an ER on the path 1169 indicating that the path to a VET neighbor may be failing. The node 1170 should first check authenticating information (e.g., the SEAL_ID, 1171 IPsec sequence number, source address of the original packet if 1172 available, etc.) to obtain reasonable assurance that the ICMP message 1173 is authentic, then should mark the longest-prefix-match FIB entry for 1174 the destination as "forwarding suspended" for the RLOC destination 1175 address of the ICMP packet-in-error. If the node receives excessive 1176 ICMP unreachable errors through multiple RLOCs associated with the 1177 same FIB entry, it should delete the FIB entry and allow subsequent 1178 packets to flow through a different route. 1180 5.6. Mobility and Multihoming Considerations 1182 EBRs that travel between distinct enterprise networks must either 1183 abandon their PA prefixes that are relative to the "old" enterprise 1184 and obtain new ones relative to the "new" enterprise or somehow 1185 coordinate with a "home" enterprise to retain ownership of the 1186 prefixes. In the first instance, the EBR would be required to 1187 coordinate a network renumbering event using the new PA prefixes 1188 [RFC4192]. In the second instance, an ancillary mobility management 1189 mechanism must be used. 1191 EBRs can retain their PI prefixes as they travel between distinct 1192 enterprise networks as long as they register the prefixes with new 1193 EBGs and (preferably) withdraw the prefixes from old EBGs prior to 1194 departure. Prefix registration with new EBGs is coordinated exactly 1195 as specified in Section 4.2.4; prefix withdrawal from old EBGs is 1196 simply through re-announcing the PI prefixes with zero lifetimes. 1198 Since EBRs can move about independently of one another, stale FIB 1199 entry state may be left in VET nodes when a neighboring EBR departs. 1200 Additionally, EBRs can lose state for various reasons, e.g., power 1201 failure, machine reboot, etc. For this reason, EBRs are advised to 1202 set relatively short PI prefix lifetimes in RIO options, and to send 1203 additional RAs to refresh lifetimes before they expire. (EBRs should 1204 place conservative limits on the RAs they send to reduce congestion, 1205 however.) 1207 EBRs may register their PI prefixes with multiple EBGs for 1208 multihoming purposes. EBRs should only forward packets via EBGs with 1209 which it has registered its PI prefixes, since other EBGs may drop 1210 the packets and return ICMPv6 "Destination Unreachable" messages. 1212 EBRs can also act as delegating routers to sub-delegate portions of 1213 their PI prefixes to requesting routers on their enterprise-edge 1214 interfaces and on VET interfaces for which they are configured as 1215 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 1216 become the PA prefixes for downstream-dependent nodes. 1218 The EBGs of a multihomed enterprise should participate in a private 1219 inner IP routing protocol instance between themselves (possibly over 1220 an alternate topology) to accommodate enterprise partitions/merges as 1221 well as intra-enterprise mobility events. These peer EBGs should 1222 accept packets from one another without respect to the destination 1223 (i.e., ingress filtering is based on the peering relationship rather 1224 than a prefix-specific ingress filter entry). 1226 5.7. Multicast 1228 In multicast-capable deployments, ERs provide an enterprise-wide 1229 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1230 [I-D.ietf-manet-smf], Protocol Independent Multicast (PIM) routing, 1231 Distance Vector Multicast Routing Protocol (DVMRP) routing, etc.) 1232 over their enterprise-interior interfaces such that outer IP 1233 multicast messages of site-scope or greater scope will be propagated 1234 across the enterprise. For such deployments, VET nodes can also 1235 provide an inner IP multicast/broadcast capability over their VET 1236 interfaces through mapping of the inner IP multicast address space to 1237 the outer IP multicast address space. In that case, operation of 1238 link-scoped (or greater scoped) inner IP multicasting services (e.g., 1239 a link-scoped neighbor discovery protocol) over the VET interface is 1240 available, but link-scoped services should be used sparingly to 1241 minimize enterprise-wide flooding. 1243 VET nodes encapsulate inner IP multicast messages sent over the VET 1244 interface in any mid-layer headers (e.g., SEAL, IPsec, etc.) followed 1245 by an outer IP header with a site-scoped outer IP multicast address 1246 as the destination. For the case of IPv6 and IPv4 as the inner/outer 1247 protocols (respectively), [RFC2529] provides mappings from the IPv6 1248 multicast address space to a site-scoped IPv4 multicast address space 1249 (for other encapsulations, mappings are established through 1250 administrative configuration or through an unspecified alternate 1251 static mapping). 1253 Multicast mapping for inner IP multicast groups over outer IP 1254 multicast groups can be accommodated, e.g., through VET interface 1255 snooping of inner multicast group membership and routing protocol 1256 control messages. To support inner-to-outer IP multicast mapping, 1257 the VET interface acts as a virtual outer IP multicast host connected 1258 to its underlying interfaces. When the VET interface detects that an 1259 inner IP multicast group joins or leaves, it forwards corresponding 1260 outer IP multicast group membership reports on an underlying 1261 interface over which the VET interface is configured. If the VET 1262 node is configured as an outer IP multicast router on the underlying 1263 interfaces, the VET interface forwards locally looped-back group 1264 membership reports to the outer IP multicast routing process. If the 1265 VET node is configured as a simple outer IP multicast host, the VET 1266 interface instead forwards actual group membership reports (e.g., 1267 IGMP messages) directly over an underlying interface. 1269 Since inner IP multicast groups are mapped to site-scoped outer IP 1270 multicast groups, the VET node must ensure that the site-scope outer 1271 IP multicast messages received on the underlying interfaces for one 1272 VET interface do not "leak out" to the underlying interfaces of 1273 another VET interface. This is accommodated through normal site- 1274 scoped outer IP multicast group filtering at enterprise boundaries. 1276 5.8. Service Discovery 1278 VET nodes can perform enterprise-wide service discovery using a 1279 suitable name-to-address resolution service. Examples of flooding- 1280 based services include the use of LLMNR [RFC4795] over the VET 1281 interface or multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] 1282 over an underlying interface. More scalable and efficient service 1283 discovery mechanisms are for further study. 1285 5.9. Enterprise Partitioning 1287 An enterprise can be partitioned into multiple distinct logical 1288 groupings. In that case, each partition must configure its own 1289 distinct 'PRLNAME' (e.g., 'isatapv2.zone1.example.com', 1290 'isatapv2.zone2.example.com', etc.). 1292 EBGs can further create multiple IP subnets within a partition by 1293 sending RAs with PIOs containing different IPv6 prefixes to different 1294 groups of nodes. EBGs can identify subnets, e.g., by examining RLOC 1295 prefixes, observing the enterprise interior interfaces over which RSs 1296 are received, etc. 1298 5.10. EBG Prefix State Recovery 1300 EBGs must retain explicit state that tracks the inner IP PA prefixes 1301 delegated to EBRs within the enterprise, e.g., so that packets are 1302 delivered to the correct EBRs. When an EBG loses some or all of its 1303 state (e.g., due to a power failure), it must recover the state so 1304 that packets can be forwarded over correct routes. 1306 5.11. Support for Legacy ISATAP Services 1308 EBGs support legacy ISATAP services according to the specifications 1309 in [RFC5214]. In particular, EBGs can configure legacy ISATAP 1310 interfaces and VET interfaces over the same sets of underlying 1311 interface as long as the PRLs and IPv6 prefixes associated with the 1312 ISATAP/VET interfaces are distinct. 1314 5.12. SEAL Encapsulation 1316 When SEAL is used, the VET interface encapsulates the inner IP packet 1317 in any mid-layer headers (e.g., IPsec [RFC4301]) followed a SEAL 1318 header [I-D.templin-intarea-seal] followed by an outer IP header; it 1319 next submits the encapsulated packet to the outer IP forwarding 1320 engine for transmission on an underlying interface. 1322 VET interfaces can use SEAL encapsulation to accommodate path MTU 1323 diversity, to defeat source address spoofing, and to enable sub-IP 1324 layer hints of forward progress that can be piggybacked on ordinary 1325 data messages. SEAL encapsulation maintains a unidirectional and 1326 monotonically incrementing per-packet identification value known as 1327 the 'SEAL_ID'. When a VET node that uses SEAL encapsulation receives 1328 an authentic neighbor discovery message from another VET node, it can 1329 cache the new SEAL_ID as per-tunnel state used for maintaining a 1330 window of unacknowledged SEAL_IDs. 1332 In terms of security, when a VET node receives an ICMP message or a 1333 SEAL error message, it can confirm that the packet-in-error within 1334 the message corresponds to one of its recently sent packets by 1335 examining the SEAL_ID along with source and destination addresses, 1336 etc. Additionally, a next-hop EBR can track the SEAL_ID in packets 1337 received from EBRs for which there is an ingress filter entry and 1338 discard packets that have SEAL_ID values outside of the current 1339 window. (Note that for IPv6 in IPv4 encapsulation packets with a 1340 link-local IPv6 destination address are excluded from this check to 1341 support operation of the neighbor discovery protocol.) 1343 In terms of next-hop reachability, an EBR can set the SEAL 1344 "Acknowledgement Requested" bit in messages to receive confirmation 1345 that a next-hop EBR is reachable. (Note that this is a mid-layer 1346 reachability confirmation, and not an L2 reachability indication.) 1347 Setting the "Acknowledgement Requested" bit is also used as the 1348 method for maintaining the window of outstanding SEAL_IDs. 1350 6. IANA Considerations 1352 There are no IANA considerations for this document. 1354 7. Security Considerations 1356 Security considerations for MANETs are found in [RFC2501]. 1358 The security considerations found in [RFC2529] [RFC5214] 1359 [I-D.nakibly-v6ops-tunnel-loops] also apply to VET. In particular: 1361 o VET nodes must ensure that a VET interface does not span multiple 1362 sites as specified in Section 6.2 of [RFC5214]. 1364 o VET nodes must verify that the outer IP source address of a packet 1365 received on a VET interface is correct for the inner IP source 1366 address; for the case of IPv6 in IPv4 encapsulation, this is 1367 accommodated using the procedures specified in Section 7.3 of 1369 [RFC5214]. 1371 o EBRs must implement both inner and outer IP ingress filtering in a 1372 manner that is consistent with [RFC2827] as well as ip-proto-41 1373 filtering. When the node at the physical boundary of the 1374 enterprise is an ordinary ER (i.e., and not an EBR), the ER itself 1375 should implement filtering. 1377 Additionally, VET interfaces that use IPv6 in IPv4 encapsulation and 1378 that maintain a coherent neighbor cache drop all outbound packet for 1379 which the IPv6 next hop is not a neighbor and the IPv6 source address 1380 is not link-local; they also drop all incoming packets for which the 1381 IPv6 previous hop is not a neighbor and the IPv6 destination address 1382 is not link-local. (Here, the previous hop is determined by 1383 examining the IPv4 source address.) 1385 Finally, VET interfaces that use IPv6 in IPv4 encapsulation drop all 1386 outbound packets for which the IPv6 source address is "foreign- 1387 prefix::0200:5efe:V4ADDR" and drop all incoming packets for which the 1388 IPv6 destination address is "foreign-prefix::0200:5efe:V4ADDR" . 1389 (Here, "foreign-prefix" is an IPv6 prefix that is not assigned to the 1390 VET interface, and "V4ADDR" is a public IPv4 address over which the 1391 VET interface is configured.) Note that these checks are only 1392 required for VET interfaces that cannot maintain a coherent neighbor 1393 cache. 1395 SEND [RFC3971] and/or IPsec [RFC4301] can be used in environments 1396 where attacks on the neighbor discovery protocol are possible. SEAL 1397 [I-D.templin-intarea-seal] provides a per-packet identification that 1398 can be used to detect source address spoofing. 1400 Rogue neighbor discovery messages with spoofed RLOC source addresses 1401 can consume network resources and cause VET nodes to perform extra 1402 work. Nonetheless, VET nodes should not "blacklist" such RLOCs, as 1403 that may result in a denial of service to the RLOCs' legitimate 1404 owners. 1406 8. Related Work 1408 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1409 automatic tunneling in [RFC2529]; this concept was later called: 1410 "Virtual Ethernet" and investigated by Quang Nguyen under the 1411 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1412 their colleagues have motivated a number of foundational concepts on 1413 which this work is based. 1415 Telcordia has proposed DHCP-related solutions for MANETs through the 1416 CECOM MOSAIC program. 1418 The Naval Research Lab (NRL) Information Technology Division uses 1419 DHCP in their MANET research testbeds. 1421 Security concerns pertaining to tunneling mechanisms are discussed in 1422 [I-D.ietf-v6ops-tunnel-security-concerns]. 1424 Default router and prefix information options for DHCPv6 are 1425 discussed in [I-D.droms-dhc-dhcpv6-default-router]. 1427 An automated IPv4 prefix delegation mechanism is proposed in 1428 [I-D.ietf-dhc-subnet-alloc]. 1430 RLOC prefix delegation for enterprise-edge interfaces is discussed in 1431 [I-D.clausen-manet-autoconf-recommendations]. 1433 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1435 Various proposals within the IETF have suggested similar mechanisms. 1437 9. Acknowledgements 1439 The following individuals gave direct and/or indirect input that was 1440 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 1441 Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, 1442 Chris Dearlove, Gert Doering, Ralph Droms, Washam Fan, Dino 1443 Farinacci, Vince Fuller, Thomas Goff, David Green, Joel Halpern, Bob 1444 Hinden, Sascha Hlusiak, Sapumal Jayatissa, Dan Jen, Darrel Lewis, 1445 Tony Li, Joe Macker, David Meyer, Gabi Nakibly, Thomas Narten, Pekka 1446 Nikander, Dave Oran, Alexandru Petrescu, Mark Smith, John Spence, 1447 Jinmei Tatuya, Dave Thaler, Ole Troan, Michaela Vanderveen, James 1448 Woodyatt, Lixia Zhang, and others in the IETF AUTOCONF and MANET 1449 working groups. Many others have provided guidance over the course 1450 of many years. 1452 10. Contributors 1454 The following individuals have contributed to this document: 1456 Eric Fleischman (eric.fleischman@boeing.com) 1457 Thomas Henderson (thomas.r.henderson@boeing.com) 1458 Steven Russert (steven.w.russert@boeing.com) 1459 Seung Yi (seung.yi@boeing.com) 1461 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1462 of the document. 1464 Jim Bound's foundational work on enterprise networks provided 1465 significant guidance for this effort. We mourn his loss and honor 1466 his contributions. 1468 11. References 1470 11.1. Normative References 1472 [I-D.templin-intarea-seal] 1473 Templin, F., "The Subnetwork Encapsulation and Adaptation 1474 Layer (SEAL)", draft-templin-intarea-seal-08 (work in 1475 progress), January 2010. 1477 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1478 September 1981. 1480 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1481 RFC 792, September 1981. 1483 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1484 converting network protocol addresses to 48.bit Ethernet 1485 address for transmission on Ethernet hardware", STD 37, 1486 RFC 826, November 1982. 1488 [RFC1035] Mockapetris, P., "Domain names - implementation and 1489 specification", STD 13, RFC 1035, November 1987. 1491 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1492 RFC 2131, March 1997. 1494 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1495 (IPv6) Specification", RFC 2460, December 1998. 1497 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1498 Defeating Denial of Service Attacks which employ IP Source 1499 Address Spoofing", BCP 38, RFC 2827, May 2000. 1501 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1502 Update", RFC 3007, November 2000. 1504 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1505 and M. Carney, "Dynamic Host Configuration Protocol for 1506 IPv6 (DHCPv6)", RFC 3315, July 2003. 1508 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1509 "DNS Extensions to Support IP Version 6", RFC 3596, 1510 October 2003. 1512 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1513 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1514 December 2003. 1516 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1517 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1519 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1520 RFC 3972, March 2005. 1522 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1523 More-Specific Routes", RFC 4191, November 2005. 1525 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1526 Architecture", RFC 4291, February 2006. 1528 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1529 Message Protocol (ICMPv6) for the Internet Protocol 1530 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1532 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1533 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1534 September 2007. 1536 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1537 Address Autoconfiguration", RFC 4862, September 2007. 1539 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1540 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1541 March 2008. 1543 11.2. Informative References 1545 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1546 Switching Networks", May 1974. 1548 [I-D.cheshire-dnsext-multicastdns] 1549 Cheshire, S. and M. Krochmal, "Multicast DNS", 1550 draft-cheshire-dnsext-multicastdns-08 (work in progress), 1551 September 2009. 1553 [I-D.clausen-manet-autoconf-recommendations] 1554 Clausen, T. and U. Herberg, "MANET Router Configuration 1555 Recommendations", 1556 draft-clausen-manet-autoconf-recommendations-00 (work in 1557 progress), February 2009. 1559 [I-D.clausen-manet-linktype] 1560 Clausen, T., "The MANET Link Type", 1561 draft-clausen-manet-linktype-00 (work in progress), 1562 October 2008. 1564 [I-D.droms-dhc-dhcpv6-default-router] 1565 Droms, R. and T. Narten, "Default Router and Prefix 1566 Advertisement Options for DHCPv6", 1567 draft-droms-dhc-dhcpv6-default-router-00 (work in 1568 progress), March 2009. 1570 [I-D.hain-ipv6-ulac] 1571 Hain, T., Hinden, R., and G. Huston, "Centrally Assigned 1572 IPv6 Unicast Unique Local Address Prefixes", 1573 draft-hain-ipv6-ulac-01 (work in progress), October 2009. 1575 [I-D.ietf-autoconf-manetarch] 1576 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1577 Network Architecture", draft-ietf-autoconf-manetarch-07 1578 (work in progress), November 2007. 1580 [I-D.ietf-csi-proxy-send] 1581 Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy 1582 ND Support for SEND", draft-ietf-csi-proxy-send-01 (work 1583 in progress), July 2009. 1585 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 1586 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 1587 Assignment Notification (RAAN) Option", 1588 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 1589 progress), July 2009. 1591 [I-D.ietf-dhc-subnet-alloc] 1592 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1593 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-10 1594 (work in progress), November 2009. 1596 [I-D.ietf-manet-smf] 1597 Macker, J. and S. Team, "Simplified Multicast Forwarding", 1598 draft-ietf-manet-smf-09 (work in progress), July 2009. 1600 [I-D.ietf-v6ops-tunnel-security-concerns] 1601 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1602 Concerns With IP Tunneling", 1603 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1604 progress), October 2008. 1606 [I-D.jen-apt] 1607 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1608 L. Zhang, "APT: A Practical Transit Mapping Service", 1609 draft-jen-apt-01 (work in progress), November 2007. 1611 [I-D.nakibly-v6ops-tunnel-loops] 1612 Nakibly, G., "Routing Loops using ISATAP and 6to4: Problem 1613 Statement and Proposed Solutions", 1614 draft-nakibly-v6ops-tunnel-loops-00 (work in progress), 1615 October 2009. 1617 [I-D.russert-rangers] 1618 Russert, S., Fleischman, E., and F. Templin, "RANGER 1619 Scenarios", draft-russert-rangers-01 (work in progress), 1620 September 2009. 1622 [I-D.templin-isatap-dhcp] 1623 Templin, F., "Dynamic Host Configuration Protocol (DHCPv4) 1624 Option for the Intra-Site Automatic Tunnel Addressing 1625 Protocol (ISATAP)", draft-templin-isatap-dhcp-06 (work in 1626 progress), December 2009. 1628 [I-D.templin-ranger] 1629 Templin, F., "Routing and Addressing in Next-Generation 1630 EnteRprises (RANGER)", draft-templin-ranger-09 (work in 1631 progress), October 2009. 1633 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1634 July 1978. 1636 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1637 Protocol Specification", October 2008. 1639 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1640 Communication Layers", STD 3, RFC 1122, October 1989. 1642 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1643 September 1991. 1645 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1646 Routing and Addressing Architecture", RFC 1753, 1647 December 1994. 1649 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1650 E. Lear, "Address Allocation for Private Internets", 1651 BCP 5, RFC 1918, February 1996. 1653 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1654 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1656 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1657 Extensions", RFC 2132, March 1997. 1659 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1660 over Non-Broadcast Multiple Access (NBMA) networks", 1661 RFC 2491, January 1999. 1663 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1664 (MANET): Routing Protocol Performance Issues and 1665 Evaluation Considerations", RFC 2501, January 1999. 1667 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1668 Domains without Explicit Tunnels", RFC 2529, March 1999. 1670 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1671 February 2000. 1673 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1674 via IPv4 Clouds", RFC 3056, February 2001. 1676 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1677 Networks", BCP 84, RFC 3704, March 2004. 1679 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1680 RFC 3753, June 2004. 1682 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1683 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1684 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1685 RFC 3819, July 2004. 1687 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1688 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1689 May 2005. 1691 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1692 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1693 September 2005. 1695 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1696 Addresses", RFC 4193, October 2005. 1698 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1699 Internet Protocol", RFC 4301, December 2005. 1701 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1702 Network Address Translations (NATs)", RFC 4380, 1703 February 2006. 1705 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1706 Proxies (ND Proxy)", RFC 4389, April 2006. 1708 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1709 Multicast Name Resolution (LLMNR)", RFC 4795, 1710 January 2007. 1712 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1713 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1714 Focus", RFC 4852, April 2007. 1716 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1717 June 2007. 1719 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1720 Extensions for Stateless Address Autoconfiguration in 1721 IPv6", RFC 4941, September 2007. 1723 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1724 for IPv6", RFC 5340, July 2008. 1726 Appendix A. Duplicate Address Detection (DAD) Considerations 1728 A priori uniqueness determination (also known as "pre-service DAD") 1729 for an RLOC assigned on an enterprise-interior interface would 1730 require either flooding the entire enterprise or somehow discovering 1731 a link in the enterprise on which a node that configures a duplicate 1732 address is attached and performing a localized DAD exchange on that 1733 link. But, the control message overhead for such an enterprise-wide 1734 DAD would be substantial and prone to false-negatives due to packet 1735 loss and intermittent connectivity. An alternative to pre-service 1736 DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior 1737 interfaces and employ a passive in-service DAD (e.g., one that 1738 monitors routing protocol messages for duplicate assignments). 1740 Pseudo-random IPv6 RLOCs can be generated with mechanisms such as 1741 CGAs, IPv6 privacy addresses, etc. with very small probability of 1742 collision. Pseudo-random IPv4 RLOCs can be generated through random 1743 assignment from a suitably large IPv4 prefix space. 1745 Consistent operational practices can assure uniqueness for EBG- 1746 aggregated addresses/prefixes, while statistical properties for 1747 pseudo-random address self-generation can assure uniqueness for the 1748 RLOCs assigned on an ER's enterprise-interior interfaces. Still, an 1749 RLOC delegation authority should be used when available, while a 1750 passive in-service DAD mechanism should be used to detect RLOC 1751 duplications when there is no RLOC delegation authority. 1753 Appendix B. Link-Layer Multiplexing and Traffic Engineering 1755 For each distinct enterprise that it connects to, an EBR configures a 1756 VET interface over possibly multiple underlying interfaces that all 1757 connect to the same enterprise. The VET interface therefore 1758 represents the EBR's logical point of attachment to the enterprise, 1759 and provides a logical interface for link-layer multiplexing over its 1760 underlying interfaces as described in Section 3.3.4.1 of [RFC1122]: 1762 "Finally, we note another possibility that is NOT multihoming: one 1763 logical interface may be bound to multiple physical interfaces, in 1764 order to increase the reliability or throughput between directly 1765 connected machines by providing alternative physical paths between 1766 them. For instance, two systems might be connected by multiple 1767 point-to-point links. We call this "link-layer multiplexing". 1768 With link-layer multiplexing, the protocols above the link layer 1769 are unaware that multiple physical interfaces are present; the 1770 link-layer device driver is responsible for multiplexing and 1771 routing packets across the physical interfaces." 1773 EBRs can support such a link-layer multiplexing capability across the 1774 enterprise in accordance with the Weak End System Model (see Section 1775 3.3.4.2 of [RFC1122]). In particular, when an EBR autoconfigures an 1776 RLOC address (see Section 4.1), it can associate it with the VET 1777 interface only instead of assigning it to an underlying interface. 1778 The EBR therefore only needs to obtain a single RLOC address even if 1779 there are multiple underlying interfaces, i.e., it does not need to 1780 obtain one for each underlying interface. The EBR can then leave the 1781 underlying interfaces unnumbered, or it can configure a randomly 1782 chosen IP link-local address (e.g., from the prefix 169.254/16 1783 [RFC3927] for IPv4) on underlying interfaces that require a 1784 configuration. The EBR need not check these link-local addresses for 1785 uniqueness within the enterprise, as they will not normally be used 1786 as the source address for packets. 1788 When the EBR engages in the enterprise-interior routing protocol, it 1789 uses the RLOC address assigned to the VET interface as the source 1790 address for all routing protocol control messages, however it must 1791 also supply an interface identifier (e.g., a small integer) that 1792 uniquely identifies the underlying interface that the control message 1793 is sent over. For example, if the underlying interfaces are known as 1794 "eth0", "eth1" and "eth7" the EBR can supply the token "7" when it 1795 sends a routing protocol control message over the "eth7" interface. 1797 This is necessary to ensure that other routers can determine the 1798 specific interface over which the EBR's routing protocol control 1799 message was sent, but the token need only be unique within the EBR 1800 itself and need not be unique throughout the enterprise. 1802 When the EBR discovers an RLOC route via the enterprise interior 1803 routing protocol, it configures a preferred route in the IP FIB that 1804 points to the VET interface instead of the underlying interface. At 1805 the same time, the EBR also configures an ancillary route that points 1806 to the underlying interface. If the EBR discovers that the same RLOC 1807 route is reachable via multiple underlying interfaces, it configures 1808 multiple ancillary routes (i.e., one for each interface). If the EBR 1809 discovers that the RLOC route is no longer reachable via any 1810 underlying interface, it removes the route in the IP FIB that points 1811 to the VET interface. 1813 With these arrangements, all locally-generated packets with RLOC 1814 destinations will flow through the VET interface (and thereby use the 1815 VET interface's RLOC address as the source address) instead of 1816 through the underlying interfaces. In the same fashion, all 1817 forwarded packets with RLOC destinations will flow through the VET 1818 interface instead of through the underlying interfaces. 1820 This arrangement has several operational advantages that enable a 1821 number of traffic engineering capabilities. First, the VET interface 1822 can insert the SEAL header so that ID-based duplicate packet 1823 detection is enabled within the enterprise. Secondly, SEAL can 1824 dynamically adjust its packet sizing parameters so that an optimum 1825 Maximum Transmission Unit (MTU) can be determined. This is true even 1826 if the VET interface reroutes traffic between underlying interfaces 1827 with different MTUs. 1829 Most importantly, the EBR can configure default and more-specific 1830 routes on the VET interface to direct traffic through a specific 1831 egress EBR (eEBR) that may be many outer IP hops away. Encapsulation 1832 will ensure that a specific eEBR is chosen, and the best eEBR can be 1833 chosen when multiple are available. Also, local applications see a 1834 stable IP source address even if there are multiple underlying 1835 interfaces. This link-layer multiplexing can therefore provide 1836 continuous operation across failovers between multiple links attached 1837 to the same enterprise without any need for readdressing. Finally, 1838 the VET interface can forward packets with RLOC-based destinations 1839 over an underlying interface without any encapsulation if 1840 encapsulation avoidance is desired. 1842 It must be specifically noted that the above arrangement constitutes 1843 a case in which the same RLOC may be used as both the inner and outer 1844 IP source address. This will not present a problem as long as both 1845 ends configure a VET interface in the same fashion. 1847 It must also be noted that EID-based communications can use the same 1848 VET interface arrangement, except that the EID-based next hop must be 1849 mapped to an RLOC-based next-hop within the VET interface. For IPvX- 1850 in-SEAL-in-IPvX encapsulation, as well as for IPv4-in-SEAL-in-Pv6 1851 encapsulation, this requires a VET interface specific address mapping 1852 database. For IPv6-in-SEAL-in-IPv4 encapsulation, the mapping is 1853 accomplished through simple static extraction of an IPv4 address 1854 embedded in a VET address. 1856 Appendix C. Anycast Services 1858 Some of the IPv4 addresses that appear in the Potential Router List 1859 may be anycast addresses, i.e., they may be configured on the VET 1860 interfaces of multiple EGBRs/EBGs. In that case, each VET router 1861 interface that configures the same anycast address must provide 1862 equivalent packet forwarding and IPv6 Neighbor Discovery services. 1864 Use of an anycast address as the IP destination address of tunneled 1865 packets can have subtle interactions with tunnel path MTU and 1866 neighbor discovery. For example, if the initial fragments of a 1867 fragmented tunneled packet with an anycast IP destination address are 1868 routed to different egress tunnel endpoints than the remaining 1869 fragments, the multiple endpoints will be left with incomplete 1870 reassembly buffers. This issue can be mitigated by ensuring that 1871 each egress tunnel endpoint implements a proactive reassembly buffer 1872 garbage collection strategy. Additionally, ingress tunnel endpoints 1873 that send packets with an anycast IP destination address must use the 1874 minimum path MTU for all egress tunnel endpoints that configure the 1875 same anycast address as the tunnel MTU. Finally, ingress tunnel 1876 endpoints should treat ICMP unreachable messages from a router within 1877 the tunnel as at most a weak indication of neighbor unreachability, 1878 since the failures may only be transient and a different path to an 1879 alternate anycast router quickly selected through reconvergence of 1880 the underlying routing protocol. 1882 Use of an anycast address as the IP source address of tunneled 1883 packets can lead to more serious issues. For example, when the IP 1884 source address of a tunneled packet is anycast, ICMP messages 1885 produced by routers within the tunnel might be delivered to different 1886 ingress tunnel endpoints than the ones that produced the packets. In 1887 that case, functions such as path MTU discovery and neighbor 1888 unreachability detection may experience non-deterministic behavior 1889 that can lead to communications failures. Additionally, the 1890 fragments of multiple tunneled packets produced by multiple ingress 1891 tunnel endpoints may be delivered to the same reassembly buffer at a 1892 single egress tunnel endpoint. In that case, data corruption may 1893 result due to fragment misassociation during reassembly. 1895 In view of these considerations, EBRs/EBGs that configure an anycast 1896 address should also configure one or more unicast addresses from the 1897 Potential Router List; they should further accept tunneled packets 1898 destined to any of their anycast or unicast addresses, but should 1899 send tunneled packets using a unicast address as the source address. 1900 In order to influence traffic to use an anycast route (and thereby 1901 leverage the natural fault tolerance afforded by anycast), ISATAP 1902 routers should set higher preferences on the default routes they 1903 advertise using an anycast address as the source and set lower 1904 preferences on the default routes they advertise using a unicast 1905 address as the source (see: [RFC4191]). 1907 Appendix D. Change Log 1909 (Note to RFC editor - this section to be removed before publication 1910 as an RFC.) 1912 Changed from -05 to -06: 1914 o reworked VET interface ND 1916 o anycast clarifications 1918 Changes from -03 to -04: 1920 o security consideration clarifications 1922 Changes from -02 to -03: 1924 o security consideration clarifications 1926 o new PRLNAME for VET is "isatav2.example.com" 1928 o VET now uses SEAL natively 1930 o EBGs can support both legacy ISATAP and VET over the same 1931 underlying interfaces. 1933 Changes from -01 to -02: 1935 o Defined CGA and privacy address configuration on VET interfaces 1937 o Interface identifiers added to routing protocol control messages 1938 for link-layer multiplexing 1940 Changes from -00 to -01: 1942 o Section 4.1 clarifications on link-local assignment and RLOC 1943 autoconfiguration. 1945 o Appendix B clarifications on Weak End System Model 1947 Changes from RFC5558 to -00: 1949 o New appendix on RLOC configuration on VET interfaces. 1951 Author's Address 1953 Fred L. Templin (editor) 1954 Boeing Research & Technology 1955 P.O. Box 3707 MC 7L-49 1956 Seattle, WA 98124 1957 USA 1959 Email: fltemplin@acm.org