idnits 2.17.1 draft-templin-autoconf-dhcp-31.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 24, 2009) is 5570 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ENCAPS' is mentioned on line 178, but not defined == Unused Reference: 'RFC4291' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1313, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 1319, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-07 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-08 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research and Technology 4 Intended status: Informational January 24, 2009 5 Expires: July 28, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-31.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 28, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 Enterprise networks connect routers over various link types, and may 48 also connect to provider networks and/or the global Internet. Nodes 49 in enterprise networks must have a way to automatically provision IP 50 addresses/prefixes and other information, and must also support 51 internetworking operation even in highly-dynamic networks. This 52 document specifies a Virtual Enterprise Traversal (VET) abstraction 53 for autoconfiguration and operation of nodes in enterprise networks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 8 60 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1. Enterprise Interior Router (EIR) Autoconfiguration . . . . 10 62 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 11 63 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 11 64 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration . . 12 65 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration . . 13 66 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 13 67 4.4. VET Host Autoconfiguration . . . . . . . . . . . . . . . . 14 68 5. Internetworking Operation . . . . . . . . . . . . . . . . . . 14 69 5.1. Routing Protocol Participation . . . . . . . . . . . . . . 14 70 5.2. PA Prefix Maintenance . . . . . . . . . . . . . . . . . . 14 71 5.3. IPv6 EBG Discovery . . . . . . . . . . . . . . . . . . . . 15 72 5.4. IPv6 PI Prefix Registration . . . . . . . . . . . . . . . 15 73 5.5. IPv6 Next-Hop EBR Discovery . . . . . . . . . . . . . . . 17 74 5.6. Forwarding Packets . . . . . . . . . . . . . . . . . . . . 18 75 5.7. SEAL Encapsulation . . . . . . . . . . . . . . . . . . . . 19 76 5.8. Generating Errors . . . . . . . . . . . . . . . . . . . . 19 77 5.9. Processing Errors . . . . . . . . . . . . . . . . . . . . 20 78 5.10. Mobility and Multihoming Considerations . . . . . . . . . 21 79 5.11. Enterprise-Local Communications . . . . . . . . . . . . . 22 80 5.12. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 22 81 5.13. Service Discovery . . . . . . . . . . . . . . . . . . . . 23 82 5.14. Enterprise Partitioning . . . . . . . . . . . . . . . . . 23 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 91 Appendix A. Duplicate Address Detection (DAD) Considerations . . 29 92 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 30 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 1. Introduction 97 Enterprise networks [RFC4852] connect routers over various link types 98 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 99 (MANETs) [RFC2501] can be considered as a challenging example of an 100 enterprise network, in that their topologies may change dynamically 101 over time and that they may employ little/no active management by a 102 centralized network administrative authority. These specialized 103 characteristics for MANETs require careful consideration, but the 104 same principles apply equally to other enterprise network scenarios. 106 This document specifies a Virtual Enterprise Traversal (VET) 107 abstraction for autoconfiguration and internetworking operation, 108 where addresses of different scopes may be assigned on various types 109 of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 110 [RFC2460] are discussed within this context. The use of standard 111 DHCP [RFC2131][RFC3315] and neighbor discovery [RFC0826][RFC4861] 112 mechanisms is assumed unless otherwise specified. 114 Provider-edge Interfaces 115 x x x 116 | | | 117 +--------------------+---+--------+----------+ E 118 | | | | | n 119 | I | | .... | | t 120 | n +---+---+--------+---+ | e 121 | t | +--------+ /| | r 122 | e I x----+ | Host | I /*+------+--< p I 123 | r n | |Function| n|**| | r n 124 | n t | +--------+ t|**| | i t 125 | a e x----+ V e|**+------+--< s e 126 | l r . | E r|**| . | e r 127 | f . | T f|**| . | f 128 | V a . | +--------+ a|**| . | I a 129 | i c . | | Router | c|**| . | n c 130 | r e x----+ |Function| e \*+------+--< t e 131 | t s | +--------+ \| | e s 132 | u +---+---+--------+---+ | r 133 | a | | .... | | i 134 | l | | | | o 135 +--------------------+---+--------+----------+ r 136 | | | 137 x x x 138 Enterprise-edge Interfaces 140 Figure 1: Enterprise Router Architecture 142 Figure 1 above depicts the architectural model for an enterprise 143 router. As shown in the figure, an enterprise router may have a 144 variety of interface types including enterprise-edge, enterprise- 145 interior, provider-edge, internal-virtual, as well as VET interfaces 146 used for encapsulation of inner IP packets within outer IP headers. 147 The different types of interfaces are defined, and the 148 autoconfiguration mechanisms used for each type are specified. This 149 architecture applies equally for MANET routers, in which enterprise- 150 interior interfaces correspond to the wireless multihop radio 151 interfaces typically associated with MANETs. Out of scope for this 152 document is the autoconfiguration of provider interfaces, which must 153 be coordinated in a manner specific to the service provider's 154 network. 156 Enterprise routers must have a means for supporting both Provider- 157 Independent (PI) and Provider-Independent (PA) IP prefixes for 158 global-scope communications. This is especially true for enterprise 159 scenarios that involve mobility and multihoming. Ingress filtering 160 for multi-homed sites, adaptation based on authenticated ICMP 161 feedback from on-path routers, effective tunnel path MTU mitigations 162 and routing scaling suppression are also required in many enterprise 163 network scenarios. The VET specification provides a comprehensive 164 solution that addresses these issues and more. 166 VET represents a functional superset of 6over4 [RFC2529] and ISATAP 167 [RFC5214], and further supports additional encapsulations such as 168 IPsec [RFC4301], SEAL [I-D.templin-seal], etc. As a result, VET 169 provides a map-and-encaps architecture using IP-in-IP tunneling based 170 on both forwarding table and mapping service lookups (defined 171 herein). 173 The VET principles can be either directly or indirectly traced to the 174 deliberations of the ROAD group in January 1992, and also to still 175 earlier works including NIMROD [RFC1753], the Catenet model for 176 internetworking [CATENET][IEN48][RFC2775], etc. [RFC1955] captures 177 the high-level architectural aspects of the ROAD group deliberations 178 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 179 IPNG". 181 VET is related to the present-day activites of the IETF autoconf, 182 dhc, ipv6, manet and v6ops working groups, as well as the IRTF rrg 183 working group. 185 2. Terminology 187 The mechanisms within this document build upon the fundamental 188 principles of IP-within-IP encapsulation. The terms "inner" and 189 "outer" are used to respectively refer to the innermost IP {address, 190 protocol, header, packet, etc.} *before* encapsulation, and the 191 outermost IP {address, protocol, header, packet, etc.} *after* 192 encapsulation. VET also supports the inclusion of "mid-layer" 193 encapsulations between the inner and outer layers, including IPSec 194 [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) 195 [I-D.templin-seal], etc. 197 The terminology in the normative references apply; the following 198 terms are defined within the scope of this document: 200 subnetwork 201 the same as defined in [RFC3819]. 203 enterprise 204 the same as defined in [RFC4852]. 206 site 207 a logical and/or physical grouping of interfaces that connect a 208 topological area less than or equal to an enterprise in scope. A 209 site within an enterprise can in some sense be considered as an 210 enterprise unto itself. 212 Mobile Ad-hoc Network (MANET) 213 a connected topology of mobile or fixed routers that maintain a 214 routing structure among themselves over dynamic links, where a 215 wide variety of MANETs share common properties with enterprise 216 networks. Characteristics of MANETs are defined in [RFC2501], 217 Section 3. 219 enterprise/site/MANET 220 throughout the remainder of this document, the term "enterprise" 221 is used to collectively refer to any of enterprise/site/MANET, 222 i.e., the VET mechanisms and operational principles apply equally 223 to enterprises, sites and MANETs. 225 enterprise router 226 an Enterprise Interior Router, Enterprise Border Router, or 227 Enterprise Border Gateway. As depicted in Figure 1, an enterprise 228 router comprises a router function, a host function, one or more 229 enterprise-interior interfaces and zero or more internal virtual, 230 enterprise-edge, provider-edge and VET interfaces. 232 Enterprise Interior Router (EIR) 233 a fixed or mobile enterprise router that forwards packets over one 234 or more sets of enterprise-interior interface, where each set 235 connects to a distinct enterprise. 237 Enterprise Border Router (EBR) 238 an EIR that connects edge networks to the enterprise, and/or 239 connects multiple enterprises together. An EBR configures a 240 seperate VET interface over each set of enterprise-interior 241 interfaces that connect the EBR to each distinct enterprise. In 242 particular, an EBR may configure mulitple VET interfaces - one for 243 each distinct enterprise. All EBRs are also EIRs. 245 Enterprise Border Gateway (EBG) 246 an EBR that connects VET interfaces configued over child 247 enterprises to a provider network - either directly via a 248 provider-edge interface, or indirectly via another VET interface 249 configured over a parent enterprise. EBRs may act as EBGs on some 250 VET interfaces and as ordinary EBRs on other VET interfaces. All 251 EBGs are also EBRs. 253 EBGs provide packet forwarding, relaying and mapping services on 254 behalf of EBRs and ordinary VET hosts within the enterprise. A 255 "default mapper" [I-D.jen-apt] is a special case of an EBG that 256 performs all EBG services except forwarding packets to provider 257 networks. Default mappers must therefore configure a default 258 route via a fully-qualified EBG. 260 enterprise-interior interface 261 a EIR's attachment to a link within an enterprise. Packets sent 262 over enterprise-interior interfaces may be forwarded over multiple 263 additional enterprise-interior interfaces within the enterprise 264 before they are forwarded via an enterprise-edge interface, 265 provider-edge interface or a VET interface configured over a 266 different enterprise. 268 enterprise-edge interface 269 an EBR's attachment to a link (e.g., an ethernet, a wireless 270 personal area network, etc.) on an arbitrarily-complex edge 271 network that the EBR connects to an enterprise and/or to provider 272 networks. 274 internal-virtual interface 275 a virtual interface that is a special case of either an 276 enterprise-edge or an enterprise-interior interface. Internal- 277 virtual interfaces that are also enterprise-edge interfaces are 278 often loopback interfaces of some form. Internal-virtual 279 interfaces that are also enterprise-interior interfaces are often 280 tunnel interfaces of some form configured over another enterprise- 281 interior interface. 283 provider-edge interface 284 an EBR's attachment to the Internet, or to a provider network 285 outside of the enterprise via which the Internet can be reached. 287 Enterprise Local Address (ELA) 288 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 289 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 290 is assigned to an enterprise-interior interface and unique within 291 the enterprise. ELAs are used as identifiers for operating the 292 routing protocol and/or locators for packet forwarding within the 293 scope of the enterprise. ELAs are used as the *outer* IP 294 addresses during encapsulation, and can also be used as addresses 295 for enterprise-internal communications that do not require 296 encapsulation. 298 Provider-Independent (PI) prefix 299 an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 300 that is routable within a limited scope and may also appear in a 301 global mapping table. PI prefixes that can appear in a global 302 mapping table are typically delegated to an EBR by a registry, but 303 are not aggregated by a provider network. Local-use IPv6 and IPv4 304 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of 305 a PI prefix, but these typically do not appear in a global mapping 306 table. 308 Provider Aggregated (PA) prefix 309 an IPv6 or IPv4 prefix that is either derived from a PI prefix or 310 delegated directly to a provider network by a registry. 312 Virtual Enterprise Traversal (VET) 313 an abstraction that uses IP-in-IP encapsulation to span a multi- 314 link enterprise in a single (inner) IP hop. 316 VET interface 317 an EBR's Non-Broadcast, Multiple Access (NBMA) interface used for 318 Virtual Enterprise Traversal. The EBR configures a VET interface 319 over a set of underlying enterprise-interior interface(s) 320 belonging to the same enterprise. When there are multiple 321 distinct enterprises (each with their own distinct set of 322 enterprise-interior interfaces), the EBR configures a separate VET 323 interface over each set of enterprise-interior interfaces, i.e., 324 the EBR configures multiple VET interfaces. 326 The VET interface encapsulates each inner IP packet in any mid- 327 layer headers plus an outer IP header then forwards it on an 328 underlying enterprise-interior interface such that the TTL/Hop 329 Limit in the inner header is not decremented as the packet 330 traverses the enterprise. The VET interface therefore presents an 331 automatic tunneling abstraction that represents the enterprise as 332 a single IP hop. 334 VET host 335 any node (host or router) that configures a VET interface for host 336 operation only. Note that a single node may configure some of its 337 VET interfaces as host interfaces and others as router interfaces. 339 VET node 340 any node that configures and uses a VET interface. 342 The following additional acronyms are used throughout the document: 344 CGA - Cryptographically Generated Address 345 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 346 FIB - Forwarding Information Base 347 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 348 NBMA - Non-Broadcast, Multiple Access 349 ND - Neighbor Discovery 350 PA - Provider Aggregated 351 PI - Provider Independent 352 PIO - Prefix Information Option 353 PRL - Potential Router List 354 PRLNAME - Identifying name for the PRL (default is "isatap") 355 RIO - Route Information Option 356 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 357 SEAL - Subnetwork Encapsulation and Adaptation Layer 358 SLAAC - IPv6 StateLess Address AutoConfiguation 360 3. Enterprise Characteristics 362 Enterprises consist of links that are connected by enterprise routers 363 as depicted in Figure 1. All enterprise routers are also Enterprise 364 Interior Routers (EIRs), and typically participate in a routing 365 protocol over enterprise-interior interfaces to discover routes that 366 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 367 Border Routers (EBRs) are EIRs that connect edge networks and/or join 368 multiple enterprises together, while Enterprise Border Gateways 369 (EBGs) are EBRs that either directly or indirectly connect 370 enterprises to provider networks. A "default mapper" is a special 371 case of an EBG that performs all EBG services except forwarding 372 packets to provider networks. 374 An enterprise may be as simple as a small collection of enterprise 375 routers (and their attached edge networks); an enterprise may also 376 contain other enterprises and/or be a subnetwork of a larger 377 enterprise. An enterprise may further encompass a set of branch 378 offices and/or nomadic hosts connected to a home office over one or 379 several service providers, e.g., through Virtual Private Network 380 (VPN) tunnels. 382 Enterprises that comprise link types with sufficiently similar 383 properties (e.g., Layer-2 (L2) address formats, maximum transmission 384 units (MTUs), etc.) can configure a sub-IP layer routing service such 385 that IP sees the enterprise as an ordinary shared link the same as 386 for a (bridged) campus LAN. In that case, a single IP hop is 387 sufficient to traverse the enterprise without IP layer encapsulation. 389 Enterprises that comprise link types with diverse properties and/or 390 configure multiple IP subnets must also provide a routing service 391 that operates as an IP layer mechanism. In that case, multiple IP 392 hops may be necessary to traverse the enterprise such that specific 393 autoconfiguration procedures are necessary to avoid multilink subnet 394 issues [RFC4903]. In particular, we describe herein the use of IP- 395 in-IP encapsulation to span the enterprise in a single (inner) IP hop 396 in order to avoid the multilink subnet issues that arise when 397 enterprise-interior interfaces are used directly by applications. 399 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 400 both a host function and router function. The host function supports 401 global-scoped communications over any of the enterprise router's non- 402 enterprise-interior interfaces according to the weak end system model 403 [RFC1122] and also supports enterprise-local-scoped communications 404 over its enterprise-interior interfaces. The router function engages 405 in the enterprise-interior routing protocol, connects any of the 406 enterprise router's edge networks to the enterprise and may also 407 connect the enterprise to provider networks (see: Figure 1). 409 In addition to other interface types, VET nodes configure VET 410 interfaces that view all other VET nodes in an enterprise as single- 411 hop neighbors, where the enterprise can also appear as a single IP 412 hop within another enterprise. VET nodes configure a separate VET 413 interface for each distinct enterprise to which they connect, and 414 discover a list of EBRs for each VET interface that can be used for 415 forwarding packets to off-enterprise destinations. The following 416 sections present the Virtual Enterprise Traversal approach. 418 4. Autoconfiguration 420 EIRs, EBRs, EBGs, and VET hosts configure themselves for operation as 421 specified in the following subsections: 423 4.1. Enterprise Interior Router (EIR) Autoconfiguration 425 EIRs configure enterprise-interior interfaces and engage in routing 426 protocols over those interfaces. 428 When an EIR joins an enterprise, it first configures a unique IPv6 429 link-local address on each enterprise-interior interface that 430 requires an IPv6 link-local capability and an IPv4 link-local address 431 on each enterprise-interior interface that requires an IPv4 link- 432 local capability. IPv6 link-local address generation mechanisms that 433 provide sufficient uniqueness include Cryptographically Generated 434 Addresses (CGAs) [RFC3972], IPv6 Privacy Addresses [RFC4941], 435 StateLess Address AutoConfiguration (SLAAC) using EUI-64 interface 436 identifiers [RFC4862], etc. The mechanisms specified in [RFC3927] 437 provide an IPv4 link-local address generation capability. 439 Next, the EIR configures an Enterprise Local Address (ELA) of the 440 outer IP protocol version on each of its enterprise-interior 441 interfaces and engages in any routing protocols on those interfaces. 442 The EIR can configure an ELA via explicit management, DHCP 443 autoconfiguration, pseudo-random self-generation from a suitably 444 large address pool, or through an alternate autoconfiguration 445 mechanism. In some enterprise use cases (e.g., highly dynamic 446 MANETs), assignment of ELAs as singleton addresses (i.e., as /32s for 447 IPv4 and /128s for IPv6) may be necessary to avoid multilink subnet 448 issues. 450 EIRs that configure ELAs using DHCP may require relay support from 451 other EIRs within the enterprise; the EIR can alternatively configure 452 both a DHCP client and relay that are connected, e.g., via a pair of 453 back-to-back connected ethernet interfaces, a tun/tap interface, a 454 loopback interface, custom S/W coding, etc. For DHCPv6, relays that 455 do not already know the ELA of a server relay requests to the 456 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 457 relays that do not already know the ELA of a server relay requests to 458 the site-scoped IPv4 multicast group address 'All_DHCPv4_Servers' 459 (see: Section 6). DHCPv4 servers that delegate ELAs join the 460 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages 461 received for that group. 463 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 464 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 465 generation of ELAs for IPv4 can be from a large IPv4 private address 466 range (e.g., [RFC1918]). When self-generation is used alone, the EIR 467 must continuously monitor the ELAs for uniqueness, e.g., by 468 monitoring the routing protocol, but care must be taken in the 469 interaction of this monitoring with existing mechanisms. 471 A combined approach using both DHCP and self-generation is also 472 possible in which the EIR first self-generates a temporary ELA used 473 only for the purpose of procuring an actual ELA taken from a disjoint 474 addressing range. The EIR then assigns the temporary ELA to an 475 enterprise-interior interface, engages in the routing protocol and 476 performs a DHCP client/relay exchange using the temporary ELA as the 477 address of the relay. When the DHCP server delegates an actual ELA, 478 the EIR abandons the temporary ELA, assigns the actual ELA to the 479 enterprise-interior interface and re-engages in the routing protocol. 481 4.2. Enterprise Border Router (EBR) Autoconfiguration 483 EBRs are EIRs that configure VET interfaces over distinct sets of 484 underlying enterprise-interior interfaces; an EBR can connect to 485 multiple enterprises, in which case it would configure multiple VET 486 interfaces. EBRs perform the following autoconfiguration operations: 488 4.2.1. VET Interface Autoconfiguration 490 VET interface autoconfiguration entails: 1) interface initialization, 491 2) EBG discovery and enterprise identification, and 3) IPv6 stateless 492 address autoconfiguration. These functions are specified in the 493 following sections: 495 4.2.1.1. Interface Initialization 497 EBRs configure a VET interface over a set of underlying enterprise- 498 interior interfaces belonging to the same enterprise, where the VET 499 interface presents a Non-Broadcast, Multiple Access (NBMA) 500 abstraction in which all EBRs in the enterprise appear as single hop 501 neighbors through the use of IP-in-IP encapsulation. 503 When IPv6 and IPv4 are used as the inner/outer protocols 504 (respectively), the EBR autoconfigures an ISATAP link-local address 505 ([RFC5214], Section 6.2) on the VET interface to support packet 506 forwarding and operation of the IPv6 neighbor discovery protocol. 507 The ISATAP link-local address embeds an IPv4 ELA assigned to an 508 underlying enterprise-interior interface, and need not be checked for 509 uniqueness since the IPv4 ELA itself was already checked (see: 510 Section 4.1). Link-local address configuration for other inner/outer 511 IP protocol combinations is through administrative configuration or 512 through an unspecified alternate method. 514 After the EBR configures a VET interface, it can communicate with 515 other VET nodes as single-hop neighbors from the viewpoint of the 516 inner IP protocol. 518 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise 519 Identification 521 The EBR next discovers a list of EBGs for each of its VET interfaces. 522 The list can be discovered through information conveyed in the 523 routing protocol and/or through the Potential Router List (PRL) 524 discovery mechanisms outlined in ([RFC5214], Section 8.3.2). In 525 multicast-capable enterprises, they can also listen for 526 advertisements on the 'rasadv' [RASADV] IPv4 multicast group address. 528 In particular, whether or not routing information is available the 529 EBR can discover the list of EBGs in the PRL by resolving an 530 identifying name for the PRL ('PRLNAME') using an enterprise local 531 name resolution service (e.g., an enterprise-local DNS service, LLMNR 532 [RFC4759], etc.). 'PRLNAME' is formed as 'hostname.domainname', 533 where 'hostname' is an enterprise-specific name string and 534 'domainname' is an enterprise-specific DNS suffix when such a suffix 535 is available. 537 The EBR discovers 'PRLNAME' through manual configuration, a DHCP 538 option, 'rasadv' protocol advertisements, link-layer information 539 (e.g., an IEEE 802.11 SSID) or through some other means specific to 540 the enterprise. In the absence of other information, the EBR sets 541 the 'hostname' component of 'PRLNAME' to "isatap" and sets the 542 'domainname' component only if an enterprise-specifc DNS suffix 543 "example.com" is known (e.g., as "isatap.example.com"). 545 After discovering 'PRLNAME', the EBR can discover the list of EBGs by 546 resolving 'PRLNAME' to a list of IPv4 addresses through a name 547 service lookup. 'PRLNAME' as well as the ELAs of EBGs and/or the IP 548 prefixes they aggregate serve as an identifier for the enterprise. 550 4.2.2. Provider-Aggregated (PA) Prefix Autoconfiguration 552 EBRs can acquire Provider-Aggregated (PA) prefixes through 553 autoconfiguration exchanges with EBGs over VET interfaces. When IPv4 554 is used as the inner IP protocol, the EBR acquires PA prefixes via an 555 unspecified automated IPv4 prefix delegation exchange, explicit 556 management, etc. 558 When IPv6 is used as the inner IP protocol, the EBR acquires PA 559 prefixes via IPv6 Neighbor Discovery and DHCPv6 Prefix Delegation 560 exchanges. In particular, the EBR (acting as a requesting router) 561 can use DHCPv6 prefix delegation [RFC3633] over the VET interface to 562 obtain PA IPv6 prefixes from the server (acting as a delegating 563 router). 565 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 566 exchange [RFC3315]. For example, to perform the 2-message exchange 567 the EBR's DHCPv6 client forwards a Solicit message with an IA_PD 568 option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ 569 relay (see: Section 4.1). The relay then forwards the message over 570 the VET interface to the EBG. The forwarded Solicit message will 571 elicit a reply from the server containing PA IPv6 prefix delegations. 573 The EBR can propose a specific prefix to the DHCPv6 server per 574 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 575 available. The server will check the proposed prefix for consistency 576 and uniqueness, then return it in the reply to the EBR if it was able 577 to perform the delegation. 579 After the EBR receives PA prefix delegations, it can provision the 580 prefixes on its enterprise-edge interfaces as well as on other VET 581 interfaces for which it is configured as an EBG. 583 4.2.3. Provider-Independent (PI) Prefix Autoconfiguration 585 Independent of any PA prefixes, EBRs can acquire and use Provider- 586 Independent (PI) prefixes that are either delegated by a registration 587 authority or self-configured by the EBR 588 [RFC4193][I-D.ietf-ipv6-ula-central]). 590 When an EBR acquires a PI prefix, it must also obtain credentials 591 (e.g., from a certification authority) that it can use to prove 592 prefix ownership through Secure Neighbor Discovery (SEND) [RFC3971] 593 messaging. 595 The minimum-sized PI prefix that an EBR may acquire is a /56. 597 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 599 EBGs are EBRs that connect child enterprises to a provider network 600 via ordinay provider-edge interfaces and/or VET interfaces configured 601 over parent enterprises. EBGs autoconfigure provider-edge interfaces 602 in a manner that is specific to their provider connections, and 603 autoconfigure VET interfaces as specified in Section 4.2.1. EBGs 604 that support PA prefix delegation also configure a DHCP relay/server. 606 For each VET interface on which it is configured as an EBG, the EBG 607 must arrange to add its enterprise-interior interface addresses 608 (i.e., its ELAs) to the PRL (see: Section 4.2.1.2), and must maintain 609 these resource records in accordance with ([RFC5214], Section 9). In 610 particular, for each such VET interface the EBG adds its ELAs to name 611 service resource records for 'PRLNAME'. 613 4.4. VET Host Autoconfiguration 615 Nodes that cannot be attached via an EBR's enterprise-edge interface 616 (e.g., nomadic laptops that connect to a home office via a Virtual 617 Private Network (VPN)) can instead be configured for operation as a 618 simple host connected to the VET interface. Such VET hosts perform 619 the same VET interface autoconfiguration procedures as specified for 620 EBRs in Section 4.2.1, but they configure their VET interfaces as 621 host interfaces (and not router interfaces). VET hosts can then send 622 packets to other hosts on the VET interface, or to off-enterprise 623 destinations via a next-hop EBR. 625 Note that a node may be configured as a host on some VET interfaces 626 and as an EBR/EBG on other VET interfaces. 628 5. Internetworking Operation 630 Following the autoconfiguration procedures specified in Section 4, 631 EIRs, EBRs, EBGs and VET hosts engage in normal internetworking 632 operations as discussed in the following sections: 634 5.1. Routing Protocol Participation 636 Following autoconfiguration, EIRs engage in any routing protocols 637 over their enterprise-interior interfaces and forward outer IP 638 packets within the enterprise as for any ordinary router. 640 EBRs can additionally engage in any inner IP routing protocols over 641 enterprise-edge and provider-edge interfaces, and can use those 642 interfaces for forwarding inner IP packets to off-enterprise 643 destinations. Note that these inner IP routing protocols are 644 separate and distinct from any enterprise-interior routing protocols. 646 5.2. PA Prefix Maintenance 648 When an EBR uses DHCP prefix delegation to obtain PA prefixes via an 649 EBG, the DHCP server ensures that the delegations are unique and that 650 the EBG's router function will forward IP packets over the VET 651 interface to the correct EBR. 653 The DHCP prefix delegations remain active as long as the EBR 654 continues to issue renewals over the VET interface before lease 655 lifetimes expire. The lease lifetime also keeps the delegation state 656 active even if communications between the EBR and DHCP server are 657 disrupted for a period of time (e.g., due to an enterprise network 658 partition) before being reestablished (e.g., due to an enterprise 659 network merge). 661 Additionnally, ordinary requesting routers on enterprise edge 662 interfaces can maintain PA prefix delegations exactly as specified in 663 [RFC3633]. 665 5.3. IPv6 EBG Discovery 667 EBGs follow the router and prefix discovery procedures specified in 668 ([RFC5214], Section 8.2). They send solicited RAs over VET 669 interfaces for which they are configured as gateways with default 670 router lifetimes, with PIOs that contain PA prefixes for SLAAC, and 671 with any other required options/parameters. EBGs must set the 'M' 672 flag in RAs to 0, since the use of DHCPv6 for address configuration 673 on VET interfaces is undefined. EBGs can also include PIOs with the 674 'L' bit set to 0 and with a prefix such as '2001:DB8::/48' as a hint 675 of an aggregated prefix from which it is willing to delegate longer 676 PA prefixes. 678 VET nodes follow the router and prefix discovery procedures specified 679 in ([RFC5214], Section 8.3). They discover EBGs within the 680 enterprise as specified in Section 4.2.1.2, then perform SEND- 681 protected RS/RA exchanges with the EBGs to establish and maintain 682 default routes. In particular the VET node sends SEND-protected 683 unicast RS messages to EBGs over its VET interface(s) to receive 684 SEND-protected RAs. When the VET node receives an RA, it configures 685 a default route based on the Router Lifetime. If the RA contains 686 Prefix Information Options (PIOs) with the 'A' and 'L' bits set to 1, 687 the VET node also autoconfigures IPv6 addresses from the advertised 688 prefixes using SLAAC and assigns them to the VET interface. 689 Thereafter, the VET node accepts packets that are fowarded by EBGs 690 for which it has current default routing information (i.e., ingress 691 filtering is based on the default router relationship rather than a 692 prefix-specific ingress filter entry). 694 5.4. IPv6 PI Prefix Registration 696 When an EBR discovers EBGs for the enterprise, it must register its 697 PI prefixes by sending SEND-protected RAs to a set of one or more 698 EBGs with Route information Options (RIOs) [RFC4191] that contain the 699 EBR's PI prefixes. Each RA must include the ELA of an EBG as the 700 outer IP destination address and an ISATAP link-local address derived 701 from the ELA as the inner IP destination address. The RAs must also 702 include a CGA link-local inner source address along with a SEND 703 signature that can be used to validate the CGA plus any certificates 704 needed to prove ownership of the PI prefixes. The EBR additionally 705 tracks the set of EBGs that it sends RAs to so that it can send 706 subsequent RAs to the same set. 708 When the EBG receives the RA, it uses SEND to authenticate the 709 message; if the authentication fails, the EBG discards the RA. 710 Otherwise, the EBG installs the PI prefixes with their respective 711 lifetimes in its Forwarding Information Base (FIB) and configures 712 them for both ingress filtering [RFC3704] and forwarding purposes. 713 In particular, the EBG configures the FIB entries as ingress filter 714 rules to accept packets received on the VET interface with a source 715 address taken from the PI prefixes. It also configures the FIB 716 entries to forward packets received on other interfaces with a 717 destination address taken from the PI prefixes to the EBR that 718 registered the prefixes on the VET interface. 720 The EBG then publishes the PI prefixes in a distributed database 721 (e.g., in a private instance of a routing protocol in which only EBGs 722 participate, via an automated name service update mechanism 723 [RFC3007], etc.). For enterprises that are managed under a 724 cooperative administrative authority, the EBG also makes the PI 725 prefixes available for enterprise-local name service queries 726 [RFC1035]. For VET interfaces configured over enterprises that are 727 managed in a distributed fashion, EBG should instead respond directly 728 to LLMNR [RFC4759] name service queries. 730 To support name service queries, the EBG publishes each /56 prefix 731 taken from the PI prefixes as a seperate FQDN that consists of a 732 sequence of 14 nibbles in reverse order (i.e., the same as in 733 [RFC3596], Section 2.5) followed by the string 'PRLNAME'. For 734 example, when 'PRLNAME' is "isatap.example.com", the EBG publishes 735 the prefix '2001:DB8::/56' as: 736 '0.0.0.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. The EBG includes 737 the inner IPv6 CGA source address (e.g., in a DNS AAAA record) and 738 the outer IPv4 source address of the RA (e.g., in a DNS A resource 739 record) in each prefix publication. If the prefix was already 740 installed in the distributed database, the EBG instead adds the outer 741 IPv4 source address (e.g., in an additional DNS AAAA record) to the 742 pre-existing publication. 744 After the EBG authenticates the RA and publishes the PI prefixes, it 745 next acts as an EBR on the VET interfaces configured over any of its 746 provider enterprises and "relays" the RA to the default routers 747 (i.e., EBGs) on those interfaces. The EBR tracks the set of EBGs 748 that it relays the RA to, and should relay subsequent RAs to the same 749 set of EBGs. Each relayed RA is formatted exactly as for the 750 original RA, except that it uses the EBR's own CGA as the inner 751 source address and an ELA taken from the VET interface as the outer 752 IP source address. The RA authentication and PI prefix publication 753 recurses in this fashion and ends when a default mapping service for 754 the interdomain routing core is reached. (In the case of the global 755 Internet interdomain routing core, the 'PRLNAME' for the default 756 mapping service is "isatap.net".) 757 After the initial PI prefix registration, the EBR that owns the 758 prefix(es) must periodically send additional RAs to its set of EBGs 759 to refresh prefix lifetimes. As long as the EBGs have retained 760 sufficient state from a previous RA authentication as a means for 761 detecting spoofed packets, however, authentication of these 762 "keepalive" RAs is not required. 764 This procedure has a direct analogy in the Teredo method of 765 maintaining state in network middleboxes through the periodic 766 transmission of "bubbles" [RFC4380]. 768 5.5. IPv6 Next-Hop EBR Discovery 770 VET nodes discover destination-specific next-hop EBRs within the 771 enterprise by either querying the name service for the /56 IPv6 PI 772 prefix taken from a packet's destination address or by forwarding 773 packets via a default route to an EBG. For example, for the IPv6 774 destination address '2001:DB8:1:2::1' and 'PRLNAME' 775 "isatap.example.com" the VET node can lookup the domain name: 776 '0.0.1.0.0.0.8.b.d.0.1.0.0.2.isatap.example.com'. If the name 777 service lookup succeeds, it will return an IPv6 CGA address (e.g., in 778 a DNS AAAA record) and IPv4 addresses (e.g., in DNS A records) that 779 correspond to the ELAs assigned to enterprise interior interfaces of 780 next-hop EBRs to which the VET node can forward packets. 782 Alternatively, the VET node can simply forward an initial packet via 783 a default route to an EBG. The EBG will forward the packet to a 784 next-hop EBR on the VET interface and return a SEND-protected ICMPv6 785 Redirect [RFC4861]. If the packet's source address is on-link on the 786 VET interface, the EBG returns an ordinary "router-to-host" redirects 787 with the source address of the packet as its destination. If the 788 packet's source address is not on-link, the EBG instead returns a 789 "router-to-router" redirect with the link-local ISATAP address of the 790 previous-hop EBR as its destination. The EBG also includes in the 791 redirect one or more IPv6 Link-Layer Address Options (LLAOs) that 792 contain the IPv4 ELAs of potential next-hop EBRs arranged in order 793 from highest to lowest priority (i.e., the first LLAO contains the 794 highest priority ELA and the final LLAO option contains the lowest 795 priority). The LLAOs are formatted using a modified version of the 796 form specified in ( [RFC2529], Section 5) as shown in Figure 2: 798 +-------+-------+-------+-------+-------+-------+-------+-------+ 799 | Type |Length | TTL | IPv4 Address | 800 +-------+-------+-------+-------+-------+-------+-------+-------+ 802 Figure 2: VET Link-Layer Address Option Format 804 For each LLAO, the Type is set to 2 (for Target Link-Layer Address 805 Option), Length is set to 1, and IPv4 Address is set to the IPv4 ELA 806 of the next-hop EBR. TTL is set to the time in seconds that the 807 recipient may cache the ELA, where the value 65535 represents 808 infinity and the value 0 suspends forwarding through this ELA. 810 When a VET host receives an ordinay "router-to-host" redirect, it 811 processes the redirect exacly as specified in [RFC4861], Section 8. 812 When an EBR receives a "router-to-router" redirect, it discovers the 813 IPv4 ELA addresses of potential next-hop EBRs by examining the LLAOs 814 included in the redirect. The EBR then installs a FIB entry that 815 contains the /56 prefix of the destination address encoded in the 816 redirect and the list of IPv4 ELAs of potential next-hop EBRs. The 817 EBR then enables the FIB entry for forwarding to next-hop EBRs but 818 DOES NOT enable it for ingress filtering acceptance of packets from 819 next-hop EBRs (i.e., the forwarding determination is unidirectional). 820 The EBR then sends RAs over the VET interface to one or more of the 821 potential next-hop EBRs with a link-local ISATAP address that embeds 822 a next-hop EBR IPv4 ELA as the destination. The RAs must include the 823 EBR's CGA link-local address as the inner IPv6 source address along 824 with a SEND signature. The RAs must also include a Route Information 825 Option (RIO) [RFC4191] that contains the /56 PI prefix of the 826 original packet's source address. 828 When a next-hop EBR receives the RA, it uses SEND to verify the CGA 829 then performs a name service lookup on the prefix in the RIO. If the 830 name service returns the correct CGA and ELA information, the next- 831 hop EBR then installs the prefix in the RIO in its FIB and enables 832 the FIB entry for ingress filtering but DOES NOT enable it for 833 forwarding purposes. 835 After an EBR sends initial RAs following a redirect, it should send 836 periodic RAs to refresh the next-hop EBR's ingress filter prefix 837 lifetimes as long as traffic is flowing. 839 5.6. Forwarding Packets 841 VET nodes forward packets by consulting the FIB to determine a 842 specific EBR/EBG as the next-hop router on a VET interface. When 843 multiple next-hop routers are available, VET nodes can use default 844 router preferences, routing protocol information, traffic engineering 845 configurations, etc. to select the best exit router. When there is 846 no FIB information other than ::/0 available, VET nodes can discover 847 the next-hop EBR/EBG through the mechanisms specified in Section 5.3 848 and Section 5.5. 850 VET interfaces encapsulate inner IP packets in any mid-layer headers 851 followed by an outer IP header according to the specific 852 encapsulation type (e.g., [RFC4301][RFC5214][I-D.templin-seal]); they 853 next submit the encapsulated packet to the outer IP forwarding engine 854 for transmission on an underlying enterprise-interior interface. 856 For forwarding to next-hop addresses over VET interfaces that use 857 IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination 858 address (i.e., the IPv4 ELA of the next-hop EBR) through static 859 extraction of the IPv4 address embedded in the next-hop ISATAP 860 address. For other IP-in-IP encapsulations, determination of the 861 outer destination address is through administrative configuration or 862 through an unspecified alternate method. When there are multiple 863 candidate destination ELAs available, the VET node should only select 864 an ELA for which there is current forwarding information in the outer 865 IP protocol FIB. 867 5.7. SEAL Encapsulation 869 VET nodes that do not use IPsec encapsulation should use SEAL 870 encapsulation [I-D.templin-seal] in conjunction with packet 871 forwarding over VET interfaces to accommdate path MTU diversity, to 872 detect source address spoofing, and to monitor next-hop EBR 873 reachability. SEAL encapsulation maintains a unidirectional and 874 monotonically-incrementing per-packet identification value known as 875 the 'SEAL_ID'. When a VET node that uses SEAL encapsulation sends a 876 SEND-protected Router Advertisement (RA) or Router Solicitation (RS) 877 message to another VET node, both nodes cache the new SEAL_ID as per- 878 tunnel state used for maintaining a window of unacknowledged 879 SEAL_IDs. 881 In terms of security, when a VET node receives an ICMP message, it 882 can confirm that the packet-in-error within the ICMP message 883 corresponds to one of its recently-sent packets by examining the 884 SEAL_ID along with source and destination addresses, etc. 885 Additionally, a next-hop EBR can track the SEAL_ID in packets 886 received from EBRs for which there is an ingress filter entry and 887 discard packets that have SEAL_ID values outside of the current 888 window. 890 In terms of next-hop reachability, an EBR can set the SEAL 891 "Acknowledgement Requested" bit in messages to receive confirmation 892 that a next-hop EBR is reachable. Setting the "Acknowledgement 893 Requested" bit is also used as the method for maintaining the window 894 of outstanding SEAL_ID's. 896 5.8. Generating Errors 898 When an EBR receives a packet over a VET interface and there is no 899 matching ingress filter entry, it drops the packet and returns an 900 ICMPv6 [RFC4443] "Destination Unreachable; Source address failed 901 ingress/egress policy" message to the previous hop EBR subject to 902 rate limiting. 904 When an EBR receives a packet over a VET interface, and there is no 905 longest-prefix-match FIB entry for the destination, it returns an 906 ICMPv6 "Destination Unreachable; No route to destination" message to 907 the previous hop EBR subject to rate limiting. 909 When an EBR receives a packet over a VET interface and the longest- 910 prefix-match FIB entry for the destination is configured over the 911 same VET interface the packet arrived on, the EBR forwards the packet 912 then (if the FIB prefix is longer than ::/0) sends a SEND-protected 913 router-to-router ICMPv6 Redirect message to the previous hop EBR as 914 specified in Section 5.5. 916 Generation of other ICMPv6 messages (e.g., ICMPv6 "Packet Too Big") 917 is the same as for any IPv6 interface. 919 5.9. Processing Errors 921 When an EBR receives an ICMPv6 "Destination Unreachable; Source 922 address failed ingress/egress policy" message from a next-hop EBR, 923 and there is a longest-prefix-match FIB entry for the original 924 packet's destination that is more-specific than ::/0, the EBR 925 discards the message and marks the FIB entry for the destination as 926 "forwarding suspended" for the ELA taken from the source address of 927 the ICMPv6 message. The EBR should then allow subsequent packets to 928 flow through different ELAs associated with the FIB entry until it 929 forwards a new SEND-protected RA to the suspended ELA. If the EBR 930 receives excessive ICMPv6 ingress policy errors through multiple ELAs 931 associated with the same FIB entry, it should delete the FIB entry 932 and allow subsequent packets to flow through an EBG. 934 When a VET node receives an ICMPv6 "Destination Unreachable; No route 935 to destination" message from a next-hop EBR, it forwards the ICMPv6 936 message to the source of the original packet as normal. If the EBR 937 has longest-prefix-match FIB entry for the original packet's 938 destination that is more-specific than ::/0, the EBR also deletes the 939 FIB entry. 941 When an EBR receives an ICMPv6 Redirect with a valid SEND signature, 942 it processes the packet as specified in Section 5.5. 944 When an EBG receives new mapping information for a specific 945 destination prefix, it can propagate the update to other EBRs/EBGs by 946 sending an ICMPv6 redirect message to the 'All Routers' link-local 947 multicast address with a LLAO with the TTL for the unreachable LLAO 948 set to zero, and with a NULL packet in error. 950 Additionally, a VET node may receive ICMPv4 [RFC0792] "Destination 951 Unreachable; net / host unreachable" messages from an EIR indicating 952 that the path to a VET neighbor may be failing. The EBR should first 953 check identifying information in the message (e.g., the SEAL_ID, 954 IPsec sequence number, source address of the original packet if 955 available, etc.) before accepting it, then should mark the longest- 956 prefix-match FIB entry for the destination as "forwarding suspended" 957 for the ELA destination address of the ICMPv4 packet-in-error. If 958 the EBR receives excessive ICMPv4 unreachable errors through multiple 959 ELAs associated with the same FIB entry, it should delete the FIB 960 entry and allow subsequent packets to flow through a different route. 962 5.10. Mobility and Multihoming Considerations 964 EBRs can retain their PI prefixes as they travel between distinct 965 enterprise networks as long as they register the prefixes with new 966 EBGs and (preferrably) withdraw the prefixes from old EBGs prior to 967 departure. Prefix registration with new EBGs is coordinated exactly 968 as specified in Section 5.4; prefix withdrawl from old EBGs is simply 969 through re-announcing the PI prefixes with zero lifetimes. 971 Since EBRs can move about independently of one another, stale FIB 972 entry state may be left in VET nodes when a neighboring EBR departs. 973 Additionally, EBRs can lose state for various reasons, e.g., power 974 failure, machine reboot, etc. For this reason, EBRs are advised to 975 set relatively short PI prefix lifetimes in RIO options, and to send 976 additional RAs to refresh lifetimes before they expire. (EBRs should 977 place conservative limits on the RAs they send to reduce congestion, 978 however.) 980 EBRs may register their PI prefixes with multiple EBGs for 981 multihoming purposes. EBRs should only forward packets via EBGs with 982 which it has registered its PI prefixes, since other EBGs may drop 983 the packets and return ICMPv6 "Destination Unreachable; Source 984 address failed ingress/egress policy" messages. 986 EBRs can also act as delegating routers to sub-delegate portions of 987 their PI prefixes to requesting routers on their enterprise edge 988 interfaces and on VET interfaces for which they are configured as 989 EBGs. In this sense, the sub-delegations of an EBR's PI prefixes 990 become the PA prefixes for downstream-dependent nodes. Downstream- 991 dependent nodes that travel with a mobile provider EBR can continue 992 to use addresses configured from PA prefixes; downstream-dependent 993 nodes that move away from their provider EBR must perform address/ 994 prefix renumbering when they assocate with a new provider. 996 The EBGs of a multi-homed enterprise should participate in a private 997 inner IP routing protocol instance between themselves (possibly over 998 an alternate topology) to accommodate enterprise partitions/merges as 999 well as intra-enterprise mobility events. These peer EBGs should 1000 accept packets from one another without respect to the destination 1001 (i.e., ingress filtering is based on the peering relationship rather 1002 than a prefix-specific ingress filter entry). 1004 5.11. Enterprise-Local Communications 1006 When permitted by policy, end systems that configure the endpoints of 1007 enterprise-local communications can avoid VET interface encapsulation 1008 by directly invoking the outer IP protocol using ELAs assigned to 1009 their enterprise-interior interfaces. For example, when the outer 1010 protocol is IPv4, end systems can use IPv4 ELAs for enterprise-local 1011 communications over their enterprise-interior interfaces without 1012 using encapsulation. 1014 5.12. Multicast 1016 In multicast-capable deployments, EIRs provide an enterprise-wide 1017 multicasting service (e.g., Simplified Multicast Forwarding (SMF) 1018 [I-D.ietf-manet-smf], PIM routing, DVMRP routing, etc.) over their 1019 enterprise-interior interfaces such that outer IP multicast messages 1020 of site- or greater scope will be propagated across the enterprise. 1021 For such deployments, VET nodes can also provide an inner IP 1022 multicast/broadcast capability over their VET interfaces through 1023 mapping of the inner IP multicast address space to the outer IP 1024 multicast address space. In that case, operation of link- or greater 1025 scoped inner IP multicasting services (e.g., a link-scoped neighbor 1026 discovery protocol) over the VET interface is available, but link- 1027 scoped services should be used sparingly to minimize enterprise-wide 1028 flooding. 1030 VET nodes encapsulate inner IP multicast messages sent over the VET 1031 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 1032 outer IP header with a site-scoped outer IP multicast address as the 1033 destination. For the case of IPv6 and IPv4 as the inner/outer 1034 protocols (respectively), [RFC2529] provides mappings from the IPv6 1035 multicast address space to a site-scoped IPv4 multicast address space 1036 (for other IP-in-IP encapsulations, mappings are established through 1037 administrative configuration or through an unspecified alternate 1038 method). 1040 Multicast forwarding for inner IP multicast groups over outer IP 1041 multicast groups can be accommodated, e.g. through VET interface 1042 snooping of inner multicast group membership and routing protocol 1043 control messages. To support inner-to-outer IP multicast forwarding, 1044 VET interface acts as a virtual outer IP multicast host connected to 1045 its underlying enterprise-interior interfaces. When the VET 1046 interface detects inner IP multicast group joins or leaves, it 1047 forwards corresponding outer IP multicast group membership reports 1048 for each enterprise-interior interface over which the VET interface 1049 is configured. If the VET node is configured as an outer IP 1050 multicast router on the underlying enterprise-interior interfaces, 1051 the VET interface forwards locally looped-back group membership 1052 reports to the outer IP multicast routing process. If the VET node 1053 is configued as a simple outer IP multicast host, the VET interface 1054 instead fowards actual group membership reports (e.g., IGMP messages) 1055 directly over each of the underlying enterprise-interior interfaces. 1057 Since inner IP multicast groups are mapped to site-scoped outer IP 1058 multicast groups, the VET node must ensure that the site-scope outer 1059 IP multicast messages received on the enterprise-interior interfaces 1060 for one VET interface do not "leak over" to the enterprise-interior 1061 interfaces of another VET interface. This is accomodated through 1062 normal site-scoped outer IP multicast group filtering at enterprise- 1063 interior interface boundaries. 1065 5.13. Service Discovery 1067 VET nodes can peform enterprise-wide service discovery using a 1068 suitable name-to-address resolution service. Examples of flooding- 1069 based services include the use of LLMNR [RFC4759] over the VET 1070 interface or mDNS [I-D.cheshire-dnsext-multicastdns] over an 1071 underlying enterprise-interior interface. More scalable and 1072 efficient service discovery mechanisms are for further study. 1074 5.14. Enterprise Partitioning 1076 EBGs can physically partition an enterprise by configuring multiple 1077 VET interfaces over multiple distinct sets of underlying interfaces. 1078 In that case, each partition (i.e., each VET interface) must 1079 configure its own distinct 'PRLNAME' (e.g., 1080 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). 1082 EBGs can logically partition an enterprise using a single VET 1083 interface by sending RAs with PIOs containing different IPv6 PA 1084 prefixes to group nodes into different logical partitions. EBGs can 1085 identify partitions, e.g., by examining IPv4 ELA prefixes, observing 1086 the interfaces over which RSs are received, etc. In that case, a 1087 single 'PRLNAME' can cover all partitions. 1089 6. IANA Considerations 1091 A Site-Local Scope IPv4 multicast group ('All_DHCPv4_Servers') for 1092 DHCPv4 server discovery is requested. The allocation should be taken 1093 from the 239.255.000.000-239.255.255.255 Site-Local Scope range in 1094 the IANA 'multicast-addresses' registry. 1096 7. Security Considerations 1098 Security considerations for MANETs are found in [RFC2501]. 1100 Security considerations with tunneling that apply also to VET are 1101 found in [RFC2529][RFC5214]. In particular, VET nodes must verify 1102 that the outer IP source address of a packet received on a VET 1103 interface is correct for the inner IP source address using the 1104 procedures specified in ([RFC5214], Section 7.3) in conjunction with 1105 the ingress filtering mechanisms specified in this document. 1107 SEND [RFC3971] and SEAL Section 5.7 provide additional securing 1108 mitigations to detect source address spoofing and bogus RA messages 1109 sent by rogue routers. 1111 Rogue routers can send bogus RA messages with spoofed ELA source 1112 addresses that can consume network resources and cause EBGs to 1113 perform extra work. Nonetheless, EBGs should not "blacklist" such 1114 ELAs, as that may result in a denial of service to the ELAs' 1115 legitimate owners. 1117 8. Related Work 1119 Brian Carpenter and Cyndi Jung introduced the concept of intra-site 1120 automatic tunneling in [RFC2529]; this concept was later called: 1121 "Virtual Ethernet" and investigated by Quang Nguyen under the 1122 guidance of Dr. Lixia Zhang. Subsequent works by these authors and 1123 their colleagues have motivated a number of foundational concepts on 1124 which this work is based. 1126 Telcordia has proposed DHCP-related solutions for MANETs through the 1127 CECOM MOSAIC program. 1129 The Naval Research Lab (NRL) Information Technology Division uses 1130 DHCP in their MANET research testbeds. 1132 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 1133 pertaining to tunneling mechanisms. 1135 An automated IPv4 prefix delegation mechanism is proposed in 1136 [I-D.ietf-dhc-subnet-alloc]. 1138 MANET link types are discussed in [I-D.clausen-manet-linktype]. 1140 Various proposals within the IETF have suggested similar mechanisms. 1142 9. Acknowledgements 1144 The following individuals gave direct and/or indirect input that was 1145 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, Brian 1146 Carpenter, James Bound, Thomas Clausen, Thomas Goff, Joel Halpern, 1147 Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe 1148 Macker, David Meyer, Thomas Narten, Pekka Nikander, Alexandru 1149 Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole Troan, 1150 Michaela Vanderveen, Lixia Zhang and others in the IETF AUTOCONF and 1151 MANET working groups. Many others have provided guidance over the 1152 course of many years. 1154 10. Contributors 1156 The following individuals have contributed to this document: 1158 Eric Fleischman (eric.fleischman@boeing.com) 1159 Thomas Henderson (thomas.r.henderson@boeing.com) 1160 Steven Russert (steven.w.russert@boeing.com) 1161 Seung Yi (seung.yi@boeing.com) 1163 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 1164 of the document. 1166 11. References 1168 11.1. Normative References 1170 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1171 September 1981. 1173 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1174 RFC 792, September 1981. 1176 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1177 converting network protocol addresses to 48.bit Ethernet 1178 address for transmission on Ethernet hardware", STD 37, 1179 RFC 826, November 1982. 1181 [RFC1035] Mockapetris, P., "Domain names - implementation and 1182 specification", STD 13, RFC 1035, November 1987. 1184 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1185 RFC 2131, March 1997. 1187 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1188 (IPv6) Specification", RFC 2460, December 1998. 1190 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1191 Update", RFC 3007, November 2000. 1193 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1194 and M. Carney, "Dynamic Host Configuration Protocol for 1195 IPv6 (DHCPv6)", RFC 3315, July 2003. 1197 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1198 "DNS Extensions to Support IP Version 6", RFC 3596, 1199 October 2003. 1201 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1202 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1203 December 2003. 1205 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1206 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1208 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1209 RFC 3972, March 2005. 1211 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1212 More-Specific Routes", RFC 4191, November 2005. 1214 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1215 Architecture", RFC 4291, February 2006. 1217 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1218 Message Protocol (ICMPv6) for the Internet Protocol 1219 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1221 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1222 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1223 September 2007. 1225 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1226 Address Autoconfiguration", RFC 4862, September 2007. 1228 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1229 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1230 March 2008. 1232 11.2. Informative References 1234 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1235 Switching Networks", May 1974. 1237 [I-D.cheshire-dnsext-multicastdns] 1238 Cheshire, S. and M. Krochmal, "Multicast DNS", 1239 draft-cheshire-dnsext-multicastdns-07 (work in progress), 1240 September 2008. 1242 [I-D.clausen-manet-linktype] 1243 Clausen, T., "The MANET Link Type", 1244 draft-clausen-manet-linktype-00 (work in progress), 1245 October 2008. 1247 [I-D.ietf-autoconf-manetarch] 1248 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1249 Network Architecture", draft-ietf-autoconf-manetarch-07 1250 (work in progress), November 2007. 1252 [I-D.ietf-dhc-subnet-alloc] 1253 Johnson, R., "Subnet Allocation Option", 1254 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1255 July 2008. 1257 [I-D.ietf-ipv6-ula-central] 1258 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 1259 Addresses", draft-ietf-ipv6-ula-central-02 (work in 1260 progress), June 2007. 1262 [I-D.ietf-manet-smf] 1263 Macker, J. and S. Team, "Simplified Multicast Forwarding 1264 for MANET", draft-ietf-manet-smf-08 (work in progress), 1265 November 2008. 1267 [I-D.ietf-v6ops-tunnel-security-concerns] 1268 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1269 Concerns With IP Tunneling", 1270 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1271 progress), October 2008. 1273 [I-D.jen-apt] 1274 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1275 L. Zhang, "APT: A Practical Transit Mapping Service", 1276 draft-jen-apt-01 (work in progress), November 2007. 1278 [I-D.templin-seal] 1279 Templin, F., "The Subnetwork Encapsulation and Adaptation 1280 Layer (SEAL)", draft-templin-seal-23 (work in progress), 1281 August 2008. 1283 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1284 July 1978. 1286 [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) 1287 Protocol Specification", October 2008. 1289 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1290 Communication Layers", STD 3, RFC 1122, October 1989. 1292 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1293 Routing and Addressing Architecture", RFC 1753, 1294 December 1994. 1296 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1297 E. Lear, "Address Allocation for Private Internets", 1298 BCP 5, RFC 1918, February 1996. 1300 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1301 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1303 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1304 (MANET): Routing Protocol Performance Issues and 1305 Evaluation Considerations", RFC 2501, January 1999. 1307 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1308 Domains without Explicit Tunnels", RFC 2529, March 1999. 1310 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1311 February 2000. 1313 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1314 via IPv4 Clouds", RFC 3056, February 2001. 1316 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1317 Networks", BCP 84, RFC 3704, March 2004. 1319 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1320 RFC 3753, June 2004. 1322 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1323 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1324 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1325 RFC 3819, July 2004. 1327 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1328 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1329 May 2005. 1331 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1332 Addresses", RFC 4193, October 2005. 1334 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1335 Internet Protocol", RFC 4301, December 2005. 1337 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1338 Network Address Translations (NATs)", RFC 4380, 1339 February 2006. 1341 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 1342 Indicator Parameter for the "tel" URI", RFC 4759, 1343 December 2006. 1345 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1346 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1347 Focus", RFC 4852, April 2007. 1349 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1350 June 2007. 1352 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1353 Extensions for Stateless Address Autoconfiguration in 1354 IPv6", RFC 4941, September 2007. 1356 Appendix A. Duplicate Address Detection (DAD) Considerations 1358 A-priori uniqueness determination (also known as "pre-service DAD") 1359 for an ELA assigned on an enterprise-interior interface would require 1360 either flooding the entire enterprise or somehow discovering a link 1361 in the enterprise on which a node that configures a duplicate address 1362 is attached and performing a localized DAD exchange on that link. 1363 But, the control message overhead for such an enterprise-wide DAD 1364 would be substantial and prone to false-negatives due to packet loss 1365 and intermittent connectivity. An alternative to pre-service DAD is 1366 to autoconfigure pseudo-random ELAs on enterprise-interior interfaces 1367 and employ a passive in-service DAD (e.g., one that monitors routing 1368 protocol messages for duplicate assignments). 1370 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 1371 CGAs, IPv6 privacy addresses, etc. with very small probability of 1372 collision. Pseudo-random IPv4 ELAs can be generated through random 1373 assignment from a suitably large IPv4 prefix space. 1375 Consistent operational practices can assure uniqueness for EBG- 1376 aggregated addresses/prefixes, while statistical properties for 1377 pseudo-random address self-generation can assure uniqueness for the 1378 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 1379 ELA delegation authority should be used when available, while a 1380 passive in-service DAD mechanism should be used to detect ELA 1381 duplications when there is no ELA delegation authority. 1383 Appendix B. Change Log 1385 (Note to RFC editor - this section to be removed before publication 1386 as an RFC.) 1388 Changes from -28 to 29: 1390 o Updates on processing/receiving errors. 1392 Changes from -27 to 28: 1394 o Introduced concept of a default mapper. 1396 Changes from -26 to 27: 1398 o Introduced new model for PI prefix management. 1400 o Teredo mechanisms used in conjunction with ISATAP ("teratap"? 1401 "isado"?) 1403 Changes from -25 to 26: 1405 o Clarifications on Router Discovery and Ingress FIltering. 1407 o Mechanisms for detecting locator liveness 1409 o Mechanisms for avoiding state synchonization requirements. 1411 Changes from -23 to 24: 1413 o Clarifications on router discovery. 1415 Changes from -22 to 23: 1417 o Clarifications on prefix mapping. 1419 Changes from -21 to 22: 1421 o Using SEAL to secure VET 1423 Changes from -20 to 21: 1425 o Enterprise partitioning. 1427 o Mapping and name service management. 1429 Changes from -18 to 20: 1431 o Added support for simple hosts. 1433 o Added EBG name service maintenace procedures 1435 o Added router and prefix maintenace procedures 1437 Changes from -17 to 18: 1439 o adjusted section headings to group autoconf operations under EIR/ 1440 EBR/EBG. 1442 o clarified M/O bits 1444 o clarified EBG roles 1446 Changes from -15 to 17: 1448 o title change to "Virtual Enterprise Traversal (VET)". 1450 o changed document focus from MANET-centric to the much-broader 1451 Enterprise-centric, where "Enterprise" is understood to also cover 1452 a wide range of MANET types. 1454 Changes from -14 to 15: 1456 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 1458 o Address review comments 1460 Changes from -12 to 14: 1462 o title change to "The MANET Virtual Ethernet Abstraction". 1464 o Minor section rearrangement. 1466 o Clartifications on portable and self-configured prefixes. 1468 o Clarifications on DHCPv6 prefix delegation procedures. 1470 Changes from -11 to 12: 1472 o title change to "MANET Autoconfiguration using Virtual Ethernet". 1474 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 1475 delegation mechanism. 1477 o IPv6 SLAAC for address autoconfiguration on the VET interface. 1479 o fixed editorials based on comments received. 1481 Changes from -10 to 11: 1483 o removed the transparent/opaque VET portal abstractions. 1485 o removed routing header as an option for MANET exit router 1486 selection. 1488 o included IPv6 SLAAC as an endorsed address configuration mechanism 1489 for the VET interface. 1491 Changes from -08 to -09: 1493 o Introduced the term "VET". 1495 o Changed address delegation language to speak of "MNBR-aggregated" 1496 instead of global/local. 1498 o Updated figures 1-3. 1500 o Explained why a MANET interface is "neutral". 1502 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 1503 DHCPv4 servers; not relays. 1505 Changes from -07 to -08: 1507 o changed terms "unenhanced" and "enhanced" to "transparent" and 1508 "opaque". 1510 o revised MANET Router diagram. 1512 o introduced RFC3753 terminology for Mobile Router; ingress/egress 1513 interface. 1515 o changed abbreviations to "MNR" and "MNBR". 1517 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1519 o rearranged Section 3.1. 1521 o various minor text cleanups 1523 Changes from -06 to -07: 1525 o added MANET Router diagram. 1527 o added new references 1529 o various minor text cleanups 1531 Changed from -05 to -06: 1533 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1535 o minor changes to preserve generality 1537 Changed from -04 to -05: 1539 o introduced conceptual "virtual ethernet" model. 1541 o support "raw" and "cooked" modes as equivalent access methods on 1542 the virutal ethernet. 1544 Changed from -03 to -04: 1546 o introduced conceptual "imaginary shared link" as a representation 1547 for a MANET. 1549 o discussion of autonomous system and site abstractions for MANETs 1551 o discussion of autoconfiguration of CGAs 1553 o new appendix on IPv6 StateLess Address AutoConfiguration 1555 Changes from -02 to -03: 1557 o updated terminology based on RFC2461 "asymmetric reachability" 1558 link type; IETF67 MANET Autoconf wg discussions. 1560 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1561 Address Detection 1563 o relaxed DHCP server deployment considerations allow DHCP servers 1564 within the MANET itself 1566 Changes from -01 to -02: 1568 o minor updates for consistency with recent developments 1570 Changes from -00 to -01: 1572 o new text on DHCPv6 prefix delegation and multilink subnet 1573 considerations. 1575 o various editorial changes 1577 Author's Address 1579 Fred L. Templin (editor) 1580 Boeing Research and Technology 1581 P.O. Box 3707 MC 7L-49 1582 Seattle, WA 98124 1583 USA 1585 Email: fltemplin@acm.org