[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-droms-nemo-dhcpv6-pd) 00 01 02 03

IPv6 Group                                                      R. Droms
Internet-Draft                                                P. Thubert
Expires: February 5, 2006                                          Cisco
                                                          August 4, 2005


                   DHCPv6 Prefix Delegation for NEMO
                      draft-ietf-nemo-dhcpv6-pd-00

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 February 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   One aspect of network mobility support is the assignment of a prefix
   or prefixes to a mobile router (MR) for use on the links in the
   mobile network.  DHCPv6 prefix delegation can be used for this
   configuration task.

1.  Introduction

   One aspect of network mobility support is the assignment of a prefix



Droms & Thubert         Expires February 5, 2006                [Page 1]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


   or prefixes to a mobile router for use on the links in the mobile
   network.  DHCPv6 prefix delegation [1] (DHCPv6PD) can be used for
   this configuration task, whether from the Home Network or locally
   from an Access Network.

2.  Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
   interpreted as described in RFC2119 [2].

   The following terms used in this document are defined in the IPv6
   Addressing Architecture document [3]:
      link-local unicast address
      link-local scope multicast address

   The following terms used in this document are defined in the mobile
   IPv6 specification [4]:
      home agent (HA)
      home link

   The following terms used in this document are defined in the mobile
   network terminology document [5]:
      mobile router (MR)
      mobile network
      mobile host (MH)

   The following terms used in this document are defined in the DHCPv6
   [6] and DHCPv6 prefix delegation [1] specifications:
      delegating router (DR)
      requesting router (RR)
      DHCPv6 relay agent

3.  Application of DHCPv6 prefix delegation to mobile networks

   The network mobility requirements document [7] defines a solution for
   mobile IPv6 networks based on the mobile IPv6 protocol [4].  In this
   solution, a MR uses the mobile IPv6 protocol to establish a maintain
   a session with its HA, and uses bidirectional tunneling between the
   MR and HA to provide a path through which hosts attached to links in
   the mobile network can maintain connectivity with nodes not in the
   mobile network.

   The requirements in basic network mobility support [7] include the
   ability of the MR to receive delegated prefixes that can then be
   assigned to links in the mobile network.  DHCPv6PD can be used to
   meet this requirement for prefix delegation.




Droms & Thubert         Expires February 5, 2006                [Page 2]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


3.1  Delegating Home prefixes

   To use DHCPv6PD for mobile networks, the HA assumes the role of the
   DR and the MR assumes the role of the RR.  Throughout the remainder
   of this document, the HA will be assumed to be acting as a DHCPv6PD
   DR and the MR will be assumed to be acting as a RR.

   The HA and MR exchange DHCPv6PD protocol messages through the tunnel
   connecting them.  The tunnel acts as the link labeled "DSL to
   subscriber premises" in figure 1 of the DHCPv6PD specification.

   The HA (acting as the DR) is provisioned with prefixes to be assigned
   using any of the prefix assignment mechanisms described in the
   DHCPv6PD specifications.  Other updates to the HA data structures
   required as a side effect of prefix delegation are specified by the
   particular network mobility protocol.  For example, in the case of
   Basic Network Mobility Support [8], the HA would add an entry in its
   binding cache registering the delegated prefix to the MR to which the
   prefix was delegated.

3.1.1  Use of HA-MR tunnel for DHCPv6 messages

   The DHCPv6 specification requires the use of link-local unicast and
   link-local scope multicast addresses in DHCPv6 messages (except in
   certain cases as defined in section 22.12 of the DHCPv6
   specification).  Section 10.4.2 of the mobile IPv6 specification
   describes forwarding of intercepted packets, and the third paragraph
   of that section begins:

      However, packets addressed to the mobile node's link-local address
      MUST NOT be tunneled to the mobile node.

   The DHCPv6 messages exchanged between the HA and the MR originate
   only with the HA and the MR, and therefore are not "intercepted
   packets" and may be sent between the HA and the MR through the
   tunnel.

3.1.2  Exchanging DHCPv6 messages when HA and MR are on the same link

   When the MR is on its home link, the HA uses the home link to
   exchange DHCPv6PD messages with the MR, even if there is a tunnel
   across the home link between the MR and the HA.  It is the
   responsibility of the implementation to determine when the MR is on
   its home link and to avoid use of any existing tunnel.

3.1.3  Location of DHCPv6PD Delegating Router function

   Support of DHCPv6PD in a mobile network is optional.  If DHCPv6PD is



