Network Working Group F. Templin Internet-Draft S. Russert Expires: December 4, 2006 I. Chakeres S. Yi Boeing Phantom Works June 2, 2006 MANET Autoconfiguration using DHCP draft-templin-autoconf-dhcp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile Ad-hoc Networks (MANETs) comprise MANET routers and their attached devices, and connect to the global Internet via one or more MANET gateways. MANET routers that require global Internet access must have a way to automatically configure globally routable and unique IP addresses/prefixes. This document specifies mechanisms for MANET address autoconfiguration (AUTOCONF) based on the Dynamic Host Templin, et al. Expires December 4, 2006 [Page 1] Internet-Draft MANET Autoconfiguration using DHCP June 2006 Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6 are given. 1. Introduction Mobile Ad-hoc Networks (MANETs) comprise MANET Routers (MRs) that have zero or more attached devices and participate in a routing protocol over limited-range (typically wireless) interfaces such that packets exchanged between MRs may need to be forwarded across multiple hops. MANETs attach to provider networks (and/or the global Internet) via zero or more MANET Gateways (MGs), and MRs may be multiple hops away from their nearest MG in some scenarios. MRs that require global Internet access must have a means to autoconfigure global IP addresses/prefixes and/or other configuration information. MANETs that comprise MRs with homogeneous MANET interfaces can configure the routing protocol to operate as a Layer-2 mechanism (e.g., IEEE 802) for route calculations and packet forwarding such that the Layer-3 protocol (e.g., IP) sees the MANET as a non- broadcast, multiple access (NBMA) link. When a Layer-2 flooding mechanism is also used, the Layer-3 protocol sees the MANET as a broadcast/multicast capable link, i.e., the same as for a (bridged) campus LAN. In such Layer-2 MANETs, MRs and MGs can autoconfigure global IP addresses/prefixes using standard BOOTP/DHCP [RFC0951] [RFC2131][RFC3315] and neighbor discovery [RFC0826][RFC1256][RFC2461] mechanisms. MANETs that comprise MRs with heterogeneous MANET interfaces must configure the routing protocol to operate as a Layer-3 mechanism such that route calculations and packet forwarding are based on Layer-3 MANET-local addresses/prefixes (MLAs) to avoid issues associated with bridging media types with dissimilar Layer-2 address formats and maximum transmission units (MTUs). In such Layer-3 MANETs, standard DHCP and neighbor discovery mechanisms are not sufficient to support global IP address/prefix autoconfiguration. This document specifies DHCP and neighbor discovery extensions for MR autoconfiguration in Layer-3 MANETs as well as details of operation for multiple MGs that apply to both Layer-2 and Layer-3 MANETs. Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are given. 2. Terminology The terminology in the normative references apply; the following terms are defined within the scope of this document: Templin, et al. Expires December 4, 2006 [Page 2] Internet-Draft MANET Autoconfiguration using DHCP June 2006 Mobile Ad-hoc Network (MANET) a connected network region (i.e., a "site") that comprises routers that maintain a routing structure among themselves in a relatively arbitrary fashion over dynamic (wireless) interfaces. Further information on the characteristics of MANETs can be found in [RFC2501]. MANET Interface a node's attachment to a MANET. MANET Router (MR) a node with zero or more attached devices that participates in the MANET routing protocol on one or more limited-range (typically wireless) MANET interface(s). MANET Gateway (MG) a MR that also provides gateway service to a provider network and/or the global Internet. MANET Local Address (MLA) a Layer-3 unicast address/prefix configured by a MR that is valid only within the scope of the connected MANET. For Layer-3 MANETs, MRs use MLAs to operate the routing protocol; for both Layer-2 and Layer-3 MANETs, MRs use MLAs for intra-MANET data communications. (For MANETs that use IPv6, Unique Local Addresses (ULAs) provide a natural MLA mechanism - see: [RFC4193] and [I-D.jelger-autoconf- mla]). Extended Router Advertisement/Solicitation (ERA/ERS) an IP Router Advertisement/Solicitation (RA/RS) message [RFC1256] [RFC2461] encapsulated in an outer header for transmission over a Layer-3 MANET with destination address set to a MLA or a site- scoped multicast address (see: Section 3.5). 3. Autoconfiguration Extensions for Layer-3 MANETs The following sections specify extensions necessary to support DHCP- based autoconfiguration for Layer-3 MANETs: 3.1. MANET Router (MR) Extensions When a MR first powers on, activates a MANET interface, or when it receives an indication of movement to a new MANET, it configures one or more MLAs (through a means outside the scope of this specification) and engages in the MANET routing protocol. Next, if the MR requires global IP address/prefix delegations, it listens for ERAs from nearby MGs and (if none are heard) sends a small number of Templin, et al. Expires December 4, 2006 [Page 3] Internet-Draft MANET Autoconfiguration using DHCP June 2006 ERSs to elicit immediate ERAs. When it needs to send ERSs, the MR should set a small value (e.g., 2, 5, 10, etc.) in the TTL (IPv4), Hop Limit (IPv6), or other Layer-3 protocol field of the encapsulating header to limit the scope. After the MR receives ERAs from MGs, it selects one or more MGs as default MGs and selects one MG as its primary MG. Acting as a DHCP client, the MR then sends a DHCP request to a MLA for its primary MG. The DHCP request must include a MLA for the MR in a DHCPv4 MLA option or the DHCPv6 "peer-address" field (see: Section 3.4) and will elicit a DHCP reply from the DHCP server with IP address/prefix delegations. After the MR configures global IP addresses/prefixes, it can send IP packets to off-MANET destinations using any of the MGs in its default MG list as egress gateways. For MANETs in which the MANET protocol is IP-based and MGs can inject a 'default' route that propagates throughout the MANET, the MR can send the IP packets without encapsulation at the expense of extra TTL (IPv4) or Hop Limit (IPv6) decrementation. For MANETs in which the MANET protocol is not IP- based and/or MGs cannot propagate a default route, the MR either: a) encapsulates IP packets with a MLA for a MG as the destination address in the outer header (i.e., tunnels the packets to the MG), or b) inserts an IPv4 source routing header (likewise IPv6 routing header) to ensure that the packets will be forwarded through a MG. The above MR specifications are analogous to the more detailed Mobile Node (MN) specifications found in ([I-D.templin-autoconf-netlmm- dhcp], section 4.1). 3.2. MANET Gateway Extensions MGs send periodic/solicited ERAs on their attached MANET interfaces instead of sending periodic/solicited RAs. The ERAs should set a small value (e.g., 2, 5, 10, etc.) in the TTL (IPv4), Hop Limit (IPv6), or other protocol field of the encapsulating header to limit the scope. MGs act as BOOTP/DHCP relays for the DHCP requests/ replies exchanged between MRs and DHCP servers. (When the DHCP server function resides on the MG itself, the MG acts as a DHCP server.) For each DHCP reply message, the MG creates a tunnel (if necessary) with the tunnel's destination address set to the MLA for the MR encoded in the DHCPv4 MLA option or the DHCPv6 "peer-address" field (see: Section 3.4). Th MG then creates entries in its IP forwarding table that point to the tunnel for each delegated IP address/prefix and relays the reply to the MLA for the MR. When MGs forward IP packets to a MR, they either: a) encapsulate the Templin, et al. Expires December 4, 2006 [Page 4] Internet-Draft MANET Autoconfiguration using DHCP June 2006 packets with the MLA for the MR as the destination address in the outer header (i.e., tunnel the packets to the MR), or b) insert an IPv4 source routing header (likewise IPv6 routing header) to ensure that the packets will be forwarded to the correct MR. The above MG specifications are analogous to the more detailed Access Router (AR) specifications found in ([I-D.templin-autoconf-netlmm- dhcp], Section 4.2). 3.3. DHCP Server Extensions DHCP servers can reside on provider networks, the Internet or on the MGs themselves. DHCPv4 servers examine DHCPv4 requests for a DHCPv4 MLA option (see: Section 3.4). If a DHCPv4 MLA option is present, the DHCPv4 server copies the option into the corresponding DHCPv4 reply message(s). No special MANET-specific extensions are required for DHCPv6 servers. 3.4. MLA Encapsulation For DHCPv6, the MLA is encoded directly in the "peer-address" field of DHCPv6 requests/replies. For DHCPv4, a new DHCPv4 option [RFC2132] called the 'MLA option' is required to encode a MLA so that the MG can direct DHCPv4 replies to the correct MR (which may be multiple Layer-3 hops away). The format of the DHCPv4 MLA option is given below: Code Len Ether Type MLA +-----+-----+-----+-----+-----+-----+--- | TBD | n | type | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+--- Code a one-octet field that identifies the option type (see: Section 5). Len a one-octet field that encodes the remaining option length. Ether Type a type value from the IANA "ethernet-numbers" registry. Templin, et al. Expires December 4, 2006 [Page 5] Internet-Draft MANET Autoconfiguration using DHCP June 2006 MLA a variable-length MANET Local Address (MLA). 3.5. MANET Flooding MRs and MGs in Layer-3 MANETs that implement this specification require a MANET flooding mechanism (e.g., Simplified Multicast Forwarding (SMF) [I-D.ietf-manet-smf]) so that site-scoped multicast ERA/ERS messages can be propagated across multiple Layer-3 hops. 4. Operation with Multiple MGs When the Layer-2 or Layer-3 MANET connects to provider networks or the global Internet via multiple MGs, MR operation and localized mobility management is based on the nature of MG deployment. For a set of MGs that attach to the same provider network and serve the same global IP prefixes, MRs can retain their global IP address/ prefix delegations as they move between different MGs within the set if the provider network configures an IP prefix mobility anchor point that participates with the MGs and MRs in a localized mobility management scheme, e.g., [I-D.templin-autoconf-netlmm-dhcp]. For a set of MGs that attach to different provider networks and/or serve different global IP prefixes from within the same provider network, MRs must configure new global IP addresses/prefixes as they change between different MGs unless inter-MG tunnels and routing protocol exchanges are supported (see: [I-D.templin-autoconf-netlmm- dhcp], Appendix A). Global mobility management mechanisms for MRs that configure new global IP addresses/prefixes as they move between different MGs are beyond the scope of this document; see: [I-D.njedjou-globalmm-ps] for a global mobility management problem statement. 5. IANA Considerations A new DHCP option code is requested for the DHCP MLA Option in the IANA "bootp-dhcp-parameters" registry. 6. Security Considerations Security considerations for this document are the same as for [I-D.templin-autoconf-netlmm-dhcp]. Templin, et al. Expires December 4, 2006 [Page 6] Internet-Draft MANET Autoconfiguration using DHCP June 2006 Threats relating to MANET routing protocols also apply to this document. 7. Related Work Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC program. Various proposals targeted for the IETF AUTOCONF working group have suggested stateless mechanisms for address configuration. 8. Acknowledgements The Naval Research Lab (NRL) Information Technology Division uses DHCP in their MANET research testbeds. The following individuals (in chronological order) have provided valuable input: Thomas Henderson. 9. References 9.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985. [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Templin, et al. Expires December 4, 2006 [Page 7] Internet-Draft MANET Autoconfiguration using DHCP June 2006 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 9.2. Informative References [I-D.ietf-manet-smf] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-02 (work in progress), March 2006. [I-D.jelger-autoconf-mla] Jelger, C., "MANET Local IPv6 Addresses", draft-jelger-autoconf-mla-00 (work in progress), April 2006. [I-D.njedjou-globalmm-ps] Njedjou, E. and J. Riera, "Problem Statement for Global IP Mobility Management", draft-njedjou-globalmm-ps-00 (work in progress), May 2006. [I-D.templin-autoconf-netlmm-dhcp] Templin, F., "Network Localized Mobility Management using DHCP", draft-templin-autoconf-netlmm-dhcp-01 (work in progress), June 2006. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. Templin, et al. Expires December 4, 2006 [Page 8] Internet-Draft MANET Autoconfiguration using DHCP June 2006 Authors' Addresses Fred L. Templin Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Steven W. Russert Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: steven.w.russert@boeing.com Ian D. Chakeres Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: ian.chakeres@gmail.com Seung Yi Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: seung.yi@boeing.com Templin, et al. Expires December 4, 2006 [Page 9] Internet-Draft MANET Autoconfiguration using DHCP June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Templin, et al. Expires December 4, 2006 [Page 10]