idnits 2.17.1 draft-templin-autoconf-dhcp-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 452. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 21, 2006) is 6516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.jelger-autoconf-mla' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-02 == Outdated reference: A later version (-01) exists of draft-jelger-autoconf-mla-00 == Outdated reference: A later version (-04) exists of draft-templin-autoconf-netlmm-dhcp-01 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft S. Russert 4 Expires: December 23, 2006 I. Chakeres 5 S. Yi 6 Boeing Phantom Works 7 June 21, 2006 9 MANET Autoconfiguration using DHCP 10 draft-templin-autoconf-dhcp-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 23, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Mobile Ad-hoc Networks (MANETs) comprise MANET routers and their 44 attached devices, and connect to the global Internet via one or more 45 MANET gateways. MANET routers that require global Internet access 46 must have a way to automatically configure globally routable and 47 unique IP addresses/prefixes. This document specifies mechanisms for 48 MANET autoconfiguration (AUTOCONF) based on the Dynamic Host 49 Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6 are 50 given. 52 1. Introduction 54 Mobile Ad-hoc Networks (MANETs) comprise MANET Routers (MRs) that 55 have zero or more attached devices and participate in a routing 56 protocol over limited-range (typically wireless) interfaces such that 57 packets exchanged between MRs may need to be forwarded across 58 multiple hops. MANETs attach to provider networks (and/or the global 59 Internet) via zero or more MANET Gateways (MGs), and MRs may be 60 multiple hops away from their nearest MG in some scenarios. MRs that 61 require global Internet access must have a means to autoconfigure 62 global IP addresses/prefixes and/or other configuration information. 64 MANETs that comprise MRs with homogeneous MANET interfaces can 65 configure the routing protocol to operate as a Layer-2 mechanism 66 (e.g., IEEE 802) for route calculations and packet forwarding such 67 that the Layer-3 protocol (e.g., IP) sees the MANET as a non- 68 broadcast, multiple access (NBMA) link. When a Layer-2 flooding 69 mechanism is also used, the Layer-3 protocol sees the MANET as a 70 unified broadcast/multicast capable link, i.e., the same as for a 71 (bridged) campus LAN. In such Layer-2 MANETs, MRs and MGs can 72 autoconfigure global IP addresses/prefixes using standard BOOTP/DHCP 73 [RFC0951][RFC2131][RFC3315][RFC3633] and neighbor discovery 74 [RFC0826][RFC1256][RFC2461][RFC2462] mechanisms. 76 MANETs that comprise MRs with heterogeneous MANET interfaces must 77 configure the routing protocol to operate as a Layer-3 mechanism such 78 that route calculations and packet forwarding are based on Layer-3 79 MANET-local addresses/prefixes (MLAs) to avoid issues associated with 80 bridging media types with dissimilar Layer-2 address formats and 81 maximum transmission units (MTUs). In such Layer-3 MANETs, standard 82 DHCP and neighbor discovery mechanisms are not sufficient to support 83 global IP address/prefix autoconfiguration since the MANET may appear 84 as multiple links. 86 This document specifies DHCP and neighbor discovery extensions for MR 87 autoconfiguration in Layer-3 MANETs as well as details of operation 88 for multiple MGs that apply to both Layer-2 and Layer-3 MANETs. 89 Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are given. 91 2. Terminology 93 The terminology in the normative references apply; the following 94 terms are defined within the scope of this document: 96 Mobile Ad-hoc Network (MANET) 97 a connected network region (i.e., a "site") that comprises MANET 98 routers that maintain a routing structure among themselves in a 99 relatively arbitrary fashion over dynamic (wireless) MANET 100 interfaces. Further information on the characteristics of MANETs 101 can be found in [RFC2501]. 103 MANET Interface 104 a node's attachment to a MANET. 106 MANET Router (MR) 107 a node with zero or more attached devices that participates in the 108 MANET routing protocol on one or more limited-range (typically 109 wireless) MANET interface(s). 111 MANET Gateway (MG) 112 an MR that also provides gateway service to a provider network 113 and/or the global Internet. 115 MANET Local Address (MLA) 116 a Layer-3 unicast address/prefix configured by an MR that is used 117 only within the scope of the connected MANET. For Layer-3 MANETs, 118 MRs use MLAs to operate the routing protocol; for both Layer-2 and 119 Layer-3 MANETs, MRs can use MLAs for intra-MANET data 120 communications. (For IPv6, Unique Local Addresses (ULAs) provide 121 a natural MLA mechanism - see: [RFC4193] and [I-D.jelger-autoconf- 122 mla]). 124 Extended Router Advertisement/Solicitation (ERA/ERS) 125 an IP Router Advertisement/Solicitation (RA/RS) message [RFC1256] 126 [RFC2461] encapsulated in an outer header for transmission over a 127 Layer-3 MANET with destination address set to an MLA or a site- 128 scoped multicast address (see: Section 3.5). 130 3. Autoconfiguration Extensions for Layer-3 MANETs 132 The following sections specify extensions necessary to support DHCP- 133 based autoconfiguration for Layer-3 MANETs: 135 3.1. MANET Router (MR) Extensions 137 When an MR first powers on, activates a MANET interface, or when it 138 receives an indication of movement to a new MANET, it configures one 139 or more MLAs (through a means outside the scope of this 140 specification) and engages in the MANET routing protocol. Next, if 141 the MR requires global IP address/prefix delegations, it listens for 142 ERAs from nearby MGs and (if none are heard) sends a small number of 143 ERSs to elicit immediate ERAs. When it needs to send ERSs, the MR 144 should set a small value (e.g., 2, 5, 10, etc.) in the TTL (IPv4), 145 Hop Limit (IPv6), or other Layer-3 protocol field of the 146 encapsulating header to limit the scope. 148 After the MR receives ERAs from MGs, it selects one or more MGs as 149 default MGs and selects one MG as its primary MG. Acting as a DHCP 150 client, the MR then sends a DHCP request to an MLA for its primary 151 MG. The DHCP request must include an MLA for the MR in a DHCPv4 MLA 152 option or the DHCPv6 "peer-address" field (see: Section 3.4) and will 153 elicit a DHCP reply from the server with IP address/prefix 154 delegations. 156 For IPv6, the MR can use DHCP prefix delegation per [RFC3633] and 157 configure addresses for itself and/or its attached devices from the 158 delegated prefixes per [I-D.thaler-autoconf-multisubnet-manets]. If 159 the ERAs include prefix options, the MR can alternatively configure 160 addresses from the advertised prefixes per [RFC2462]. In the latter 161 case, MGs should not advertise the same prefixes to more than one MR 162 so that multilink subnet issues are avoided - see: [I-D.thaler- 163 intarea-multilink-subnet-issues]. 165 After the MR configures global IP addresses/prefixes, it can send IP 166 packets to off-MANET destinations using any of the MGs in its default 167 MG list as egress gateways. For MANETs in which the MANET routing 168 protocol is IP-based and MGs can inject a 'default' route that 169 propagates throughout the MANET, the MR can send the IP packets 170 without encapsulation at the expense of extra TTL (IPv4) or Hop Limit 171 (IPv6) decrementation. For MANETs in which the MANET routing 172 protocol is not IP-based and/or MGs cannot propagate a default route, 173 the MR either: a) encapsulates IP packets with an MLA for an MG as 174 the destination address in the outer header (i.e., tunnels the 175 packets to the MG), or b) inserts an IPv4 source routing header 176 (likewise IPv6 routing header) to ensure that the packets will be 177 forwarded through an MG. 179 The above MR specifications are analogous to the more detailed Mobile 180 Node (MN) specifications found in ([I-D.templin-autoconf-netlmm- 181 dhcp], section 4.1). 183 3.2. MANET Gateway Extensions 185 MGs send periodic/solicited ERAs on their attached MANET interfaces 186 instead of sending periodic/solicited RAs. The ERAs should set a 187 small value (e.g., 2, 5, 10, etc.) in the TTL (IPv4), Hop Limit 188 (IPv6), or other protocol field of the encapsulating header to limit 189 the scope. MGs act as BOOTP/DHCP relays for the DHCP requests/ 190 replies exchanged between MRs and DHCP servers. (When the DHCP 191 server function resides on the MG itself, the MG acts as a DHCP 192 server.) 194 For each DHCP reply message it processes pertaining to address/prefix 195 delegation, the MG creates a tunnel (if necessary) with the tunnel's 196 destination address set to the MLA for the MR encoded in the DHCPv4 197 MLA option or the DHCPv6 "peer-address" field (see: Section 3.4). 198 The MG then creates entries in its IP forwarding table that point to 199 the tunnel for each delegated IP address/prefix and relays the reply 200 to the MLA for the MR. 202 When MGs forward IP packets to an MR, they either: a) encapsulate the 203 packets with the MLA for the MR as the destination address in the 204 outer header (i.e., tunnel the packets to the MR), or b) insert an 205 IPv4 source routing header (likewise IPv6 routing header) to ensure 206 that the packets will be forwarded to the correct MR. 208 The above MG specifications are analogous to the more detailed Access 209 Router (AR) specifications found in ([I-D.templin-autoconf-netlmm- 210 dhcp], Section 4.2). 212 3.3. DHCP Server Extensions 214 DHCP servers can reside on provider networks, the Internet or on the 215 MGs themselves. 217 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 218 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 219 copies the option into the corresponding DHCPv4 reply message(s). 221 No MANET-specific extensions are required for DHCPv6 servers. 223 3.4. MLA Encapsulation 225 For DHCPv6, the MLA is encoded directly in the "peer-address" field 226 of DHCPv6 requests/replies. 228 For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is 229 required to encode an MLA so that the MG can direct DHCPv4 replies to 230 the correct MR, which may be multiple Layer-3 hops away. The format 231 of the DHCPv4 MLA option is given below: 233 Code Len Ether Type MLA 234 +-----+-----+-----+-----+-----+-----+--- 235 | TBD | n | type | a1 | a2 | ... 236 +-----+-----+-----+-----+-----+-----+--- 237 Code 238 a one-octet field that identifies the option type (see: 239 Section 5). 241 Len 242 a one-octet field that encodes the remaining option length. 244 Ether Type 245 a type value from the IANA "ethernet-numbers" registry. 247 MLA 248 a variable-length MANET Local Address (MLA). 250 3.5. MANET Flooding 252 MRs and MGs in Layer-3 MANETs that implement this specification 253 require a MANET flooding mechanism (e.g., Simplified Multicast 254 Forwarding (SMF) [I-D.ietf-manet-smf]) so that site-scoped multicast 255 ERA/ERS messages can be propagated across multiple Layer-3 hops. 257 4. Operation with Multiple MGs 259 When the Layer-2 or Layer-3 MANET connects to provider networks or 260 the global Internet via multiple MGs, MR operation and localized 261 mobility management is based on the nature of MG deployment. 263 For a set of MGs that attach to the same provider network, MRs can 264 retain their global IP address/prefix delegations as they move 265 between different MGs if the network configures a mobility anchor 266 point that participates with the MGs and MRs in a localized mobility 267 management scheme, e.g., see: [I-D.templin-autoconf-netlmm-dhcp]. 269 For a set of MGs that attach to different provider networks and/or 270 serve different global IP prefixes from within the same provider 271 network, MRs must configure new global IP addresses/prefixes as they 272 change between different MGs unless inter-MG tunnels and routing 273 protocol exchanges are supported, e.g., see: [I-D.templin-autoconf- 274 netlmm-dhcp], Appendix A. 276 Global mobility management mechanisms for MRs that configure new 277 global IP addresses/prefixes as they move between different MGs are 278 beyond the scope of this document; see: [I-D.njedjou-globalmm-ps] for 279 a global mobility management problem statement. 281 5. IANA Considerations 282 A new DHCP option code is requested for the DHCP MLA Option in the 283 IANA "bootp-dhcp-parameters" registry. 285 6. Security Considerations 287 Security considerations for this document are the same as for 288 [I-D.templin-autoconf-netlmm-dhcp]. 290 Threats relating to MANET routing protocols also apply to this 291 document. 293 7. Related Work 295 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 296 program. Various proposals targeted for the IETF AUTOCONF working 297 group have suggested stateless mechanisms for address configuration. 299 8. Acknowledgements 301 The Naval Research Lab (NRL) Information Technology Division uses 302 DHCP in their MANET research testbeds. 304 The following individuals (in chronological order) have provided 305 valuable input: Thomas Henderson. 307 9. References 309 9.1. Normative References 311 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 312 September 1981. 314 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 315 converting network protocol addresses to 48.bit Ethernet 316 address for transmission on Ethernet hardware", STD 37, 317 RFC 826, November 1982. 319 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 320 September 1985. 322 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 323 September 1991. 325 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 326 RFC 2131, March 1997. 328 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 329 Extensions", RFC 2132, March 1997. 331 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 332 (IPv6) Specification", RFC 2460, December 1998. 334 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 335 Discovery for IP Version 6 (IPv6)", RFC 2461, 336 December 1998. 338 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 339 Autoconfiguration", RFC 2462, December 1998. 341 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 342 and M. Carney, "Dynamic Host Configuration Protocol for 343 IPv6 (DHCPv6)", RFC 3315, July 2003. 345 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 346 Host Configuration Protocol (DHCP) version 6", RFC 3633, 347 December 2003. 349 9.2. Informative References 351 [I-D.ietf-manet-smf] 352 Macker, J., "Simplified Multicast Forwarding for MANET", 353 draft-ietf-manet-smf-02 (work in progress), March 2006. 355 [I-D.jelger-autoconf-mla] 356 Jelger, C., "MANET Local IPv6 Addresses", 357 draft-jelger-autoconf-mla-00 (work in progress), 358 April 2006. 360 [I-D.njedjou-globalmm-ps] 361 Njedjou, E. and J. Riera, "Problem Statement for Global IP 362 Mobility Management", draft-njedjou-globalmm-ps-00 (work 363 in progress), May 2006. 365 [I-D.templin-autoconf-netlmm-dhcp] 366 Templin, F., "Network Localized Mobility Management using 367 DHCP", draft-templin-autoconf-netlmm-dhcp-01 (work in 368 progress), June 2006. 370 [I-D.thaler-autoconf-multisubnet-manets] 371 Thaler, D., "Multi-Subnet MANETs", 372 draft-thaler-autoconf-multisubnet-manets-00 (work in 373 progress), February 2006. 375 [I-D.thaler-intarea-multilink-subnet-issues] 376 Thaler, D., "Issues With Protocols Proposing Multilink 377 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 378 (work in progress), March 2006. 380 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 381 (MANET): Routing Protocol Performance Issues and 382 Evaluation Considerations", RFC 2501, January 1999. 384 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 385 Addresses", RFC 4193, October 2005. 387 Appendix A. Change Log 389 Changes from -00 to -01: 391 o new text on DHCPv6 prefix delegation and multilink subnet 392 considerations. 394 o various editorial changes 396 Authors' Addresses 398 Fred L. Templin 399 Boeing Phantom Works 400 P.O. Box 3707 MC 7L-49 401 Seattle, WA 98124 402 USA 404 Email: fred.l.templin@boeing.com 406 Steven W. Russert 407 Boeing Phantom Works 408 P.O. Box 3707 MC 7L-49 409 Seattle, WA 98124 410 USA 412 Email: steven.w.russert@boeing.com 414 Ian D. Chakeres 415 Boeing Phantom Works 416 P.O. Box 3707 MC 7L-49 417 Seattle, WA 98124 418 USA 420 Email: ian.chakeres@gmail.com 422 Seung Yi 423 Boeing Phantom Works 424 P.O. Box 3707 MC 7L-49 425 Seattle, WA 98124 426 USA 428 Email: seung.yi@boeing.com 430 Intellectual Property Statement 432 The IETF takes no position regarding the validity or scope of any 433 Intellectual Property Rights or other rights that might be claimed to 434 pertain to the implementation or use of the technology described in 435 this document or the extent to which any license under such rights 436 might or might not be available; nor does it represent that it has 437 made any independent effort to identify any such rights. Information 438 on the procedures with respect to rights in RFC documents can be 439 found in BCP 78 and BCP 79. 441 Copies of IPR disclosures made to the IETF Secretariat and any 442 assurances of licenses to be made available, or the result of an 443 attempt made to obtain a general license or permission for the use of 444 such proprietary rights by implementers or users of this 445 specification can be obtained from the IETF on-line IPR repository at 446 http://www.ietf.org/ipr. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights that may cover technology that may be required to implement 451 this standard. Please address the information to the IETF at 452 ietf-ipr@ietf.org. 454 Disclaimer of Validity 456 This document and the information contained herein are provided on an 457 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 458 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 459 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 460 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 461 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 462 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 464 Copyright Statement 466 Copyright (C) The Internet Society (2006). This document is subject 467 to the rights, licenses and restrictions contained in BCP 78, and 468 except as set forth therein, the authors retain all their rights. 470 Acknowledgment 472 Funding for the RFC Editor function is currently provided by the 473 Internet Society.