Network Working Group                                         F. Templin
Internet-Draft                                                S. Russert
Expires: December 23, 2006                                   I. Chakeres
                                                                   S. Yi
                                                    Boeing Phantom Works
                                                           June 21, 2006


                   MANET Autoconfiguration using DHCP
                   draft-templin-autoconf-dhcp-01.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 23, 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 autoconfiguration (AUTOCONF) based on the Dynamic Host



Templin, et al.         Expires December 23, 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
   unified 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][RFC3633] and neighbor discovery
   [RFC0826][RFC1256][RFC2461][RFC2462] 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 since the MANET may appear
   as multiple links.

   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 23, 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 MANET
      routers that maintain a routing structure among themselves in a
      relatively arbitrary fashion over dynamic (wireless) MANET
      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)
      an 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 an MR that is used
      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 can use MLAs for intra-MANET data
      communications.  (For 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 an 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 an 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 23, 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 an MLA for its primary
   MG.  The DHCP request must include an 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 server with IP address/prefix
   delegations.

   For IPv6, the MR can use DHCP prefix delegation per [RFC3633] and
   configure addresses for itself and/or its attached devices from the
   delegated prefixes per [I-D.thaler-autoconf-multisubnet-manets].  If
   the ERAs include prefix options, the MR can alternatively configure
   addresses from the advertised prefixes per [RFC2462].  In the latter
   case, MGs should not advertise the same prefixes to more than one MR
   so that multilink subnet issues are avoided - see: [I-D.thaler-
   intarea-multilink-subnet-issues].

   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 routing
   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 routing
   protocol is not IP-based and/or MGs cannot propagate a default route,
   the MR either: a) encapsulates IP packets with an MLA for an 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 an 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



Templin, et al.         Expires December 23, 2006               [Page 4]


Internet-Draft     MANET Autoconfiguration using DHCP          June 2006


   server function resides on the MG itself, the MG acts as a DHCP
   server.)

   For each DHCP reply message it processes pertaining to address/prefix
   delegation, 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).
   The 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 an MR, they either: a) encapsulate the
   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 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 an 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 | ...
   +-----+-----+-----+-----+-----+-----+---





Templin, et al.         Expires December 23, 2006               [Page 5]


Internet-Draft     MANET Autoconfiguration using DHCP          June 2006


   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.

   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, MRs can
   retain their global IP address/prefix delegations as they move
   between different MGs if the network configures a mobility anchor
   point that participates with the MGs and MRs in a localized mobility
   management scheme, e.g., see: [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, e.g., 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




Templin, et al.         Expires December 23, 2006               [Page 6]


Internet-Draft     MANET Autoconfiguration using DHCP          June 2006


   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].

   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",



Templin, et al.         Expires December 23, 2006               [Page 7]


Internet-Draft     MANET Autoconfiguration using DHCP          June 2006


              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
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, 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.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 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.

   [I-D.thaler-autoconf-multisubnet-manets]
              Thaler, D., "Multi-Subnet MANETs",
              draft-thaler-autoconf-multisubnet-manets-00 (work in
              progress), February 2006.



Templin, et al.         Expires December 23, 2006               [Page 8]


Internet-Draft     MANET Autoconfiguration using DHCP          June 2006


   [I-D.thaler-intarea-multilink-subnet-issues]
              Thaler, D., "Issues With Protocols Proposing Multilink
              Subnets", draft-thaler-intarea-multilink-subnet-issues-00
              (work in progress), March 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.


Appendix A.  Change Log

   Changes from -00 to -01:

   o  new text on DHCPv6 prefix delegation and multilink subnet
      considerations.

   o  various editorial changes






























Templin, et al.         Expires December 23, 2006               [Page 9]


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 23, 2006              [Page 10]


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 23, 2006              [Page 11]