idnits 2.17.1 draft-templin-autoconf-dhcp-02.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 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 476. ** 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 issues found here. 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 (October 23, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 (-04) exists of draft-templin-autoconf-netlmm-dhcp-03 Summary: 8 errors (**), 0 flaws (~~), 3 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 Intended status: Informational I. Chakeres 5 Expires: April 26, 2007 S. Yi 6 Boeing Phantom Works 7 October 23, 2006 9 MANET Autoconfiguration using DHCP 10 draft-templin-autoconf-dhcp-02.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 April 26, 2007. 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). For the purpose of this 110 specification, MANET routers configure both a DHCP client and 111 relay that are tightly-coupled. 113 MANET Gateway (MG) 114 an MR that also provides gateway service to a provider network 115 and/or the global Internet. 117 MANET Local Address (MLA) 118 a Layer-3 unicast address/prefix configured by an MR that is used 119 only within the scope of the connected MANET. MRs can use MLAs 120 for intra-MANET data communications. (For IPv6, Unique Local 121 Addresses (ULAs) provide a natural MLA mechanism - see: [RFC4193] 122 and [I-D.jelger-autoconf-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 either ERAs from nearby MGs or a MG indication carried via the MANET 143 routing protocol through a means outside the scope of this 144 specification. If ERAs or MG indications are heard, it sends a small 145 number of ERSs to elicit immediate ERAs. When it needs to send ERSs, 146 the MR should set a small value (e.g., 2, 5, 10, etc.) in the TTL 147 (IPv4), Hop Limit (IPv6), or other Layer-3 protocol field of the 148 encapsulating header to limit the scope. 150 After the MR discovers MGs, it selects one or more MGs as default MGs 151 and selects one MG as its primary MG. The MR's DHCP client function 152 then forwards a DHCP DISCOVER (DHCPv4) or Solicit (DHCPv6) via its 153 relay function to an MLA for its primary MG. The DHCP request must 154 include an MLA for the MR in a DHCPv4 MLA option or the DHCPv6 "peer- 155 address" field (see: Section 3.4) and will elicit a DHCP reply from 156 the server with IP address/prefix delegations. 158 For IPv6, the MR can use DHCP prefix delegation per [RFC3633] and 159 configure addresses for itself and/or its attached devices from the 160 delegated prefixes per [I-D.thaler-autoconf-multisubnet-manets]. If 161 the ERAs include prefix options, the MR can alternatively configure 162 addresses from the advertised prefixes per [RFC2462]. In the latter 163 case, MGs should not advertise the same prefixes to more than one MR 164 so that multilink subnet issues are avoided - see: 165 [I-D.thaler-intarea-multilink-subnet-issues]. 167 After the MR configures global IP addresses/prefixes, it can send IP 168 packets to off-MANET destinations using any of the MGs in its default 169 MG list as egress gateways. For MANETs in which MGs can inject a 170 'default' route that propagates throughout the MANET, the MR can send 171 the IP packets without encapsulation at the expense of extra TTL 172 (IPv4) or Hop Limit (IPv6) decrementation. For MANETs in which MGs 173 cannot propagate a default route, the MR either: a) encapsulates IP 174 packets with an MLA for an MG as the destination address in the outer 175 header (i.e., tunnels the packets to the MG), or b) inserts an IPv4 176 source routing header (likewise IPv6 routing header) to ensure that 177 the packets will be forwarded through an MG. 179 The above MR specifications are analogous to the more detailed Mobile 180 Node (MN) specifications found in 181 ([I-D.templin-autoconf-netlmm-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. (In certain use case 187 scenarios, MGs can inject MG indications into the MANET routing 188 protocol instead of sending periodic ERAs.) The ERAs should set a 189 small value (e.g., 2, 5, 10, etc.) in the TTL (IPv4), Hop Limit 190 (IPv6), or other protocol field of the encapsulating header to limit 191 the scope. MGs should not advertise the same prefixes to more than 192 one MR so that multilink subnet issues are avoided - see: 193 [I-D.thaler-intarea-multilink-subnet-issues]. 195 MGs act as BOOTP/DHCP relays for the DHCP requests/replies exchanged 196 between MRs and DHCP servers. (When the DHCP server function resides 197 on the MG itself, the MG acts as a DHCP server.) For DHCPv4, when a 198 MG acting as a relay forwards a MR's DHCP request that includes an 199 MLA option, it writes its own address in the 'giaddr' field, i.e., it 200 overwrites the value that was written into 'giaddr' by the MR's relay 201 function. 203 For each DHCP reply message it processes pertaining to address/prefix 204 delegation, the MG creates a tunnel (if necessary) with the tunnel's 205 destination address set to the MLA for the MR encoded in the DHCPv4 206 MLA option or the DHCPv6 "peer-address" field (see: Section 3.4). 207 The MG then creates entries in its IP forwarding table that point to 208 the tunnel for each delegated IP address/prefix and relays the reply 209 to the MLA for the MR. 211 When MGs forward IP packets to an MR, they either: a) encapsulate the 212 packets with the MLA for the MR as the destination address in the 213 outer header (i.e., tunnel the packets to the MR), or b) insert an 214 IPv4 source routing header (likewise IPv6 routing header) to ensure 215 that the packets will be forwarded to the correct MR. 217 The above MG specifications are analogous to the more detailed Access 218 Router (AR) specifications found in 219 ([I-D.templin-autoconf-netlmm-dhcp], Section 4.2). 221 3.3. DHCP Server Extensions 223 DHCP servers can reside on provider networks, the Internet or on the 224 MGs themselves. 226 DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: 227 Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server 228 copies the option into the corresponding DHCPv4 reply message(s). 230 No MANET-specific extensions are required for DHCPv6 servers. 232 3.4. MLA Encapsulation 234 For DHCPv6, the MLA is encoded directly in the "peer-address" field 235 of DHCPv6 requests/replies. 237 For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is 238 required to encode an MLA so that the MG can direct DHCPv4 replies to 239 the correct MR, which may be multiple Layer-3 hops away. The format 240 of the DHCPv4 MLA option is given below: 242 Code Len Ether Type MLA 243 +-----+-----+-----+-----+-----+-----+--- 244 | TBD | n | type | a1 | a2 | ... 245 +-----+-----+-----+-----+-----+-----+--- 247 Code 248 a one-octet field that identifies the option type (see: 249 Section 5). 251 Len 252 a one-octet field that encodes the remaining option length. 254 Ether Type 255 a type value from the IANA "ethernet-numbers" registry. 257 MLA 258 a variable-length MANET Local Address (MLA). 260 3.5. MANET Flooding 262 MRs and MGs in Layer-3 MANETs that implement this specification 263 require a MANET flooding mechanism (e.g., Simplified Multicast 264 Forwarding (SMF) [I-D.ietf-manet-smf]) so that site-scoped multicast 265 ERA/ERS messages can be propagated across multiple Layer-3 hops. 267 4. Operation with Multiple MGs 269 When the Layer-2 or Layer-3 MANET connects to provider networks or 270 the global Internet via multiple MGs, MR operation and localized 271 mobility management is based on the nature of MG deployment. 273 For a set of MGs that attach to the same provider network, MRs can 274 retain their global IP address/prefix delegations as they move 275 between different MGs if the network configures a mobility anchor 276 point that participates with the MGs and MRs in a localized mobility 277 management scheme, e.g., see: [I-D.templin-autoconf-netlmm-dhcp]. 279 For a set of MGs that attach to different provider networks and/or 280 serve different global IP prefixes from within the same provider 281 network, MRs must configure new global IP addresses/prefixes as they 282 change between different MGs unless inter-MG tunnels and routing 283 protocol exchanges are supported, e.g., see: 284 [I-D.templin-autoconf-netlmm-dhcp], Appendix A. 286 Global mobility management mechanisms for MRs that configure new 287 global IP addresses/prefixes as they move between different MGs are 288 beyond the scope of this document. 290 5. IANA Considerations 292 A new DHCP option code is requested for the DHCP MLA Option in the 293 IANA "bootp-dhcp-parameters" registry. 295 6. Security Considerations 297 Security considerations for this document are the same as for 298 [I-D.templin-autoconf-netlmm-dhcp]. 300 Threats relating to MANET routing protocols also apply to this 301 document. 303 7. Related Work 305 Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC 306 program. Various proposals targeted for the IETF AUTOCONF working 307 group have suggested stateless mechanisms for address configuration. 309 8. Acknowledgements 311 The Naval Research Lab (NRL) Information Technology Division uses 312 DHCP in their MANET research testbeds. 314 The following individuals (in chronological order) have provided 315 valuable input: Thomas Henderson. 317 9. References 319 9.1. Normative References 321 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 322 September 1981. 324 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 325 converting network protocol addresses to 48.bit Ethernet 326 address for transmission on Ethernet hardware", STD 37, 327 RFC 826, November 1982. 329 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 330 September 1985. 332 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 333 September 1991. 335 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 336 RFC 2131, March 1997. 338 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 339 Extensions", RFC 2132, March 1997. 341 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 342 (IPv6) Specification", RFC 2460, December 1998. 344 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 345 Discovery for IP Version 6 (IPv6)", RFC 2461, 346 December 1998. 348 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 349 Autoconfiguration", RFC 2462, December 1998. 351 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 352 and M. Carney, "Dynamic Host Configuration Protocol for 353 IPv6 (DHCPv6)", RFC 3315, July 2003. 355 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 356 Host Configuration Protocol (DHCP) version 6", RFC 3633, 357 December 2003. 359 9.2. Informative References 361 [I-D.ietf-manet-smf] 362 Macker, J., "Simplified Multicast Forwarding for MANET", 363 draft-ietf-manet-smf-02 (work in progress), March 2006. 365 [I-D.jelger-autoconf-mla] 366 Jelger, C., "MANET Local IPv6 Addresses", 367 draft-jelger-autoconf-mla-01 (work in progress), 368 October 2006. 370 [I-D.templin-autoconf-netlmm-dhcp] 371 Templin, F., "Network Localized Mobility Management using 372 DHCP", draft-templin-autoconf-netlmm-dhcp-03 (work in 373 progress), September 2006. 375 [I-D.thaler-autoconf-multisubnet-manets] 376 Thaler, D., "Multi-Subnet MANETs", 377 draft-thaler-autoconf-multisubnet-manets-00 (work in 378 progress), February 2006. 380 [I-D.thaler-intarea-multilink-subnet-issues] 381 Thaler, D., "Issues With Protocols Proposing Multilink 382 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 383 (work in progress), March 2006. 385 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 386 (MANET): Routing Protocol Performance Issues and 387 Evaluation Considerations", RFC 2501, January 1999. 389 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 390 Addresses", RFC 4193, October 2005. 392 Appendix A. Change Log 394 Changes from -01 to -02: 396 o minor updates for consistency with recent developments 398 Changes from -00 to -01: 400 o new text on DHCPv6 prefix delegation and multilink subnet 401 considerations. 403 o various editorial changes 405 Authors' Addresses 407 Fred L. Templin 408 Boeing Phantom Works 409 P.O. Box 3707 MC 7L-49 410 Seattle, WA 98124 411 USA 413 Email: fred.l.templin@boeing.com 414 Steven W. Russert 415 Boeing Phantom Works 416 P.O. Box 3707 MC 7L-49 417 Seattle, WA 98124 418 USA 420 Email: steven.w.russert@boeing.com 422 Ian D. Chakeres 423 Boeing Phantom Works 424 P.O. Box 3707 MC 7L-49 425 Seattle, WA 98124 426 USA 428 Email: ian.chakeres@gmail.com 430 Seung Yi 431 Boeing Phantom Works 432 P.O. Box 3707 MC 7L-49 433 Seattle, WA 98124 434 USA 436 Email: seung.yi@boeing.com 438 Full Copyright Statement 440 Copyright (C) The Internet Society (2006). 442 This document is subject to the rights, licenses and restrictions 443 contained in BCP 78, and except as set forth therein, the authors 444 retain all their rights. 446 This document and the information contained herein are provided on an 447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 449 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 450 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 451 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 454 Intellectual Property 456 The IETF takes no position regarding the validity or scope of any 457 Intellectual Property Rights or other rights that might be claimed to 458 pertain to the implementation or use of the technology described in 459 this document or the extent to which any license under such rights 460 might or might not be available; nor does it represent that it has 461 made any independent effort to identify any such rights. Information 462 on the procedures with respect to rights in RFC documents can be 463 found in BCP 78 and BCP 79. 465 Copies of IPR disclosures made to the IETF Secretariat and any 466 assurances of licenses to be made available, or the result of an 467 attempt made to obtain a general license or permission for the use of 468 such proprietary rights by implementers or users of this 469 specification can be obtained from the IETF on-line IPR repository at 470 http://www.ietf.org/ipr. 472 The IETF invites any interested party to bring to its attention any 473 copyrights, patents or patent applications, or other proprietary 474 rights that may cover technology that may be required to implement 475 this standard. Please address the information to the IETF at 476 ietf-ipr@ietf.org. 478 Acknowledgment 480 Funding for the RFC Editor function is provided by the IETF 481 Administrative Support Activity (IASA).