idnits 2.17.1 draft-templin-autoconf-dhcp-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1110. 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 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 (October 17, 2008) is 5670 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 150, but not defined == Unused Reference: 'I-D.ietf-autoconf-manetarch' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 852, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-07 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 ** 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 (-14) exists of draft-ietf-manet-smf-07 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 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 Phantom Works 4 Intended status: Informational October 17, 2008 5 Expires: April 20, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-18.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 20, 2009. 35 Abstract 37 Enterprise networks connect routers over various link types, and may 38 also connect to provider networks and/or the global Internet. 39 Routers in enterprise networks must have a way to automatically 40 provision IP addresses/prefixes and other information, and must also 41 support post-autoconfiguration operations even for highly-dynamic 42 networks. This document specifies a Virtual Enterprise Traversal 43 (VET) abstraction for autoconfiguration and operation of routers in 44 enterprise networks. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Enterprise Characteristics . . . . . . . . . . . . . . . . . . 7 51 4. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 8 52 4.1. Enterprise Interior Router (EIR) Autoconfiguration . . . . 8 53 4.2. Enterprise Border Router (EBR) Autoconfiguration . . . . . 10 54 4.2.1. VET Interface Autoconfiguration . . . . . . . . . . . 10 55 4.2.2. Enterprise Border Gateway Discovery and Enterprise 56 Identification . . . . . . . . . . . . . . . . . . . . 11 57 4.2.3. Inner IP Address/Prefix Delegation and Maintenance . . 11 58 4.2.4. Portable Inner IP Addresses/Prefixes . . . . . . . . . 13 59 4.2.5. Enterprise-edge Interface Autoconfiguration . . . . . 13 60 4.3. Enterprise Border Gateway (EBG) Autoconfiguration . . . . 13 61 5. Post-Autoconfiguration Operation . . . . . . . . . . . . . . . 14 62 5.1. Forwarding Packets to Destinations Outside of the 63 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.2. Enterprise-Local Communications . . . . . . . . . . . . . 15 65 5.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 66 5.4. Service Discovery . . . . . . . . . . . . . . . . . . . . 15 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 71 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 75 Appendix A. Duplicate Address Detection (DAD) Considerations . . 20 76 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 Intellectual Property and Copyright Statements . . . . . . . . . . 24 80 1. Introduction 82 Enterprise networks [RFC4852] connect routers over various link types 83 (see: [RFC4861], Section 2.2). Certain Mobile Ad-hoc Networks 84 (MANETs) [RFC2501] can be considered as a challenging example of an 85 enterprise network, in that their topologies may change dynamically 86 over time and that they may employ little/no active management by a 87 centralized network administrative authority. These specialized 88 characteristics for MANETs require careful consideration, but the 89 same principles apply equally to other enterprise network scenarios. 91 This document specifies a Virtual Enterprise Traversal (VET) 92 abstraction for autoconfiguration and runtime operation of enterprise 93 routers over various interface types, where addresses of different 94 scopes may be assigned on various types of interfaces with diverse 95 properties. Both IPv4 [RFC0791] and IPv6 [RFC2460] are discussed 96 within this context. The use of standard DHCP [RFC2131][RFC3315] and 97 neighbor discovery [RFC0826][RFC4861] mechanisms is assumed unless 98 otherwise specified. 100 Provider-edge Interfaces 101 x x x 102 | | | 103 +--------------------+---+--------+----------+ E 104 | | | | | n 105 | I | | .... | | t 106 | n +---+---+--------+---+ | e 107 | t | +--------+ /| | r 108 | e I x----+ | Host | I /*+------+--< p I 109 | r n | |Function| n|**| | r n 110 | n t | +--------+ t|**| | i t 111 | a e x----+ V e|**+------+--< s e 112 | l r . | E r|**| . | e r 113 | f . | T f|**| . | f 114 | V a . | +--------+ a|**| . | I a 115 | i c . | | Router | c|**| . | n c 116 | r e x----+ |Function| e \*+------+--< t e 117 | t s | +--------+ \| | e s 118 | u +---+---+--------+---+ | r 119 | a | | .... | | i 120 | l | | | | o 121 +--------------------+---+--------+----------+ r 122 | | | 123 x x x 124 Enterprise-edge Interfaces 126 Figure 1: Enterprise Router Architecture 128 Figure 1 above depicts the architectural model for an enterprise 129 router. As shown in the figure, an enterprise router may have a 130 variety of interface types including enterprise-edge, enterprise- 131 interior, provider-edge, internal-virtual, as well as VET interfaces 132 used for encapsulation of inner IP packets within outer IP headers. 133 The different types of interfaces are defined, and the 134 autoconfiguration mechanisms used for each type are specified. This 135 architecture applies equally for MANET routers, in which enterprise- 136 interior interfaces correspond to the wireless multihop radio 137 interfaces typically associated with MANETs. Out of scope for this 138 document is the autoconfiguration of provider interfaces, which must 139 be coordinated in a manner specific to the service provider's 140 network. 142 The VET specification represents a functional superset of 6over4 143 [RFC2529] and ISATAP [RFC5214], and further supports additional 144 encapsulations such as IPsec [RFC4301], SEAL [I-D.templin-seal], etc. 146 The VET principles can be either directly or indirectly traced to the 147 deliberations of the ROAD group in January 1992, and likely also to 148 still earlier works. [RFC1955] captures the high-level architectural 149 aspects of the ROAD group deliberations in a "New Scheme for Internet 150 Routing and Addressing [ENCAPS] for IPNG". 152 VET is related to the present-day activites of the IETF autoconf, 153 dhc, ipv6, manet and v6ops working groups. 155 2. Terminology 157 The mechanisms within this document build upon the fundamental 158 principles of IP-within-IP encapsulation. The terms "inner" and 159 "outer" are used throughout this document to respectively refer to 160 the innermost IP {address, protocol, header, packet, etc.} *before* 161 encapsulation, and the outermost IP {address, protocol, header, 162 packet, etc.} *after* encapsulation. VET also supports the inclusion 163 of "mid-layer" encapsulations between the inner and outer layers, 164 including IPSec [RFC4301], the Subnetwork Encapsulation and 165 Adaptation Layer (SEAL) [I-D.templin-seal], etc. 167 The terminology in the normative references apply; the following 168 terms are defined within the scope of this document: 170 subnetwork 171 the same as defined in [RFC3819]. 173 enterprise 174 the same as defined in [RFC4852]. 176 site 177 a logical and/or physical grouping of interfaces that connect a 178 topological area less than or equal to the enterprise in scope. A 179 site within an enterprise can be considered as an enterprise unto 180 itself. 182 Mobile Ad-hoc Network (MANET) 183 a connected topology of mobile or fixed routers that maintain a 184 routing structure among themselves over asymmetric reachability 185 links (see: [RFC4861], Section 2.2), where a wide variety of 186 MANETs share common properties with enterprise networks. Further 187 information on MANETs can be found in [RFC2501]. 189 enterprise/site/MANET 190 throughout the remainder of this document, the term "enterprise" 191 is used to collectively refer to any of enterprise/site/MANET, 192 i.e., the VET mechanisms and operational principles apply equally 193 to enterprises, sites and MANETs. 195 enterprise router 196 an Enterprise Interior Router, Enterprise Border Router, or 197 Enterprise Border Gateway. For the purose of this specification, 198 an enterprise router comprises a router function, a host function, 199 one or more enterprise-interior interfaces and zero or more 200 internal virtual, enterprise-edge, provider-edge and VET 201 interfaces. 203 Enterprise Interior Router (EIR) 204 a fixed or mobile enterprise router that forwards packets over a 205 set of enterprise-interior interfaces connected to the same 206 enterprise. 208 Enterprise Border Router (EBR) 209 an EIR that connects edge networks to the enterprise, and/or 210 connects multiple enterprises together. An EBR configures a 211 seperate VET interface over each set of enterprise-interior 212 interfaces that connect the EBR to each distinct enterprise, i.e., 213 an EBR may configure mulitple VET interfaces - one for each 214 distinct enterprise. All EBRs are also EIRs. 216 Enterprise Border Gateway (EBG) 217 an EBR that either directly or indirectly connects the enterprise 218 to provider networks and can delegate addresses/prefixes to other 219 EBRs within the enterprise. All EBGs are also EBRs. 221 internal-virtual interface 222 a virtual interface that is a special case of either an 223 enterprise-edge or an enterprise-interior interface. Internal- 224 virtual interfaces that are also enterprise-edge interfaces are 225 often loopback interfaces of some form. Internal-virtual 226 interfaces that are also enterprise-interior interfaces are often 227 tunnel interfaces of some form configured over another enterprise- 228 interior interface. 230 enterprise-edge interface 231 an EBR's attachment to a link (e.g., an ethernet, a wireless 232 personal area network, etc.) on an arbitrarily-complex edge 233 network that the EBR connects to an enterprise and/or to provider 234 networks. 236 provider-edge interface 237 an EBR's attachment to the Internet, or to a provider network 238 outside of the enterprise via which the Internet can be reached. 240 enterprise-interior Interface 241 a EIR's attachment to a link within an enterprise. An enterprise- 242 interior interface is "neutral" in its orientation, i.e., it is 243 inherently neither an enterprise-edge nor provider-edge interface. 244 In particular, a packet may need to be forwarded over several 245 enterprise-interior interfaces before it is forwarded via either 246 an enterprise-edge or provider-edge interface. 248 Enterprise Local Address (ELA) 249 an enterprise-scoped IP address (e.g., an IPv6 Unique Local 250 Address [RFC4193], an IPv4 privacy address [RFC1918], etc.) that 251 is assigned to an enterprise-interior interface and unique within 252 the enterprise. ELAs are used as identifiers for operating the 253 routing protocol and/or locators for packet forwarding within the 254 scope of the enterprise; ELAs are also used as *outer* IP 255 addresses during encapsulation. 257 Virtual Enterprise Traversal (VET) 258 an abstraction that uses IP-in-IP encapsulation to span a multi- 259 link enterprise in a single (inner) IP hop. 261 VET interface 262 an EBR's Non-Broadcast, Multiple Access interface used for Virtual 263 Enterprise Traversal. The EBR configures a VET interface over a 264 set of underlying enterprise-interior interface(s) belonging to 265 the same enterprise. When there are multiple distinct enterprises 266 (each with their own distinct set of enterprise-interior 267 interfaces), the EBR configures a separate VET interface over each 268 set of enterprise-interior interfaces, i.e., the EBR configures 269 multiple VET interfaces. 271 The VET interface encapsulates each inner IP packet in any mid- 272 layer headers plus an outer IP header then forwards it on an 273 underlying enterprise-interior interface such that the TTL/Hop 274 Limit in the inner header is not decremented as the packet 275 traverses the enterprise. The VET interface presents an automatic 276 tunneling abstraction that represents the enterprise as a single 277 IP hop. 279 The following additional acronyms are used throughout the document: 281 CGA - Cryptographically Generated Address 282 DHCP[v4,v6] - the Dynamic Host Configuration Protocol 283 IP[v4,v6] - the Internet Protocol 284 ISATAP - Intra-Site Automatic Tunnel Addressing Protocol 285 ND - Neighbor Discovery 286 PIO - Prefix Information Option 287 RIO - Route Information Option 288 RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement 289 SEAL - Subnetwork Encapsulation and Adaptation Layer 290 SLAAC - IPv6 StateLess Address AutoConfiguation 292 3. Enterprise Characteristics 294 Enterprises consist of links that are connected by enterprise routers 295 as depicted in Figure 1. All enterprise routers are also Enterprise 296 Interior Routers (EIRs) that typically participate in a routing 297 protocol over enterprise-interior interfaces to discover routes that 298 may include multiple Layer-2 or Layer-3 forwarding hops. Enterprise 299 Border Routers (EBRs) are EIRs that connect edge networks and/or join 300 multiple enterprises together, while Enterprise Border Gateways 301 (EBGs) are EBRs that either directly or indirectly connect 302 enterprises to provider networks. An enterprise may be as simple as 303 a small collection of enterprise routers (and their attached edge 304 networks); an enterprise may also contain other enterprises/sites 305 and/or be a subnetwork of a larger enterprise. An enterprise may 306 further encompass a set of branch offices connected to a home office 307 over one or several service providers, e.g., through Virtual Private 308 Network (VPN) tunnels. 310 Enterprises that comprise homogeneous link types within a single IP 311 subnet can configure the routing protocol to operate as a sub-IP 312 layer mechanism such that IP sees the enterprise as an ordinary 313 shared link the same as for a (bridged) campus LAN. In that case, a 314 single IP hop is sufficient to traverse the enterprise without IP 315 layer encapsulation. 317 Enterprises that comprise heterogeneous link types and/or multiple IP 318 subnets must also provide a routing service that operates as an IP 319 layer mechanism, e.g., to accommodate media types with dissimilar 320 Layer-2 address formats and maximum transmission units (MTUs). In 321 that case, multiple IP hops may be necessary to traverse the 322 enterprise such that specific autoconfiguration procedures are 323 necessary to avoid multilink subnet issues [RFC4903]. In particular, 324 we describe herein the use of IP-in-IP encapsulation to span the 325 enterprise in a single (inner) IP hop in order to avoid the multilink 326 subnet issues that arise when enterprise-interior interfaces are used 327 directly by applications. 329 Conceptually, an enterprise router (i.e, an EIR/EBR/EBG) embodies 330 both a host function and router function. The host function supports 331 global-scoped communications over any of the enterprise router's non- 332 enterprise-interior interfaces according to the weak end system model 333 [RFC1122] and also supports enterprise-local-scoped communications 334 over its enterprise-interior interfaces. The router function 335 connects the enterprise router's attached edge networks to the 336 enterprise and/or connects the enterprise to other networks including 337 the Internet (see: Figure 1). 339 In addition to other interface types, EBRs configure VET interfaces 340 that view all other EBRs in an enterprise as single-hop neighbors, 341 where the enterprise can also appear as a single IP hop within 342 another enterprise. EBRs configure a separate VET interface for each 343 distinct enterprise to which they connect, and discover a list of 344 EBRs for each VET interface that can be used for forwarding packets 345 to off-enterprise destinations. The following sections present the 346 Virtual Enterprise Traversal approach. 348 4. Autoconfiguration 350 EIRs configure enterprise-interior interfaces. An EBR is an EIR that 351 also configures enterprise-edge and VET interfaces. An EBG is an EBR 352 that also either directly or indirectly connects the enterprise to a 353 provider network. EIRs, EBRs and EBGs configure themselves for 354 operation according to the following subsections: 356 4.1. Enterprise Interior Router (EIR) Autoconfiguration 358 EIRs configure enterprise-interior interfaces and engage in routing 359 protocols over those interfaces. 361 When an EIR joins an enterprise, it first configures a unique IPv6 362 link-local address on each enterprise-interior interface that 363 requires an IPv6 link-local capability and an IPv4 link-local address 364 on each enterprise-interior interface that requires an IPv4 link- 365 local capability. IPv6 link-local address generation mechanisms that 366 provide sufficient uniqueness include Cryptographically Generated 367 Addresses (CGAs) [RFC3972], StateLess Address AutoConfiguration 368 (SLAAC) using EUI-64 interface identifiers [RFC4862], etc. The 369 mechanisms specified in [RFC3927] provide an IPv4 link-local address 370 generation capability. 372 Next, the EIR configures an Enterprise Local Address (ELA) of the 373 outer IP protocol version on each of its enterprise-interior 374 interfaces and engages in any routing protocols on those interfaces. 375 The EIR can configure an ELA via explicit management, DHCP 376 autoconfiguration, pseudo-random self-generation from a suitably 377 large address pool, or through an alternate autoconfiguration 378 mechanism. 380 DHCP configuration of ELAs may require support from relays within the 381 enterprise that have already autoconfigured an ELA as well as an 382 enterprise-wide multicast forwarding capability. For DHCPv6, relays 383 that do not already know the ELA of a server relay requests to the 384 'All_DHCP_Servers' site-scoped IPv6 multicast group. For DHCPv4, 385 relays that do not already know the ELA of a server relay requests to 386 the site-scoped IPv4 multicast group address TBD (see: Section 6). 387 DHCPv4 servers that delegate ELAs join the TBD multicast group and 388 service any DHCPv4 messages received for that group. 390 Self-generation of ELAs for IPv6 can be from a large IPv6 local-use 391 address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- 392 generation of ELAs for IPv4 can be from a large IPv4 private address 393 range, e.g., [I-D.fuller-240space]. When self-generation is used 394 alone, the EIR must continuously monitor the ELAs for uniqueness, 395 e.g., by monitoring the routing protocol, sending beacons, etc. 396 (This continuous monitoring process is sometimes known as "in-service 397 duplicate address detection"). 399 A combined approach using both DHCP and self-generation is also 400 possible. In this combined approach, the EIR first self-generates a 401 temporary ELA which it will use only for the purpose of procuring an 402 actual ELA from a DHCP server. Acting as a combined client/relay, 403 the EIR then assigns the temporary ELA to an enterprise-interior 404 interface, engages in the routing protocol and performs a relay- 405 server exchange using the temporary ELA as an address for the relay. 406 When the DHCP server delegates an actual ELA, the EIR abandons the 407 temporary ELA, assigns the actual ELA to the enterprise-interior 408 interface and re-engages in the routing protocol. Note that the 409 range of ELAs delegated by a DHCP server must be disjoint from the 410 range of ELAs used by the EIR for self-generation. 412 4.2. Enterprise Border Router (EBR) Autoconfiguration 414 EBRs are EIRs that configure enterprise-edge interfaces, and also 415 configure a VET interface over a set of underlying enterprise- 416 interior interfaces belonging to the same enterprise. Note that an 417 EBR may connect to multiple distinct enterprises, in which case it 418 would configure multiple VET interfaces over multiple distinct sets 419 of enterprise-interior interfaces. EBRs perform the following 420 autoconfiguration operations: 422 4.2.1. VET Interface Autoconfiguration 424 EBRs configure a VET interface over a set of underlying enterprise- 425 interior interfaces belonging to the same enterprise, where the VET 426 interface presents a virtual view of all EBRs in the enterprise as 427 single hop neighbors. Inner IP packets forwarded over the VET 428 interface are encapsulated in any mid-layer headers (e.g., IPsec, the 429 SEAL header, etc.) followed by an outer IP header, then submitted to 430 the outer IP forwarding engine for transmission on an underlying 431 enterprise-interior interface. Further encapsulation details are 432 specified in Section 5. 434 When IPv6 and IPv4 are used as the inner/outer protocols 435 (respectively), the EBR autoconfigures an ISATAP link-local address 436 ([RFC5214], Section 6.2) on the VET interface to support packet 437 forwarding and operation of the IPv6 neighbor discovery protocol. 438 The ISATAP link-local address embeds an IPv4 ELA assigned to an 439 underlying enterprise-interior interface, and need not be checked for 440 uniqueness since the IPv4 ELA itself was already determined to be 441 unique. Link-local address configuration for other inner/outer IP 442 protocol combinations is through administrative configuration or 443 through an unspecified alternate method. 445 After the EBR configures a VET interface, it can communicate with 446 other EBRs as single-hop neighbors. It can also confirm reachability 447 of other EBRs through Neighbor Discovery (ND) and/or DHCP exchanges 448 over the VET interface, or through other means such as information 449 conveyed in the routing protocol. 451 The EBR must be able to detect and recover from the loss of VET 452 interface neighbors due to e.g., enterprise network partitions, node 453 failures, etc. Mechanisms specified outside of this document such as 454 monitoring the routing protocol, ND beaconing/polling, DHCP renewals/ 455 leasequeries, upper layer protocol hints of forward progress, 456 bidirectional forward detection, detection of network attachment, 457 etc. can be used according to the particular deployment scenario. 459 4.2.2. Enterprise Border Gateway Discovery and Enterprise 460 Identification 462 After the EBR configures its VET interfaces, it next discovers a list 463 of EBGs for each distinct enterprise to which it connects. The list 464 can be discovered through information conveyed in the routing 465 protocol or through the discovery mechanisms outlined in [RFC5214], 466 Section 8.3.2. 468 In particular, whether or not routing information is available the 469 EBR can discover the list of EBGs by resolving an identifying name 470 for the enterprise using an Enterprsie-local name resolution service 471 (e.g., using LLMNR [RFC4759] over the VET interface). In the absence 472 of other identifying names, the EBR can resolve either the hostname 473 "6over4" or the FQDN "6over4.example.com" (i.e., if an enterprise- 474 specific suffix "example.com" is known) for multicast-capable 475 enterprises. For non-multicast enterprises, the EBR can instead 476 resolve the hostname "isatap" or the FQDN "isatap.example.com". 478 Identifying names along with addresses of EBGs and/or the prefixes 479 they aggregate serve as an identifier for the enterprise. 481 4.2.3. Inner IP Address/Prefix Delegation and Maintenance 483 EBRs acquire inner IP protocol addresses and/or prefix delegations 484 through autoconfiguration exchanges via EBGs over VET interfaces, as 485 discussed in the following sections: 487 4.2.3.1. IPv4 Addresses/Prefix Delegation 489 When IPv4 is used as the inner IP protocol, the EBR performs DHCPv4 a 490 prefix delegation exchange [I-D.ietf-dhc-subnet-alloc] via an EBG 491 over a VET interface to obtain IPv4 prefixes for sub-delegation 492 and/or assignment on its enterprise-edge interfaces (the EBR may 493 peform multiple such exchanges via multiple EBGs.) 495 To perform the DHCPv4 prefix delegation exchange, a DHCPv4 client 496 associated with the EBR's host function forwards a DHCPDISCOVER 497 message with a Subnet Allocation option to a DHCPv4 relay associated 498 with its router function, i.e., the EBR acts as both client and 499 relay. The relay then forwards the message over the VET interface to 500 the DHCPv4 server via an EBG that hosts a DHCPv4 relay/server. The 501 forwarded DHCPDISCOVER will elicit a DHCPOFFER from the server 502 containing IPv4 prefix delegations, and the EBR completes the 503 delegation through a DHCPREQUEST/DHCPACK exchange. The EBR can also 504 obtain /32 prefixes using DHCPv4 prefix delegation the same as for 505 any IPv4 prefix. 507 4.2.3.2. IPv6 Addresses/Prefix Delegation 509 When IPv6 is used as the inner protocol, the EBR sends unicast IPv6 510 Router Solicitation (RS) messages to an EBG over a VET interface to 511 receive Router Advertisements (RAs) with Prefix Information Options 512 (PIOs) and/or with the M/O flags set to signify whether DHCPv6 513 autoconfiguration is available; the EBR may also perform RS/RA 514 exchanges with multiple EBGs. When the EBR receives an RA containing 515 PIOs with the 'A' and 'L' bits set to 1, it autoconfigures IPv6 516 addresses from the prefixes using SLAAC and assigns them to the VET 517 interface. (When IPv4 is used as the outer IP protocol, the 518 addresses are autoconfigured and assigned as ISATAP addresses the 519 same as specified in [RFC5214].) 521 When the EBR receives an RA with the M/O flags set to 1, the EBG that 522 sent the RA also hosts a DHCPv6 relay/server. If the RA also 523 contains PIOs with the 'L' bit set to 0, the EBR can use them as 524 hints of prefixes the server is willing to delegate (see: 525 Section 4.3). Whether or not such hints are available, the EBR 526 (acting as a requesting router) can use DHCPv6 prefix delegation 527 [RFC3633] over the VET interface to obtain IPv6 prefixes from the 528 server (acting as a delegating router). The EBR can then use the 529 delegated prefixes for sub-delegation and/or assignment on its 530 enterprise-edge interfaces. 532 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 533 exchange [RFC3315]. For example, to perform the 2-message exchange a 534 DHCPv6 client associated with the EBR's host function forwards a 535 Solicit message with an IA_PD option to a DHCPv6 relay associated 536 with its router function, i.e., the EBR acts as both client and 537 relay. The relay then forwards the message over the VET interface to 538 the server via the EBG. The forwarded Solicit message will elicit a 539 Reply from the server containing IPv6 prefix delegations. 541 The EBR can also propose a specific prefix to the DHCPv6 server per 542 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 543 available. The server will check the proposed prefix for consistency 544 and uniqueness, then return it in the reply to the EBR if it was able 545 to perform the delegation. The EBR can use mechanisms such as CGAs 546 [RFC3972], IPv6 privacy address [RFC4941], etc. to self-generate 547 addresses in conjunction with prefix delegation. 549 4.2.3.3. Prefix and Route Maintenance 551 When DHCP prefix delegation is used, the DHCP server ensures that the 552 delegations are unique and that the EBG's router function will 553 forward IP packets over the VET interface to the EBR to which the 554 prefix was delegated. The prefix delegation remains active as long 555 as the EBR continues to issue renewals over the VET interface before 556 the lease lifetime expires. The lease lifetime also keeps the 557 delegation state active even if communications between the EBR and 558 DHCP server is disrupted for a period of time (e.g., due to an 559 enterprise network partition) before being reestablished (e.g., due 560 to an enterprise network merge). EBRs can also sub-delegate inner IP 561 prefixes to requesting routers on networks connected on their 562 enterprise-edge interfaces as well as to EBRs in other enterprises. 564 Since the DHCP client and relay are co-resident on the same EBR, no 565 special coordination is necessary for the EBG to maintain routing 566 information. The EBG simply retains forwarding information base 567 entries that identify the EBR as the next-hop toward the prefix over 568 the VET interface, and issues ordinary redirects over the VET 569 interface when necessary . 571 4.2.4. Portable Inner IP Addresses/Prefixes 573 Independent of any inner IP addresses/prefix delegations (see: 574 Section 4.2.3), an EBR can also use portable IP addresses/prefixes 575 (e.g., taken from a home network) and/or self-configured IP 576 addresses/prefixes (e.g., IPv6 Unique Local Addresses (ULAs) 577 [RFC4193][I-D.ietf-ipv6-ula-central]). The EBR can continue to use 578 these addresses/prefixes as it travels between visited enterprise 579 networks as long as it coordinates in some fashion with a mapping 580 agent, prefix aggregation authority, etc. EBRs can also sub-delegate 581 portable (and other self-configured) prefixes to requesting routers 582 on networks connected on their enterprise-edge interfaces as well as 583 to EBRs in other enterprises. 585 4.2.5. Enterprise-edge Interface Autoconfiguration 587 After the EBR receives inner IP address/prefix delegations (see: 588 Section 4.2.3), it can assign them on enterprise-edge interfaces 589 only; it does not assign them on provider-edge, VET, or enterprise- 590 interior interfaces (see: [RFC3633], Section 12.1). Similarly, the 591 EBR can assign portable and/or self-configured addresses/prefixes 592 (see: Section 4.2.4) on enterprise-edge interfaces. 594 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 596 EBGs are EBRs that connect an enterprise to a service provider either 597 directly via provider-edge interfaces or indirectly via another 598 enterprise. EBGs configure provider-edge interfaces in a manner that 599 is specific to its provider connections. 601 For IPv6, EBGs send RAs over VET interfaces on enterprises for which 602 they are gateways with the M/O flags set to indicate whether they 603 configure a DHCP relay/server. EBGs can also include PIOs with the 604 'L' bit set to '0' and with a prefix such as 2001:DB8::/48 as a hint 605 of an aggregated prefix from which it is willing to delegate longer 606 prefixes. 608 5. Post-Autoconfiguration Operation 610 After an EIR has been autoconfigured, it participates in any routing 611 protocols over enterprise-interior interfaces and forwards outer IP 612 packets within the enterprise as for any ordinary router. 614 EBRs can additionally engage in any inner IP routing protocols over 615 enterprise-edge, provider-edge and VET interfaces interfaces, and can 616 use those interfaces for forwarding inner IP packets to off- 617 enterprise destinations. Note that these inner IP routing protocols 618 are separate and distinct from any enterprise-interior routing 619 protocols. 621 The following sections discuss post-autoconfiguration operations: 623 5.1. Forwarding Packets to Destinations Outside of the Enterprise 625 EBRs consult the inner IP forwarding table to determine the next hop 626 address (e.g., the VET interface address of another EBR) for 627 forwarding packets to destinations outside of the enterprise. When 628 there is no forwarding information available, the EBR can discover 629 the next-hop through FQDN or reverse lookup using the same name 630 resolution services as for EBG discovery (see: Section 4.2.2). 632 For forwarding to next-hop addresses over VET interfaces that use 633 IPv6-in-IPv4 encapsulation, EBRs determine the outer destination 634 address through static extraction of the IPv4 address embedded in the 635 next-hop ISATAP address. For other IP-in-IP encapsulations, 636 determination of the outer destination address is through 637 administrative configuration or through an unspecified alternate 638 method. 640 EBRs that use IPv6 as the inner protocol can discover default router 641 preferences and more-specific routes [RFC4191] by sending an RS over 642 the VET interface to elicit an RA from another EBR. After default 643 and/or more-specific routes are discovered, the EBR can forward IP 644 packets via a specific EBR as the next-hop router on the VET 645 interface. When multiple default routers are available, the EBR can 646 use default router preferences, routing protocol information, traffic 647 engineering configurations, etc. to select the best exit router. 649 Note that the EBR only accepts PIOs, M/O flag settings and default 650 router preferences in RAs that are received from EBGs (i.e., it does 651 not accept them from ordinary EBRs). 653 5.2. Enterprise-Local Communications 655 When permitted by policy, pairs of EIRs that configure the endpoints 656 of a communications session can avoid VET interface encapsulation by 657 directly invoking the outer IP protocol using ELAs assigned to their 658 enterprise-interior interfaces. For example, when the outer protocol 659 is IPv4, a pair of communicating EIRs can use IPv4 ELAs for 660 enterprise-local communications over their enterprise-interior 661 interfaces without using the VET interface. 663 5.3. Multicast 665 In multicast-capable deployments, EIRs provide an enterprise-wide 666 multicasting service such as Simplified Multicast Forwarding (SMF) 667 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 668 that outer IP multicast messages of site- or greater scope will be 669 propagated across the enterprise. For such deployments, EBRs can 670 also provide an inner IP multicast/broadcast capability over their 671 VET interfaces through mapping of the inner IP multicast address 672 space to the outer IP multicast address space. 674 EBRs encapsulate inner IP multicast messages sent over the VET 675 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 676 outer IP header with a site-scoped outer IP multicast address as the 677 destination. For the case of IPv6 and IPv4 as the inner/outer 678 protocols (respectively), [RFC2529] provides mappings from the IPv6 679 multicast address space to the IPv4 multicast address space. For 680 other IP-in-IP encapsulations, mappings are established through 681 administrative configuration or through an unspecified alternate 682 method. 684 For multicast-capable enterprises, use of the inner IP multicast 685 service for operating the ND protocol over the VET interface is 686 available but should be used sparingly to minimize enterprise-wide 687 flooding. Therefore, EBRs should use unicast ND services over the 688 VET interface instead of multicast whenever possible. 690 5.4. Service Discovery 692 EIRs can peform enterprise-wide service discovery using a suitable 693 name-to-address resolution service. Examples of flooding-based 694 services include the use of LLMNR [RFC4759] over the VET interface or 695 mDNS [I-D.cheshire-dnsext-multicastdns] over an underlying 696 enterprise-interior interface. More scalable and efficient service 697 discovery mechanisms are for further study. 699 6. IANA Considerations 701 A Site-Local Scope IPv4 multicast group (TBD) for DHCPv4 server 702 discovery is requested. The allocation should be taken from the 703 239.255.000.000-239.255.255.255 Site-Local Scope range in the IANA 704 'multicast-addresses' registry. 706 7. Security Considerations 708 Security considerations for MANETs are found in [RFC2501]. 710 Security concerns with tunneling along with recommendations that 711 apply also to VET are found in 712 [I-D.ietf-v6ops-tunnel-security-concerns] [RFC5214]. 714 8. Related Work 716 The authors acknowledge the work done by Brian Carpenter and Cyndi 717 Jung in [RFC2529] that introduced the concept of intra-site automatic 718 tunneling. This concept was later called: "Virtual Ethernet" and 719 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 720 As for this document, these architectural principles also follow from 721 earlier works articulated by the ROAD group deliberations of 1992. 723 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 724 program. The Naval Research Lab (NRL) Information Technology 725 Division uses DHCP in their MANET research testbeds. Various 726 proposals within the IETF have suggested similar mechanisms. 728 9. Acknowledgements 730 The following individuals gave direct and/or indirect input that was 731 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 732 Bound, Thomas Clausen, Bob Hinden, Joe Macker, Thomas Narten, 733 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Michaela 734 Vanderveen and others in the IETF AUTOCONF and MANET working groups. 735 Many others have provided guidance over the course of many years. 737 10. Contributors 739 The following individuals have contributed to this document: 741 Eric Fleischman (eric.fleischman@boeing.com) 742 Thomas Henderson (thomas.r.henderson@boeing.com) 743 Steven Russert (steven.w.russert@boeing.com) 744 Seung Yi (seung.yi@boeing.com) 746 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 747 of the document. 749 11. References 751 11.1. Normative References 753 [I-D.ietf-dhc-subnet-alloc] 754 Johnson, R., "Subnet Allocation Option", 755 draft-ietf-dhc-subnet-alloc-07 (work in progress), 756 July 2008. 758 [I-D.ietf-v6ops-tunnel-security-concerns] 759 Hoagland, J., Krishnan, S., and D. Thaler, "Security 760 Concerns With IP Tunneling", 761 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 762 progress), October 2008. 764 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 765 September 1981. 767 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 768 converting network protocol addresses to 48.bit Ethernet 769 address for transmission on Ethernet hardware", STD 37, 770 RFC 826, November 1982. 772 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 773 RFC 2131, March 1997. 775 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 776 (IPv6) Specification", RFC 2460, December 1998. 778 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 779 and M. Carney, "Dynamic Host Configuration Protocol for 780 IPv6 (DHCPv6)", RFC 3315, July 2003. 782 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 783 Host Configuration Protocol (DHCP) version 6", RFC 3633, 784 December 2003. 786 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 787 More-Specific Routes", RFC 4191, November 2005. 789 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 790 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 791 September 2007. 793 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 794 Address Autoconfiguration", RFC 4862, September 2007. 796 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 797 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 798 March 2008. 800 11.2. Informative References 802 [I-D.cheshire-dnsext-multicastdns] 803 Cheshire, S. and M. Krochmal, "Multicast DNS", 804 draft-cheshire-dnsext-multicastdns-07 (work in progress), 805 September 2008. 807 [I-D.fuller-240space] 808 Fuller, V., "Reclassifying 240/4 as usable unicast address 809 space", draft-fuller-240space-02 (work in progress), 810 March 2008. 812 [I-D.ietf-autoconf-manetarch] 813 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 814 Network Architecture", draft-ietf-autoconf-manetarch-07 815 (work in progress), November 2007. 817 [I-D.ietf-ipv6-ula-central] 818 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 819 Addresses", draft-ietf-ipv6-ula-central-02 (work in 820 progress), June 2007. 822 [I-D.ietf-manet-smf] 823 Macker, J. and S. Team, "Simplified Multicast Forwarding 824 for MANET", draft-ietf-manet-smf-07 (work in progress), 825 February 2008. 827 [I-D.templin-seal] 828 Templin, F., "The Subnetwork Encapsulation and Adaptation 829 Layer (SEAL)", draft-templin-seal-23 (work in progress), 830 August 2008. 832 [RFC1122] Braden, R., "Requirements for Internet Hosts - 833 Communication Layers", STD 3, RFC 1122, October 1989. 835 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 836 E. Lear, "Address Allocation for Private Internets", 837 BCP 5, RFC 1918, February 1996. 839 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 840 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 842 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 843 (MANET): Routing Protocol Performance Issues and 844 Evaluation Considerations", RFC 2501, January 1999. 846 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 847 Domains without Explicit Tunnels", RFC 2529, March 1999. 849 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 850 via IPv4 Clouds", RFC 3056, February 2001. 852 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 853 RFC 3753, June 2004. 855 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 856 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 857 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 858 RFC 3819, July 2004. 860 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 861 Configuration of IPv4 Link-Local Addresses", RFC 3927, 862 May 2005. 864 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 865 RFC 3972, March 2005. 867 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 868 Addresses", RFC 4193, October 2005. 870 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 871 Internet Protocol", RFC 4301, December 2005. 873 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 874 Indicator Parameter for the "tel" URI", RFC 4759, 875 December 2006. 877 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 878 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 879 Focus", RFC 4852, April 2007. 881 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 882 June 2007. 884 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 885 Extensions for Stateless Address Autoconfiguration in 886 IPv6", RFC 4941, September 2007. 888 Appendix A. Duplicate Address Detection (DAD) Considerations 890 A-priori uniqueness determination (also known as "pre-service DAD") 891 for an ELA assigned on an enterprise-interior interface (such as 892 specified in [RFC4862]) would require either flooding the entire 893 enterprise or somehow discovering a link in the enterprise on which a 894 node that configures a duplicate address is attached and performing a 895 localized DAD exchange on that link. But, the control message 896 overhead for such an enterprise-wide DAD would be substantial and 897 prone to false-negatives due to packet loss and intermittent 898 connectivity. An alternative to pre-service DAD is to autoconfigure 899 pseudo-random ELAs on enterprise-interior interfaces and employ a 900 passive in-service DAD (e.g., one that monitors routing protocol 901 messages for duplicate assignments). 903 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 904 CGAs, IPv6 privacy addresses, etc. with very small probability of 905 collision. Pseudo-random IPv4 ELAs can be generated through random 906 assignment from a suitably large IPv4 prefix space, e.g., the soon- 907 to-be-reclassified 240/4 space [I-D.fuller-240space]. 909 Consistent operational practices can assure uniqueness for EBG- 910 aggregated addresses/prefixes, while statistical properties for 911 pseudo-random address self-generation can assure uniqueness for the 912 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 913 ELA delegation authority should be used when available, while a 914 passive in-service DAD mechanism should be used to detect ELA 915 duplications when there is no ELA delegation authority. 917 Appendix B. Change Log 919 (Note to RFC editor - this section to be removed before publication 920 as an RFC.) 922 Changes from -17 to 18: 924 o adjusted section headings to group autoconf operations under EIR/ 925 EBR/EBG. 927 o clarified M/O bits 929 o clarified EBG roles 931 Changes from -15 to 17: 933 o title change to "Virtual Enterprise Traversal (VET)". 935 o changed document focus from MANET-centric to the much-broader 936 Enterprise-centric, where "Enterprise" is understood to also cover 937 a wide range of MANET types. 939 Changes from -14 to 15: 941 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 943 o Address review comments 945 Changes from -12 to 14: 947 o title change to "The MANET Virtual Ethernet Abstraction". 949 o Minor section rearrangement. 951 o Clartifications on portable and self-configured prefixes. 953 o Clarifications on DHCPv6 prefix delegation procedures. 955 Changes from -11 to 12: 957 o title change to "MANET Autoconfiguration using Virtual Ethernet". 959 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 960 delegation mechanism. 962 o IPv6 SLAAC for address autoconfiguration on the VET interface. 964 o fixed editorials based on comments received. 966 Changes from -10 to 11: 968 o removed the transparent/opaque VET portal abstractions. 970 o removed routing header as an option for MANET exit router 971 selection. 973 o included IPv6 SLAAC as an endorsed address configuration mechanism 974 for the VET interface. 976 Changes from -08 to -09: 978 o Introduced the term "VET". 980 o Changed address delegation language to speak of "MNBR-aggregated" 981 instead of global/local. 983 o Updated figures 1-3. 985 o Explained why a MANET interface is "neutral". 987 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 988 DHCPv4 servers; not relays. 990 Changes from -07 to -08: 992 o changed terms "unenhanced" and "enhanced" to "transparent" and 993 "opaque". 995 o revised MANET Router diagram. 997 o introduced RFC3753 terminology for Mobile Router; ingress/egress 998 interface. 1000 o changed abbreviations to "MNR" and "MNBR". 1002 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 1004 o rearranged Section 3.1. 1006 o various minor text cleanups 1008 Changes from -06 to -07: 1010 o added MANET Router diagram. 1012 o added new references 1014 o various minor text cleanups 1016 Changed from -05 to -06: 1018 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1020 o minor changes to preserve generality 1022 Changed from -04 to -05: 1024 o introduced conceptual "virtual ethernet" model. 1026 o support "raw" and "cooked" modes as equivalent access methods on 1027 the virutal ethernet. 1029 Changed from -03 to -04: 1031 o introduced conceptual "imaginary shared link" as a representation 1032 for a MANET. 1034 o discussion of autonomous system and site abstractions for MANETs 1036 o discussion of autoconfiguration of CGAs 1038 o new appendix on IPv6 StateLess Address AutoConfiguration 1040 Changes from -02 to -03: 1042 o updated terminology based on RFC2461 "asymmetric reachability" 1043 link type; IETF67 MANET Autoconf wg discussions. 1045 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1046 Address Detection 1048 o relaxed DHCP server deployment considerations allow DHCP servers 1049 within the MANET itself 1051 Changes from -01 to -02: 1053 o minor updates for consistency with recent developments 1055 Changes from -00 to -01: 1057 o new text on DHCPv6 prefix delegation and multilink subnet 1058 considerations. 1060 o various editorial changes 1062 Author's Address 1064 Fred L. Templin (editor) 1065 Boeing Phantom Works 1066 P.O. Box 3707 MC 7L-49 1067 Seattle, WA 98124 1068 USA 1070 Email: fltemplin@acm.org 1072 Full Copyright Statement 1074 Copyright (C) The IETF Trust (2008). 1076 This document is subject to the rights, licenses and restrictions 1077 contained in BCP 78, and except as set forth therein, the authors 1078 retain all their rights. 1080 This document and the information contained herein are provided on an 1081 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1082 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1083 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1084 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1085 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1086 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1088 Intellectual Property 1090 The IETF takes no position regarding the validity or scope of any 1091 Intellectual Property Rights or other rights that might be claimed to 1092 pertain to the implementation or use of the technology described in 1093 this document or the extent to which any license under such rights 1094 might or might not be available; nor does it represent that it has 1095 made any independent effort to identify any such rights. Information 1096 on the procedures with respect to rights in RFC documents can be 1097 found in BCP 78 and BCP 79. 1099 Copies of IPR disclosures made to the IETF Secretariat and any 1100 assurances of licenses to be made available, or the result of an 1101 attempt made to obtain a general license or permission for the use of 1102 such proprietary rights by implementers or users of this 1103 specification can be obtained from the IETF on-line IPR repository at 1104 http://www.ietf.org/ipr. 1106 The IETF invites any interested party to bring to its attention any 1107 copyrights, patents or patent applications, or other proprietary 1108 rights that may cover technology that may be required to implement 1109 this standard. Please address the information to the IETF at 1110 ietf-ipr@ietf.org.