Droms & Thubert         Expires February 5, 2006                [Page 3]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


   used then the DHCPv6PD DR function MUST be implemented in the HA for
   the MR.  The use of a DHCPv6 relay agent is not defined for DHCPv6PD.

3.1.4  Other DHCPv6 functions

   The DHCPv6 messages exchanged between the MR and the HA may also be
   used for other DHCPv6 functions in addition to DHCPv6PD.  For
   example, the HA may assign global addresses to the MR and may pass
   other configuration information such as a list of available DNS
   recursive resolvers to the MR using the same DHCPv6 messages as used
   for DHCPV6PD.

   The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR
   for MRs.

3.2  Delegating Access Prefixes

   A Mobile Router may also obtain a temporary delegated prefix from its
   Access Router (acting as a DHCPv6PD DR) while the MR is roaming
   within the AR space.

   This is used for instance if the MR opens a network for anonymous
   visitors to roam in.  In that model, the delegated network is
   advertised in the clear, as opposed to the MR's own Mobile Network
   Prefixes, which can stay private, over secured media.

   As a result, the CareOf Addresses of the visitors in a nested
   structure are all aggregated by a larger prefix owned, subdelegated,
   and advertised to the infrastructure by the Access Router itself.

   It is possible to protect the privacy of both parties between a VMN
   that implements RFC 3041 [9] and a visited MR that advertises only
   the delegated prefixes in the clear.

   In the case of a nested structure, it is expected that the AR and the
   MR maintain a tunnel and that the connectivity between the two is
   maintained somehow; this can be achieved by:

   o  Performing a routing protocol such as a MANET within the nested
      topology.
   o  performing some L3 bridging technique between AR and MRs.
   o  placing a Nemo Home Agent at the AR so that the MR registers the
      mobility of the delegated prefix while it is roaming inside or
      outside the nested structure below the AR.

   It may be beneficial for the Mobile Router to use its address within
   its delegated prefix as CareOf to register to its Home Agent.  As a
   result, the MR gets some advantages similar to those obtained with



Droms & Thubert         Expires February 5, 2006                [Page 4]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


   HMIP.

4.  Security Considerations

   This document describes the use of DHCPv6 for prefix delegation in
   mobile networks.  It does not introduce any additional security
   considerations beyond those described in the "Security
   Considerations" section of the DHCPv6 base specification [6] and the
   "Security Considerations" of the DHCPv6 Prefix Delegation
   specification [1].

   Following the DHCPv6 Prefix Delegation specification, HAs and MRs
   SHOULD use DHCPv6 authentication as described in section
   "Authentication of DHCP messages" of the DHCPv6 specification [6], to
   guard against attacks mounted through prefix delegation.

5.  IANA Considerations

   This document describes the use of DHCPv6 for prefix delegation in
   mobile networks.  It does not introduce any additional IANA
   considerations.

6.  Normative References

   [1]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
        Configuration Protocol (DHCP) version 6", RFC 3633,
        December 2003.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

   [4]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [5]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
        draft-ietf-nemo-terminology-03 (work in progress),
        February 2005.

   [6]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
        RFC 3315, July 2003.

   [7]  Ernst, T., "Network Mobility Support Goals and Requirements",
        draft-ietf-nemo-requirements-04 (work in progress),
        February 2005.



Droms & Thubert         Expires February 5, 2006                [Page 5]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


   [8]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
        "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
        January 2005.

   [9]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.


Authors' Addresses

   Ralph Droms
   Cisco
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Phone: +1 978.936.1674
   Email: rdroms@cisco.com


   Pascal Thubert
   Cisco
   Village d'Entreprises Green Side
   400, Avenue Roumanille
   Biot - Sophia Antipolis  06410
   FRANCE

   Email: pthubert@cisco.com

Appendix A.  Changes Log

   Rev -01: The section on access prefix delegation was added.  That
   section provides a mechanism that is very close to HMIP but purely
   based on standard DHCP-PD.  It is limited to Nemo applications, but
   it provides additional features, including the privacy of the mobile
   access router.

   Rev -02: The section on optimization of access prefix delegation was
   removed.

   WG work item: Published as draft-ietf-nemo-dhcpv6-pd-02.txt










Droms & Thubert         Expires February 5, 2006                [Page 6]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


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 (2005).  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.





Droms & Thubert         Expires February 5, 2006                [Page 7]


Internet-Draft      DHCPv6 Prefix Delegation for NEMO        August 2005


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Droms & Thubert         Expires February 5, 2006                [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/