idnits 2.17.1 draft-templin-autoconf-dhcp-19.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 1080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1091. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1104. 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 28, 2008) is 5658 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 796, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'RFC3753' is defined on line 847, 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-07 == 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: 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 28, 2008 5 Expires: May 1, 2009 7 Virtual Enterprise Traversal (VET) 8 draft-templin-autoconf-dhcp-19.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 May 1, 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 . . . . . . . . . . . . . . . 13 62 5.1. Forwarding Packets to Destinations Outside of the 63 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.2. Enterprise-Local Communications . . . . . . . . . . . . . 14 65 5.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 66 5.4. Service Discovery . . . . . . . . . . . . . . . . . . . . 15 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . 17 75 Appendix A. Duplicate Address Detection (DAD) Considerations . . 19 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 coordinates with 490 EBGs to acquire IPv4 prefixes for sub-delegation and/or assignment on 491 its enterprise-edge interfaces. This coordination can be through 492 explicit management, or through an unspecified automated prefix 493 delegation exchange. The EBR can also obtain /32 prefixes the same 494 as for any IPv4 prefix. 496 4.2.3.2. IPv6 Addresses/Prefix Delegation 498 When IPv6 is used as the inner protocol, the EBR sends unicast IPv6 499 Router Solicitation (RS) messages to an EBG over a VET interface to 500 receive Router Advertisements (RAs) with Prefix Information Options 501 (PIOs) and/or with the M/O flags set to signify whether DHCPv6 502 autoconfiguration is available; the EBR may also perform RS/RA 503 exchanges with multiple EBGs. When the EBR receives an RA containing 504 PIOs with the 'A' and 'L' bits set to 1, it autoconfigures IPv6 505 addresses from the prefixes using SLAAC and assigns them to the VET 506 interface. (When IPv4 is used as the outer IP protocol, the 507 addresses are autoconfigured and assigned as ISATAP addresses the 508 same as specified in [RFC5214].) 510 When the EBR receives an RA with the M/O flags set to 1, the EBG that 511 sent the RA also hosts a DHCPv6 relay/server. If the RA also 512 contains PIOs with the 'L' bit set to 0, the EBR can use them as 513 hints of prefixes the server is willing to delegate (see: 514 Section 4.3). Whether or not such hints are available, the EBR 515 (acting as a requesting router) can use DHCPv6 prefix delegation 516 [RFC3633] over the VET interface to obtain IPv6 prefixes from the 517 server (acting as a delegating router). The EBR can then use the 518 delegated prefixes for sub-delegation and/or assignment on its 519 enterprise-edge interfaces. 521 The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 522 exchange [RFC3315]. For example, to perform the 2-message exchange a 523 DHCPv6 client associated with the EBR's host function forwards a 524 Solicit message with an IA_PD option to a DHCPv6 relay associated 525 with its router function, i.e., the EBR acts as both client and 526 relay. The relay then forwards the message over the VET interface to 527 the server via the EBG. The forwarded Solicit message will elicit a 528 Reply from the server containing IPv6 prefix delegations. 530 The EBR can also propose a specific prefix to the DHCPv6 server per 531 Section 7 of [RFC3633], e.g., if a prefix delegation hint is 532 available. The server will check the proposed prefix for consistency 533 and uniqueness, then return it in the reply to the EBR if it was able 534 to perform the delegation. The EBR can use mechanisms such as CGAs 535 [RFC3972], IPv6 privacy address [RFC4941], etc. to self-generate 536 addresses in conjunction with prefix delegation. 538 4.2.3.3. Prefix and Route Maintenance 540 When DHCP prefix delegation is used, the DHCP server ensures that the 541 delegations are unique and that the EBG's router function will 542 forward IP packets over the VET interface to the EBR to which the 543 prefix was delegated. The prefix delegation remains active as long 544 as the EBR continues to issue renewals over the VET interface before 545 the lease lifetime expires. The lease lifetime also keeps the 546 delegation state active even if communications between the EBR and 547 DHCP server is disrupted for a period of time (e.g., due to an 548 enterprise network partition) before being reestablished (e.g., due 549 to an enterprise network merge). EBRs can also sub-delegate inner IP 550 prefixes to requesting routers on networks connected on their 551 enterprise-edge interfaces as well as to EBRs in other enterprises. 553 Since the DHCP client and relay are co-resident on the same EBR, no 554 special coordination is necessary for the EBG to maintain routing 555 information. The EBG simply retains forwarding information base 556 entries that identify the EBR as the next-hop toward the prefix over 557 the VET interface, and issues ordinary redirects over the VET 558 interface when necessary . 560 4.2.4. Portable Inner IP Addresses/Prefixes 562 Independent of any inner IP addresses/prefix delegations (see: 563 Section 4.2.3), an EBR can also use portable IP addresses/prefixes 564 (e.g., taken from a home network) and/or self-configured IP 565 addresses/prefixes (e.g., IPv6 Unique Local Addresses (ULAs) 566 [RFC4193][I-D.ietf-ipv6-ula-central]). The EBR can continue to use 567 these addresses/prefixes as it travels between visited enterprise 568 networks as long as it coordinates in some fashion with a mapping 569 agent, prefix aggregation authority, etc. EBRs can also sub-delegate 570 portable (and other self-configured) prefixes to requesting routers 571 on networks connected on their enterprise-edge interfaces as well as 572 to EBRs in other enterprises. 574 4.2.5. Enterprise-edge Interface Autoconfiguration 576 After the EBR receives inner IP address/prefix delegations (see: 577 Section 4.2.3), it can assign them on enterprise-edge interfaces 578 only; it does not assign them on provider-edge, VET, or enterprise- 579 interior interfaces (see: [RFC3633], Section 12.1). Similarly, the 580 EBR can assign portable and/or self-configured addresses/prefixes 581 (see: Section 4.2.4) on enterprise-edge interfaces. 583 4.3. Enterprise Border Gateway (EBG) Autoconfiguration 585 EBGs are EBRs that connect an enterprise to a service provider either 586 directly via provider-edge interfaces or indirectly via another 587 enterprise. EBGs configure provider-edge interfaces in a manner that 588 is specific to its provider connections. 590 For IPv6, EBGs send RAs over VET interfaces on enterprises for which 591 they are gateways with the M/O flags set to indicate whether they 592 configure a DHCP relay/server. EBGs can also include PIOs with the 593 'L' bit set to '0' and with a prefix such as 2001:DB8::/48 as a hint 594 of an aggregated prefix from which it is willing to delegate longer 595 prefixes. 597 5. Post-Autoconfiguration Operation 599 After an EIR has been autoconfigured, it participates in any routing 600 protocols over enterprise-interior interfaces and forwards outer IP 601 packets within the enterprise as for any ordinary router. 603 EBRs can additionally engage in any inner IP routing protocols over 604 enterprise-edge, provider-edge and VET interfaces interfaces, and can 605 use those interfaces for forwarding inner IP packets to off- 606 enterprise destinations. Note that these inner IP routing protocols 607 are separate and distinct from any enterprise-interior routing 608 protocols. 610 The following sections discuss post-autoconfiguration operations: 612 5.1. Forwarding Packets to Destinations Outside of the Enterprise 614 EBRs consult the inner IP forwarding table to determine the next hop 615 address (e.g., the VET interface address of another EBR) for 616 forwarding packets to destinations outside of the enterprise. When 617 there is no forwarding information available, the EBR can discover 618 the next-hop through FQDN or reverse lookup using the same name 619 resolution services as for EBG discovery (see: Section 4.2.2). 621 For forwarding to next-hop addresses over VET interfaces that use 622 IPv6-in-IPv4 encapsulation, EBRs determine the outer destination 623 address through static extraction of the IPv4 address embedded in the 624 next-hop ISATAP address. For other IP-in-IP encapsulations, 625 determination of the outer destination address is through 626 administrative configuration or through an unspecified alternate 627 method. 629 EBRs that use IPv6 as the inner protocol can discover default router 630 preferences and more-specific routes [RFC4191] by sending an RS over 631 the VET interface to elicit an RA from another EBR. After default 632 and/or more-specific routes are discovered, the EBR can forward IP 633 packets via a specific EBR as the next-hop router on the VET 634 interface. When multiple default routers are available, the EBR can 635 use default router preferences, routing protocol information, traffic 636 engineering configurations, etc. to select the best exit router. 638 Note that the EBR only accepts PIOs, M/O flag settings and default 639 router preferences in RAs that are received from EBGs (i.e., it does 640 not accept them from ordinary EBRs). 642 5.2. Enterprise-Local Communications 644 When permitted by policy, pairs of EIRs that configure the endpoints 645 of a communications session can avoid VET interface encapsulation by 646 directly invoking the outer IP protocol using ELAs assigned to their 647 enterprise-interior interfaces. For example, when the outer protocol 648 is IPv4, a pair of communicating EIRs can use IPv4 ELAs for 649 enterprise-local communications over their enterprise-interior 650 interfaces without using the VET interface. 652 5.3. Multicast 654 In multicast-capable deployments, EIRs provide an enterprise-wide 655 multicasting service such as Simplified Multicast Forwarding (SMF) 656 [I-D.ietf-manet-smf] over their enterprise-interior interfaces such 657 that outer IP multicast messages of site- or greater scope will be 658 propagated across the enterprise. For such deployments, EBRs can 659 also provide an inner IP multicast/broadcast capability over their 660 VET interfaces through mapping of the inner IP multicast address 661 space to the outer IP multicast address space. 663 EBRs encapsulate inner IP multicast messages sent over the VET 664 interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an 665 outer IP header with a site-scoped outer IP multicast address as the 666 destination. For the case of IPv6 and IPv4 as the inner/outer 667 protocols (respectively), [RFC2529] provides mappings from the IPv6 668 multicast address space to the IPv4 multicast address space. For 669 other IP-in-IP encapsulations, mappings are established through 670 administrative configuration or through an unspecified alternate 671 method. 673 For multicast-capable enterprises, use of the inner IP multicast 674 service for operating the ND protocol over the VET interface is 675 available but should be used sparingly to minimize enterprise-wide 676 flooding. Therefore, EBRs should use unicast ND services over the 677 VET interface instead of multicast whenever possible. 679 5.4. Service Discovery 681 EIRs can peform enterprise-wide service discovery using a suitable 682 name-to-address resolution service. Examples of flooding-based 683 services include the use of LLMNR [RFC4759] over the VET interface or 684 mDNS [I-D.cheshire-dnsext-multicastdns] over an underlying 685 enterprise-interior interface. More scalable and efficient service 686 discovery mechanisms are for further study. 688 6. IANA Considerations 690 A Site-Local Scope IPv4 multicast group (TBD) for DHCPv4 server 691 discovery is requested. The allocation should be taken from the 692 239.255.000.000-239.255.255.255 Site-Local Scope range in the IANA 693 'multicast-addresses' registry. 695 7. Security Considerations 697 Security considerations for MANETs are found in [RFC2501]. 699 Security considerations with tunneling that apply also to VET are 700 found in [RFC2529][RFC5214]. 702 8. Related Work 704 The authors acknowledge the work done by Brian Carpenter and Cyndi 705 Jung in [RFC2529] that introduced the concept of intra-site automatic 706 tunneling. This concept was later called: "Virtual Ethernet" and 707 investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang. 708 As for this document, these architectural principles also follow from 709 earlier works articulated by the ROAD group deliberations of 1992. 711 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 712 program. The Naval Research Lab (NRL) Information Technology 713 Division uses DHCP in their MANET research testbeds. Various 714 proposals within the IETF have suggested similar mechanisms. 716 [I-D.ietf-v6ops-tunnel-security-concerns] discusses security concerns 717 regarding tunneling mechanisms that may subvert security through 718 Network Address Translator (NAT) traversal. 720 An automated IPv4 prefix delegation mechanism is proposed in 721 [I-D.ietf-dhc-subnet-alloc]. 723 9. Acknowledgements 725 The following individuals gave direct and/or indirect input that was 726 essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James 727 Bound, Thomas Clausen, Bob Hinden, Joe Macker, Thomas Narten, 728 Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Michaela 729 Vanderveen and others in the IETF AUTOCONF and MANET working groups. 730 Many others have provided guidance over the course of many years. 732 10. Contributors 734 The following individuals have contributed to this document: 736 Eric Fleischman (eric.fleischman@boeing.com) 737 Thomas Henderson (thomas.r.henderson@boeing.com) 738 Steven Russert (steven.w.russert@boeing.com) 739 Seung Yi (seung.yi@boeing.com) 741 Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions 742 of the document. 744 11. References 746 11.1. Normative References 748 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 749 September 1981. 751 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 752 converting network protocol addresses to 48.bit Ethernet 753 address for transmission on Ethernet hardware", STD 37, 754 RFC 826, November 1982. 756 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 757 RFC 2131, March 1997. 759 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 760 (IPv6) Specification", RFC 2460, December 1998. 762 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 763 and M. Carney, "Dynamic Host Configuration Protocol for 764 IPv6 (DHCPv6)", RFC 3315, July 2003. 766 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 767 Host Configuration Protocol (DHCP) version 6", RFC 3633, 768 December 2003. 770 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 771 More-Specific Routes", RFC 4191, November 2005. 773 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 774 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 775 September 2007. 777 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 778 Address Autoconfiguration", RFC 4862, September 2007. 780 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 781 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 782 March 2008. 784 11.2. Informative References 786 [I-D.cheshire-dnsext-multicastdns] 787 Cheshire, S. and M. Krochmal, "Multicast DNS", 788 draft-cheshire-dnsext-multicastdns-07 (work in progress), 789 September 2008. 791 [I-D.fuller-240space] 792 Fuller, V., "Reclassifying 240/4 as usable unicast address 793 space", draft-fuller-240space-02 (work in progress), 794 March 2008. 796 [I-D.ietf-autoconf-manetarch] 797 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 798 Network Architecture", draft-ietf-autoconf-manetarch-07 799 (work in progress), November 2007. 801 [I-D.ietf-dhc-subnet-alloc] 802 Johnson, R., "Subnet Allocation Option", 803 draft-ietf-dhc-subnet-alloc-07 (work in progress), 804 July 2008. 806 [I-D.ietf-ipv6-ula-central] 807 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 808 Addresses", draft-ietf-ipv6-ula-central-02 (work in 809 progress), June 2007. 811 [I-D.ietf-manet-smf] 812 Macker, J. and S. Team, "Simplified Multicast Forwarding 813 for MANET", draft-ietf-manet-smf-07 (work in progress), 814 February 2008. 816 [I-D.ietf-v6ops-tunnel-security-concerns] 817 Hoagland, J., Krishnan, S., and D. Thaler, "Security 818 Concerns With IP Tunneling", 819 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 820 progress), October 2008. 822 [I-D.templin-seal] 823 Templin, F., "The Subnetwork Encapsulation and Adaptation 824 Layer (SEAL)", draft-templin-seal-23 (work in progress), 825 August 2008. 827 [RFC1122] Braden, R., "Requirements for Internet Hosts - 828 Communication Layers", STD 3, RFC 1122, October 1989. 830 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 831 E. Lear, "Address Allocation for Private Internets", 832 BCP 5, RFC 1918, February 1996. 834 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 835 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 837 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 838 (MANET): Routing Protocol Performance Issues and 839 Evaluation Considerations", RFC 2501, January 1999. 841 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 842 Domains without Explicit Tunnels", RFC 2529, March 1999. 844 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 845 via IPv4 Clouds", RFC 3056, February 2001. 847 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 848 RFC 3753, June 2004. 850 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 851 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 852 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 853 RFC 3819, July 2004. 855 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 856 Configuration of IPv4 Link-Local Addresses", RFC 3927, 857 May 2005. 859 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 860 RFC 3972, March 2005. 862 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 863 Addresses", RFC 4193, October 2005. 865 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 866 Internet Protocol", RFC 4301, December 2005. 868 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 869 Indicator Parameter for the "tel" URI", RFC 4759, 870 December 2006. 872 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 873 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 874 Focus", RFC 4852, April 2007. 876 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 877 June 2007. 879 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 880 Extensions for Stateless Address Autoconfiguration in 881 IPv6", RFC 4941, September 2007. 883 Appendix A. Duplicate Address Detection (DAD) Considerations 885 A-priori uniqueness determination (also known as "pre-service DAD") 886 for an ELA assigned on an enterprise-interior interface (such as 887 specified in [RFC4862]) would require either flooding the entire 888 enterprise or somehow discovering a link in the enterprise on which a 889 node that configures a duplicate address is attached and performing a 890 localized DAD exchange on that link. But, the control message 891 overhead for such an enterprise-wide DAD would be substantial and 892 prone to false-negatives due to packet loss and intermittent 893 connectivity. An alternative to pre-service DAD is to autoconfigure 894 pseudo-random ELAs on enterprise-interior interfaces and employ a 895 passive in-service DAD (e.g., one that monitors routing protocol 896 messages for duplicate assignments). 898 Pseudo-random IPv6 ELAs can be generated with mechanisms such as 899 CGAs, IPv6 privacy addresses, etc. with very small probability of 900 collision. Pseudo-random IPv4 ELAs can be generated through random 901 assignment from a suitably large IPv4 prefix space, e.g., the soon- 902 to-be-reclassified 240/4 space [I-D.fuller-240space]. 904 Consistent operational practices can assure uniqueness for EBG- 905 aggregated addresses/prefixes, while statistical properties for 906 pseudo-random address self-generation can assure uniqueness for the 907 ELAs assigned on an EIR's enterprise-interior interfaces. Still, an 908 ELA delegation authority should be used when available, while a 909 passive in-service DAD mechanism should be used to detect ELA 910 duplications when there is no ELA delegation authority. 912 Appendix B. Change Log 914 (Note to RFC editor - this section to be removed before publication 915 as an RFC.) 917 Changes from -17 to 18: 919 o adjusted section headings to group autoconf operations under EIR/ 920 EBR/EBG. 922 o clarified M/O bits 924 o clarified EBG roles 926 Changes from -15 to 17: 928 o title change to "Virtual Enterprise Traversal (VET)". 930 o changed document focus from MANET-centric to the much-broader 931 Enterprise-centric, where "Enterprise" is understood to also cover 932 a wide range of MANET types. 934 Changes from -14 to 15: 936 o title change to "Virtual Enterprise Traversal (VET) for MANETs". 938 o Address review comments 940 Changes from -12 to 14: 942 o title change to "The MANET Virtual Ethernet Abstraction". 944 o Minor section rearrangement. 946 o Clartifications on portable and self-configured prefixes. 948 o Clarifications on DHCPv6 prefix delegation procedures. 950 Changes from -11 to 12: 952 o title change to "MANET Autoconfiguration using Virtual Ethernet". 954 o DHCP prefix delegation for both IPv4 and IPv6 as primary address 955 delegation mechanism. 957 o IPv6 SLAAC for address autoconfiguration on the VET interface. 959 o fixed editorials based on comments received. 961 Changes from -10 to 11: 963 o removed the transparent/opaque VET portal abstractions. 965 o removed routing header as an option for MANET exit router 966 selection. 968 o included IPv6 SLAAC as an endorsed address configuration mechanism 969 for the VET interface. 971 Changes from -08 to -09: 973 o Introduced the term "VET". 975 o Changed address delegation language to speak of "MNBR-aggregated" 976 instead of global/local. 978 o Updated figures 1-3. 980 o Explained why a MANET interface is "neutral". 982 o Removed DHCPv4 "MLA Address option". Now, MNBRs can only be 983 DHCPv4 servers; not relays. 985 Changes from -07 to -08: 987 o changed terms "unenhanced" and "enhanced" to "transparent" and 988 "opaque". 990 o revised MANET Router diagram. 992 o introduced RFC3753 terminology for Mobile Router; ingress/egress 993 interface. 995 o changed abbreviations to "MNR" and "MNBR". 997 o added text on ULAs and ULA-Cs to "Self-Generated Addresses". 999 o rearranged Section 3.1. 1001 o various minor text cleanups 1003 Changes from -06 to -07: 1005 o added MANET Router diagram. 1007 o added new references 1009 o various minor text cleanups 1011 Changed from -05 to -06: 1013 o Changed terms "raw" and "cooked" to "unenhanced" and "enhanced". 1015 o minor changes to preserve generality 1017 Changed from -04 to -05: 1019 o introduced conceptual "virtual ethernet" model. 1021 o support "raw" and "cooked" modes as equivalent access methods on 1022 the virutal ethernet. 1024 Changed from -03 to -04: 1026 o introduced conceptual "imaginary shared link" as a representation 1027 for a MANET. 1029 o discussion of autonomous system and site abstractions for MANETs 1031 o discussion of autoconfiguration of CGAs 1032 o new appendix on IPv6 StateLess Address AutoConfiguration 1034 Changes from -02 to -03: 1036 o updated terminology based on RFC2461 "asymmetric reachability" 1037 link type; IETF67 MANET Autoconf wg discussions. 1039 o added new appendix on IPv6 Neighbor Discovery and Duplicate 1040 Address Detection 1042 o relaxed DHCP server deployment considerations allow DHCP servers 1043 within the MANET itself 1045 Changes from -01 to -02: 1047 o minor updates for consistency with recent developments 1049 Changes from -00 to -01: 1051 o new text on DHCPv6 prefix delegation and multilink subnet 1052 considerations. 1054 o various editorial changes 1056 Author's Address 1058 Fred L. Templin (editor) 1059 Boeing Phantom Works 1060 P.O. Box 3707 MC 7L-49 1061 Seattle, WA 98124 1062 USA 1064 Email: fltemplin@acm.org 1066 Full Copyright Statement 1068 Copyright (C) The IETF Trust (2008). 1070 This document is subject to the rights, licenses and restrictions 1071 contained in BCP 78, and except as set forth therein, the authors 1072 retain all their rights. 1074 This document and the information contained herein are provided on an 1075 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1076 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1077 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1078 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1079 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1080 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1082 Intellectual Property 1084 The IETF takes no position regarding the validity or scope of any 1085 Intellectual Property Rights or other rights that might be claimed to 1086 pertain to the implementation or use of the technology described in 1087 this document or the extent to which any license under such rights 1088 might or might not be available; nor does it represent that it has 1089 made any independent effort to identify any such rights. Information 1090 on the procedures with respect to rights in RFC documents can be 1091 found in BCP 78 and BCP 79. 1093 Copies of IPR disclosures made to the IETF Secretariat and any 1094 assurances of licenses to be made available, or the result of an 1095 attempt made to obtain a general license or permission for the use of 1096 such proprietary rights by implementers or users of this 1097 specification can be obtained from the IETF on-line IPR repository at 1098 http://www.ietf.org/ipr. 1100 The IETF invites any interested party to bring to its attention any 1101 copyrights, patents or patent applications, or other proprietary 1102 rights that may cover technology that may be required to implement 1103 this standard. Please address the information to the IETF at 1104 ietf-ipr@ietf.org.