[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                     Sheng Jiang
                                                            Sean Shen
Internet Draft                            Huawei Technologies Co., Ltd
Expires: April 2009                                 October 27th, 2008

             DHCPv6 and CGA Interaction: Problem Statement


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.

   This document may only be posted in an Internet-Draft.

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 25, 2009.


   This document presents a problem statement for the possible
   interactions between DHCPv6 and CGA. Firstly, in order to support the
   co-existing scenarios of DHCPv6 and CGA, Some operations are
   clarified for the interaction of DHCPv6 servers and CGA-associated
   hosts. Then, some extended scenarios are also discussed in this
   document, including using CGAs in DHCPv6 operations to enhance the
   security features and using DHCPv6 to serve the CGA generation.

Jiang & Shen           Expires April 25, 2009                 [Page 1]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-00.txt      October 2008

Table of Contents

   1. Introduction................................................2
   2. Terminology.................................................2
   3. Co-existing of DHCPv6 and CGA................................3
   4. What DHCPv6 can do for CGA...................................3
   5. What CGA can do for DHCPv6...................................4
   6. Security Considerations......................................5
   7. IANA Considerations.........................................5
   8. References..................................................5
      8.1. Normative References....................................5
      8.2. Informative References..................................5
   Author's Addresses.............................................6
   Intellectual Property Statement.................................6
   Disclaimer of Validity.........................................7
   Copyright Statement............................................7

1. Introduction

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can
   assign addresses statefully. Although there are other ways to assign
   IPv6 address [RFC4339], DHCPv6 is still useful when administrator
   desire more control over addressing. Besides, DHCPv6 also be used to
   distribute other information when dialog state is critical [RFC4242].

   Cryptographically Generated Addresses (CGA) [RFC3972] are IPv6
   addresses for which the interface identifiers are generated by
   computing a cryptographic one-way hash function from a public key and
   auxiliary parameters. By using the associate public & private keys as
   described in SEcure Neighbor Discovery (SEND) [RFC3971], CGA can
   protect Neighbor Discovery Protocol (NDP) [RFC4861], i.e. it provides
   address validation and integrity protection for NDP messages.

   This document presents a problem statement for the possible
   interactions between DHCPv6 and CGA. Firstly, in order to support the
   co-existing scenarios of DHCPv6 and CGA, Some operations are
   clarified for the interaction of DHCPv6 servers and CGA-associated
   hosts. Then, some extended scenarios are also discussed in this
   document, including using CGAs in DHCPv6 operations to enhance the
   security features and using DHCPv6 to serve the CGA generation.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

Jiang & Shen           Expires April 25, 2009                 [Page 2]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-00.txt      October 2008

3. Co-existing of DHCPv6 and CGA

   As an important IPv6 technique, CGA is used efficiently on the
   stateless address configuration of IPv6 address. The public key
   system associated with CGA address provides message origin validation
   and integrity protection without negotiation and transportation of
   key materials. {more}

   The current CGA specifications does not mandate which device
   generates a CGA address. In many cases, a CGA address is generated by
   the associated key pair owner, which normally is also the host that
   will use the CGA address.

   However, in a DHCPv6-managed network, hosts should obtain IPv6
   addresses only from a DHCPv6 server. This difference of roles needs
   to be carefully considered during the interaction of CGA and DHCPv6.

   Operations, as clarified in the next paragraph, support the co-
   existing of CGA's host self-generate address mechanism and DHCPv6
   managed address mechanism.

   This can be solved by validation procedure, which has been defined in
   the current DHCPv6. A node requests DHCPv6 server to grant a CGA
   generated by the node itself, listing the CGA addresses in IA options,
   which has been defined in [RFC3315]. According to whether the CGA
   matches the CGA-related configuration parameters of the network, the
   DHCPv6 server sends an acknowledgement to the node, grant the usage
   of the CGA or indicate the node that it must generate a new CGA with
   the CGA-related configuration parameters of the network. In the
   meantime, the DHCPv6 server has had the opportunity to log the
   address/host combination.

4. What DHCPv6 can do for CGA

   In the current CGA specifications, there is a lack of procedures to
   enable proper management of CGA generation. Administrators should be
   able to configure parameters used to generate CGA. For example,
   DHCPv6 server should be able to assign subnet prefix or certificates
   to CGA address owner. In some scenarios, the administrator may
   further want to enforce some parameters, particularly, the demanded
   security related parameters such as SEC value.

   In the CGA generation procedure, the large computational consumption
   is needed to generate the Modifier field. This CPU intensive
   operation can represent time and/or battery consumption problems for

Jiang & Shen           Expires April 25, 2009                 [Page 3]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-00.txt      October 2008

   end hosts (i.e. mobile devices) with limited computing ability and/or
   restricted battery power. In these cases, a mechanism to delegate the
   computation of the modifier should be provided.

   DHCPv6 can help on these issues by providing more relevant functions.

   New DHCPv6 options may be defined to carry management parameters from
   DHCPv6 server to the client. A new DHCPv6 prefix assignment option
   may be define to propagate a subnet prefix. More DHCPv6 options may
   be defined to propagate more CGA-relevant configuration information,
   such as SEC value, certification information, SEND proxy information,

   New interaction behavior between DHCPv6 server and client with a set
   of new DHCPv6 options may be defined to allow computation delegation.
   A node may initiate a DHCPv6 request to the DHCPv6 server for the
   computation of the Modifier. The server either computes the Modifier
   value, or redirects the computation require to another server. Once
   the server obtains the modifier, it computes the CGA and responds to
   the node with the resulting address and the corresponding CGA
   Parameters Data Structure.

5. What CGA can do for DHCPv6

   DHCPv6 is vulnerable to various attacks particularly fake attack. In
   the basic DHCPv6 specifications, regular IPv6 addresses are used. It
   is possible for a malicious attacker to use a fake address to spoof
   or launch an attack. A malicious fake DHCPv6 server can provide
   incorrect configuration to the client in order to divert the client
   to communicate with malicious services, like DNS or NTP. It may also
   mount a denial of service attack through mis-configuration of the
   client that causes all network communication from the client to fail.
   Fake DHCPv6 server may also collect some critical information from
   the client. Attackers may be able to gain unauthorized access to some
   resources, such as network access.

   The usage of CGA can efficiently improve the security of DHCPv6. Thus
   the address of a DHCP message sender, which can be a DHCP server, a
   reply agent or a client, can be verified by a receiver. It improves
   communication security of DHCPv6 interaction. This mechanism is
   applicable in environments where physical security on the link is not
   assured (such as over wireless) or where available security
   mechanisms are not sufficient, and attacks on DHCPv6 are a concern.
   Of course, as an assumption, the advantage of CGA can be taken only
   when CGA addresses are used in DHCPv6 communications.

Jiang & Shen           Expires April 25, 2009                 [Page 4]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-00.txt      October 2008

6. Security Considerations

   This whole draft is discussing security relevant problems. CGA and
   DHCPv6 can provide additional service or security features for each
   other. The IPv6 protocols can take advantages of each other when they
   coexist online.

7. IANA Considerations

   There are no IANA considerations in this document.

8. References

8.1. Normative References

   [RFC2462] S. Thomson, T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC2462, December 1998.

   [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
             IPv6", RFC3315, July 2003.

   [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
             Discovery (SEND) ", RFC 3971, March 2005.

   [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
             March 2005.

   [RFC4242] S. Venaas, T. Chown, B. Volz, "Information Refresh Time
             Option for Dynamic Host Configuration Protocol for IPv6
             (DHCPv6)", RFC4242, November 2005.

   [RFC4339] J. Jeong, Ed., "IPv6 Host Configuration of DNS Server
             Information Approaches", RFC4339, February 2006.

   [RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor
             Discovery for IP version 6 (IPv6)", RFC4861, September 2007.

8.2. Informative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC2119, March 1997.

Jiang & Shen           Expires April 25, 2009                 [Page 5]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-00.txt      October 2008

Author's Addresses

   Sheng Jiang
   Huawei Technologies
   QuiKe Bld., No.6 Rd, Xinxi St.,
   Shang-Di Information Industry Base,
   Hai-Dian District, Beijing, P.R. China
   Phone: 86-10-82836774
   Email: shengjiang@huawei.com

   Sean Shen
   Huawei Technologies Co., Ltd
   QuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base,
   Hai-Dian District, Beijing, P.R. China
   Phone: 86-10-82836072
   Email: sshen@huawei.com

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

   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

Jiang & Shen           Expires April 25, 2009                 [Page 6]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-00.txt      October 2008

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

Jiang & Shen           Expires April 25, 2009                 [Page 7]